tag:blogger.com,1999:blog-65286621615179811092024-02-19T13:27:40.335+08:00輕鬆談軟工-- by 台灣軟體工程學會薛念林http://www.blogger.com/profile/12980029140541777743noreply@blogger.comBlogger62125tag:blogger.com,1999:blog-6528662161517981109.post-18501073899830309272017-08-08T11:25:00.001+08:002017-08-09T22:36:07.975+08:00加油站與小鎮兩個小鎮之間有一個荒蕪之地,一些汽車會經過,一個聰明的商人於是在那裡開了一間加油站,生意還不錯。一個月過後有人在旁邊開了一間雜貨店,買點日用品喝點水,再過一些日子有人開了咖啡店,可以休息聊個天。漸漸的有人在那裡蓋房子住了下來,於是餐廳、學校、銀行進駐,慢慢的變成一個小鎮。
同樣一個故事發生在另外一個地方,生意人覺得加油站真賺錢,於是在附近蓋了第二間加油站,生意也還可以,於是第三個人再進來蓋加油站,開始削價競爭,最後三家生意都做不下去紛紛倒店了。
老掉牙的故事,每隔四五年就會聽到一次,但感受卻越來越深。
我們現在做的系統(或事情),是第二個加油站,還是邁向小鎮的咖啡廳?
薛念林http://www.blogger.com/profile/14914118237671233903noreply@blogger.com0tag:blogger.com,1999:blog-6528662161517981109.post-48271321904401725722017-08-08T10:58:00.002+08:002017-08-09T22:37:57.638+08:00治標不治本
家裡總有些小蟑螂,我們想盡了各種方法來除小蟑螂,例如買強力黏蟑紙,或是殺蟑螂的誘餌,一開始都有點功效,但過了一陣子蟑螂又跑出來了。
根本的解決之道在於,蟑螂為什麼會到我家?過去我們大概兩三天會倒一次垃圾,因為家裡的塑膠袋是大的,每天倒垃圾覺得浪費。於是我們換成小的垃圾袋,並開始每天倒垃圾,於是乎家裡的小蟑螂慢慢地就不見了。
治標真的不是辦法,必須要找出問題的根源並加以解決。
軟體的開發也是,如果你的公司不斷的產生 bug, 或是品質出現問題,別只是見 bug 除 bug,得好好想想:bug 為何會出現?薛念林http://www.blogger.com/profile/14914118237671233903noreply@blogger.com0tag:blogger.com,1999:blog-6528662161517981109.post-13678169782410820482017-07-08T22:23:00.000+08:002017-07-28T10:55:40.046+08:00TCSE 2017 2017 年第 13 屆台灣軟體工程研討會於 7/8 圓滿落幕。本次共有25 個學術研究單位參加,包含中央大學、中央研究院、中正大學、中華電信研究所、元智大學、台中教育大學、台北大學、台北科技大學、台灣大學、交通大學、成功大學、亞洲大學、宜蘭大學、東吳大學、東海大學、虎尾科技大學、政治大學、修平科技大學、海洋大學、高雄師範大學、崑山科技大學、逢甲大學、嘉義大學、輔仁大學、靜宜大學等。第一天參與會議約 180 人,晚宴席開12桌約 120 人,第二天半天的活動也有約 100 人與會。
本次大會主題為 Software Engineering and Data Science,共有 83 篇投稿,最後收錄 75 篇論文,包含 12 篇英文論文,6 篇展示論文及 57 篇中文論文。針對這三類論文共邀請九位委員選出六篇最佳論文,其中最佳英文論文兩篇:
Chien-Hung Liu and 薛念林http://www.blogger.com/profile/14914118237671233903noreply@blogger.com0407台灣台中市西屯區文華路100號24.178816 120.646705-4.4585089999999994 79.338111 52.816141 161.955299tag:blogger.com,1999:blog-6528662161517981109.post-46657710326675350272015-11-12T10:19:00.000+08:002017-07-28T11:51:21.616+08:00使用CRC cards的『責任驅動設計』方法本文簡單介紹一般人比較不熟習的所謂『責任驅動設計』(Responsibility-Driven Design 簡稱 RDD),這種設計方法是根據系統的責任,來設計類別的行為與方法或功能,因此RDD可運用在軟體發展上。1989年Rebecca Wirfs-Brock與Brain Wilkerson在OOPSLA'89發表『責任驅動設計』的軟體設計方法,後來她們與Lauren Wiener共同寫了一本叫『Designing Object-Oriented Software』(PTR Prentice Hall 1990)的書用以實作RDD,2003年Wirfs-Brock與Alan McKean合著『Object Design - Roles, Responsibilities, and Collaborations』(Addison-Wesley)一書更深入介紹RDD,讀者如沒有這兩本書黃為德http://www.blogger.com/profile/02964648045837160880noreply@blogger.com0tag:blogger.com,1999:blog-6528662161517981109.post-9062578004881374082015-03-15T12:21:00.000+08:002015-03-24T20:12:32.287+08:00現今軟體發展流程趨向 降低發展軟體系統的工作量、減少發展所需的時間是現今軟體發展流程的主要趨勢,因此由郭忠義、薛念林、馬尚彬與黃為德共同發展一本書名為『現代軟體工程─物件導向軟體發展策略』,這本書有別於傳統的軟體工程書籍,引進現代的先進軟體工程技術,並具有下列特色:
全面理解基本軟體工程與物件導向的觀念。
提供『案例研究』(case study)以說明物件導向軟體發展流程。
介紹系統化軟體測試與方法,導引出各種敏捷軟體發展方法,如Scrum方法。
根據軟體設計原理與發展樣式,協助發展者發展可保養的軟體系統,提高設計品質。
以敏捷觀念介紹一些有用的建模原理與應用,例如責任驅動設計(Responsibility-Driven Design,RDD)、模型驅動架構(Model Driven Architecture,MDD)。
專章介紹軟體度量預測與使用CRR卡模型,兼顧黃為德http://www.blogger.com/profile/02964648045837160880noreply@blogger.com0tag:blogger.com,1999:blog-6528662161517981109.post-71471404910957193332013-11-10T16:50:00.001+08:002017-07-28T10:33:30.375+08:00『簡單』- 讓混亂發展成規則 (Order from Chaos)
我在治療期間,抽空讀了一本肯恩‧西格爾(Ken Segall)著作,書名為『簡單』的書 (應該稱為『極致簡單』- Insanely Simple),西格爾主要在闡述史蒂夫‧賈伯斯(Steve Jobs)以『簡單』至上的觀念引導蘋果的成功故事,其實,賈伯斯曾經被蘋果「放逐」11年,於1997年再度回到蘋果擔任執行長,賈伯斯不在期間,蘋果每下愈況,一直到賈伯斯回來時,蘋果已經岌岌可危,幾近破產邊緣,賈伯斯以『簡單』至上的觀念重振蘋果。『簡單』至上的概念很難說得清楚,它可能是一種選擇,一種氛圍或一種指引,視你的需要而定,簡言之,『簡單』就是『打破複雜,創造絕對優勢』,你/妳如果用過蘋果的產品如iPad,可能就會有所感受,例如更新作業系統(iOS)就很簡單,總之,蘋果的基本理念是:『硬體簡單化,而背後的軟體卻豐富化』。賈伯斯黃為德http://www.blogger.com/profile/02964648045837160880noreply@blogger.com1tag:blogger.com,1999:blog-6528662161517981109.post-56786910930111327682012-12-08T14:56:00.000+08:002017-07-28T10:45:30.963+08:00CRC cards - 非正規物件導向發展技術最近看到Kent Beck與Martin Fowler講的一句『諺語』,說:"Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文,提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』,溝通在軟體發展的過程中十分重要,尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto),此地不宜對宣言多做闡述),問題是你要使用何種工具或方法來溝通?我想除use cases外,CRC cards可能是最佳工具之一,它是隨時隨地可得的低技術工具,易學易用。
軟體開發與維護時,工作夥伴的合作十分重要,換言之,團隊合作是黃為德http://www.blogger.com/profile/02964648045837160880noreply@blogger.com10tag:blogger.com,1999:blog-6528662161517981109.post-83184224169130812832012-04-24T18:03:00.000+08:002017-07-27T22:57:13.628+08:00再漫談『課程改進』 去年TCSE2011 Panel discussion之後,我在2011/07/13po了一`篇叫『課程改進』短文,文中主要討論,教學生是先教程式設計或模式觀念,該文引起一些討論,2011/12/05我又發表一篇:『CRC cards - 非正規物件導向發展技術』(該文因無人點閱故暫還原為草稿),我因此想到「冷飯熱炒」po這篇短文就教對該類議題的有心人士。
事實上,討論程式與模式孰先孰後不會有結論,也不應有結論,因何者為先何者為後,甚至兩者平行教學,端視教師的觀念與想法,不過我認為,這個議題可能影響往後的軟體工程與物件軟體工程的教學以及學生學習的深度與速度,我教過幾年的物件軟工課程,發現有些學生對於模式的概念相當薄弱,因此要了解諸如UML的功能與運用時有些困難,甚至於利用UML來發展軟體也黃為德http://www.blogger.com/profile/02964648045837160880noreply@blogger.com0tag:blogger.com,1999:blog-6528662161517981109.post-53135648716681274272011-09-24T16:48:00.000+08:002011-09-24T16:52:12.455+08:00TCSE 2011 Panel discussion
前言
今年在輔大舉行的TCSE Panel discussion,三位與談者與眾多與會者對『軟體核心能力』這個議題,在一個小時的時間內做了許多探討。以下的抄本,由輔仁大學范姜永益教授轉錄自當天的錄音,特此致謝;抄本業經與談人修訂、補充。建議讀者參考當天的 投影片 一起閱讀,更歡迎大家在『輕鬆談軟工』一起加入討論。附帶說明,此抄本已略去錄音效果不佳的部份,敬請包涵。
Transcript begins
北科大 鄭教授開場
軟體領域最近的熱度,大家都知道。最近參加的一個會議裡,電腦公會的代表提到,幾家ICT大廠有數千個android 軟體開發的職缺;同一個會議中亦談到雲端軟體開發,在座好幾個大廠每家亦以數以百計的數量開出軟體開發人員的需求。各位,如果您或是您的學生會寫Android的程式 我想出路應該是沒有什麼問題。但是,身為教育界的一分子,我們要薛念林http://www.blogger.com/profile/12980029140541777743noreply@blogger.com7tag:blogger.com,1999:blog-6528662161517981109.post-88831499423394820702011-07-13T17:56:00.005+08:002011-07-13T18:26:35.219+08:00課程改進今年在輔大招開的TSCE11,其中在Panel Discusion中(主題:軟體核心能力),我提議軟工教育訓練由OO modeling概念開始,而程式則依據models來撰寫,這種提議可能須修改教學程序,不過我認為,「軟體核心能力」的目的乃是要建立優良的軟體系統,而models比複雜的程式容易描述系統,也比較容易保養系統,因為其抽象層次較高,也符合程式語言以及軟體發展方法的演變之故。我提出這種意見,希望對軟體工程教育有興趣的人士能夠討論,提供意見。黃為德http://www.blogger.com/profile/02964648045837160880noreply@blogger.com13tag:blogger.com,1999:blog-6528662161517981109.post-60961564879351891182010-05-03T23:20:00.001+08:002017-07-29T11:36:30.793+08:00蓋房子和寫軟體往花蓮的自強號上,旁邊坐著一位五十幾歲的長者,一直反覆的看著一本旅遊書籍,看起來是歐洲旅遊的書。我好奇便問他:『剛從歐洲旅遊回來嗎?』,他嚇了一跳,我連忙向他道歉,他親切說;『沒關係』,接著很興奮的告訴我他的攝影心得,就這麼聊了起來。
他一邊翻閱書上的照片,許多的地方他都去過,他說他喜歡研究別人取景的角度為何和他不同,借此學習更好的攝影技巧。看得出他對生命充滿熱情,喜歡思考、創作與分享。聊著聊著才知道他原來是台中知名建商的董事長。
除了生活上的樂趣外,他也跟我分享他的經營理念。他對員工的要求是『不能凡事都照著規格書、設計圖走,那是官僚』。為什麼?他們的員工每天都在接觸房子的買賣,久了就麻痺了,以為房子的買賣很輕鬆,但是對許多買房子的人可能是畢生的積蓄,一生可能只買一次房子。
他說他接觸過很多醫生、教授或高科技產業的客戶,他們在自己的領域上十分的專業,"但對房子的事情真的就是不懂",薛念林http://www.blogger.com/profile/12980029140541777743noreply@blogger.com3tag:blogger.com,1999:blog-6528662161517981109.post-70461838087658079482010-04-06T11:59:00.000+08:002017-07-28T10:32:45.843+08:00有理說不清軟體系統常常背上許多莫需有罪名,有時候是需求的提供者沒把需求說清楚(或根本說了錯誤的需求),有時候是使用者不會用 (沒參與教育訓練或沒看說明書)造成操作不當。當後者的情況發生時,使用者通常會怪罪『介面設計不好』。
的確多數的軟體工程師對於介面的設計不重視也不在行,但有時候使用者也太無理取鬧,把所有的錯誤都賴在介面設計上。
張大叔最近開始使用線上照片沖洗的功能,但照片卻遲遲沒有寄到,他上網查了一下,發現住址寫錯了。他打電話到客服中心發飆。
『你們的系統有問題不穩定,把我家的地址記錯了。明明是100號,怎麼會記成200號?』
客服查了一下,回應說:『張先生,有可能是您打錯了,系統記錄的的確是200號』
『怎麼可能?我打過無數次了,怎麼可能會把自己的住址打錯?』
客服有耐心的說:『有可能1和2相鄰,您打的時候打太快了,所以不小心打錯了』
『那你們系統要做檢查嘛,哪有那們笨的系統?要薛念林http://www.blogger.com/profile/12980029140541777743noreply@blogger.com4tag:blogger.com,1999:blog-6528662161517981109.post-77986427447341112492010-03-25T10:22:00.010+08:002017-07-30T15:10:43.641+08:00問題解決古時候,中國有一則寓言是說:有四個人走到一面高牆前面,高牆的通門用鐵鍊與鎖鎖住,其中三人試圖用盡各種方法要打開門鎖,用石頭打、火燒、以及用木棒挖鎖等方法,但最後仍然無功,這時候,忽然看到那第四人從森林走出,手握一把長竹竿,走到牆面前以撐竿跳的方式跳過那一面牆。
第四人並沒解決門鎖的問題,而是避開重新定義問題,創造新的而可解決的問題,因此基本上問題不在門鎖,而目的是人要到達牆的另一面。
這則故事顯示,"what"與"how"的問題,前面三個人只想『我如何打開那道門』(how),至於另外一個人則避開那三個人的困境,只是想『我要做甚麼』(what),答案是『我要過那面牆』,一旦他將問題放在"what"上面,他就可以設計如何執行而獲得成功,他解決問題不只是解決,而是問題要合理解決。
發展軟體就應如這則寓言中第四人的作法,要如何達到有許多方法,其中CRC cards (黃為德http://www.blogger.com/profile/02964648045837160880noreply@blogger.com1tag:blogger.com,1999:blog-6528662161517981109.post-59513911248664888642010-02-25T23:28:00.005+08:002010-02-25T23:59:09.554+08:00從種樹小故事看流程改善今天上課前突然想到一個故事,稍作改變後用來跟學生講解流程改善。某公司聘用一個員工上種樹,他需要鋤頭挖洞,將樹植下,最後再用鏟子把地鏟平。以他的速度一天只能種十顆樹,比老闆預期的進度差太多,於是老闆又聘了兩個人來幫忙,速度提昇了兩倍。[from work harder to work smarter]但是這樣的速度還是不夠快,而成本又太高已經沒有經費在聘用員工,只好想辦法進行流程改善。他仔細觀察三個員工的工作方式,發現花在工具的抽換花了太多的時間。於是他重新更換了三個人的工作:A 只做挖洞的動作,B 隨後將樹植下, C 隨後在將地鏟平。這樣的工作模式可以省去更換工具的時間,更棒的是,每個人更能夠把自己的工作做的專精,效率又提高了兩成。[但,小心成為官僚流程]這樣的流程跑了很久,員工來來去去換了許多次,但都保持一定的高效率。一天,老闆去看工地,發現A 挖玩洞後,C 緊接著把洞補起來填平,老闆薛念林http://www.blogger.com/profile/12980029140541777743noreply@blogger.com4tag:blogger.com,1999:blog-6528662161517981109.post-19934586186983957152010-01-10T20:36:00.005+08:002017-07-30T13:22:13.268+08:00軟體工程與大型整合專案—以WiMAX整合型計畫為例 (3/3)Continuous Integration
在討論版本控管時,我們曾經提到WiMAX計畫使用一個輔助工具「JCIS」進行持續整合(Continuous Integration)的工作。那麼,為什麼要做持續整合呢?維基百科中對於持續整合的理論有些初步的介紹,包含下列十個重要的Practices:
維護一個程式庫(Maintain a code repository)
將建置自動化 (Automate the build)
使建置能進行自我測試(Make the build self-testing)
每人每天送交程式碼(Everyone commits every day)
每次送交都應該被建置(Every commit should be built)
維持快速的建置時間(Keep the build fast)
在實際運行的環境下進行測試(Test in a clone of 陳偉凱http://www.blogger.com/profile/13559894007235435226noreply@blogger.com0tag:blogger.com,1999:blog-6528662161517981109.post-24509600682206512942009-12-31T18:11:00.021+08:002017-07-28T10:46:26.229+08:00無題趁歲末,我花了一點時間,回憶一些各方對今年發表的諺語與部落格文章所提出的意見,雖然這些意見不能涵蓋全面,但多少反應一些現象,這種現象顯示國內軟工教育問題,就是學校的軟工教育訓練不能完全『學以致用』,也讓我這個開授軟工課程多年的教師匠有點『做白工』的感覺,嚴重一點說,有點誤人子弟。話說,從今年2月20日薛教授post上去的『好人難為』一篇文章,以及最近Q39諺語:『Schedule是用來Delay的』說起,我覺得我們的軟體工程師似乎受很大的委曲,大部分的委曲都是說很難與老闆溝通,有人說溝通無效只好忍氣吞聲,或者默認,甚至乾脆打包走人(「好人難為」意見箱),『‧‧‧要不然抱怨變化永遠趕不上客戶的一通電話』(Q39諺語),甚至說如果客戶來個需求變更,那(專案)就要delay到天荒地老等等,是不是那麼嚴重,我想還不至於吧,不過我相信這些抱屈都是事實,也都是經驗之談,不過從軟工的角度來看,似乎並不黃為德http://www.blogger.com/profile/02964648045837160880noreply@blogger.com0tag:blogger.com,1999:blog-6528662161517981109.post-90951784729068204562009-12-05T21:43:00.003+08:002017-07-30T13:21:16.673+08:00軟體工程與大型整合專案—以WiMAX整合型計畫為例 (2/3)版本控管
在整合國科會CMMI文件與程式開發的過程中,總計劃與各子計畫的文件與程式都需要一個版本管理的機制,一方面萬一有電腦當機或是檔案損毀時,可以迅速還原最新的版本,解決資料備份的問題,另一方面還可以在歷史紀錄中往返,將刪去的文件或程式找回來。對於文件或程式整合而言,版本控管十足是一個Time Machine。
我們在第一年開發之前就已經預期到版本控管的重要性,因此在專案初期便架設可透過Web介面存取的版本控管伺服器(Apache + Subversion),並且安排Subversion的教育訓練。但是,可能是一開始時教育訓練的內容安排不符合需求,也可能是開發團隊不夠用心,導致版本控管並不上軌道。最常發生的問題包括:團隊成員未確實解決衝突(Conflicts)、久久不送交(Commit)程式、送交無法編譯的程式、送交時不寫註解等。
這些問題的原因,有部分與先前討論過的缺乏一致的陳偉凱http://www.blogger.com/profile/13559894007235435226noreply@blogger.com0tag:blogger.com,1999:blog-6528662161517981109.post-16246467813144553792009-11-01T21:42:00.004+08:002017-07-30T13:19:57.237+08:00軟體工程與大型整合專案—以WiMAX整合型計畫為例 (1/3)以往學生在學軟體工程時,總覺得這門課就是在「寫文件」,對於為什麼要寫文件,以及文件的用途,不甚了解,甚至覺得寫文件是很枯燥乏味的一件事。的確,為了交作業而寫文件,我想沒有人會認為寫文件是有用的,特別是對於一個虛擬的軟體專案而言,即使必須開發對應的軟體,充其量也是一個小品,而且一個學期的時間又很有限,所以不是文件品質不好就是軟體沒寫好,更別提要維護了, 而學生無法對軟體跟專案產生情感,自然無法體會文件的意義。
過去三年,筆者因為主持國科會整合型計畫「WiMAX 無線通訊系統軟體與工具開發(I),(II),(III)」的關係,需要主導撰寫其Light-weight CMMI文件,剛開始的第一年,參與計畫的學生們也是哀鴻遍野,學生們即便已經參加過國科會舉辦的Light-weighted CMMI研討會,寫出來的文件,和實際的軟體設計仍有一段很大的落差,一直到第二年,需要開始維護第一年的軟體時陳偉凱http://www.blogger.com/profile/13559894007235435226noreply@blogger.com2tag:blogger.com,1999:blog-6528662161517981109.post-26895176786200650092009-10-02T23:53:00.004+08:002009-10-03T00:33:29.773+08:00手機上的物件導向最近 HTC 出了一款 Android 手機, HTC Hero, 相信3C 迷及 Google 的愛好者都相當注意。我雖然也注意了一陣子,但最近才發現它一直很強調它的 People-centric 的特色-- 就是以人為中心,將電子郵件、通話紀錄、簡訊整合在一起的功能。這樣的設計感覺起來很直覺,很好用。回頭看看過去的設計,是以通話、傳簡訊、查看通話記錄為主的『功能導向』設計,『人』只是這些動作的參數。這才驚覺原來現在的手機介面設計流行(進化到?)『物件導向』。這樣的進化是偶然?還是從物件設計的理論得到靈感?如果是後者,也許可以進一步的思考物件設計的技術 -- 例如繼承 -- 如何應用在手機上。 把手機上的聯絡人用繼承樹(a kind of)來模組,如此一來在訊息傳送給父類別的群組時也會送給子類別的聯絡人,或許這樣可以簡化整個手機上的群組關係。當然,物件上的『association』薛念林http://www.blogger.com/profile/12980029140541777743noreply@blogger.com0tag:blogger.com,1999:blog-6528662161517981109.post-88850135576462184472009-09-30T12:32:00.005+08:002017-07-27T22:56:36.165+08:00大長多多學生們還是問,為什麼需要軟體工程?和程式設計有什麼不同?為什麼需要作專案管理、監控、控管等等?寫得出程式不是比較實在嗎?
這是因為學生寫的程式太小、參與開發的人太少、專案關係人太少、而維護的時間太短,以致於他們無法想像軟體工程的必要性。
真的軟體專案是『大長多多』的。
到了業界,一個專案要破萬行很容易的,程式一旦大,相互關係就會變複雜,動一行指令可能會牽涉到好多地方。所以需要學軟體工程,學如何切模組、作架構設計。學設計概念,知道如何才容易維護、好擴充功能。程式一旦變大,它的成本也會指數性的上升,你需要學習成本估算的方法。
專案的時間通常很長,不是一個星期能完成的家庭作業。所以你需要專案文件(幫助你記憶),專案管理(來掌握時間與分配人力)。維護當然把整個時程拉的更長,所以設計的時候要考慮彈性、成本要把維護算進去。在組織人力調配上,你需要考慮開發與維護是否是同一組人。薛念林http://www.blogger.com/profile/12980029140541777743noreply@blogger.com12tag:blogger.com,1999:blog-6528662161517981109.post-56239276995731389502009-09-20T09:29:00.067+08:002009-09-28T10:13:45.928+08:00談談設計原則DIP3/21本人寫了一篇文章介紹OCP設計原則 (意即:要延伸一個類別時不能要求修改該類別) ,多少引起一些反應,現在我們利用這篇短文來輕鬆談談,另外一項重要的軟體設計原則:「依存反向原則」(Dependency Inversion Principle - DIP)。首先我們談談何謂軟體「設計原則」,在軟體發展的領域中,所謂設計原則是:「在發展軟體系統的動作中,一種可接受的規則或方法,也就是說可使用的工作原則」(http://dictionary.reference.com/),好的設計原則必須是能夠協助發展者產生設計主意(idea),而且可以讓設計者能夠透過設計意涵來思考其實際的設計(Rebecca J. Wirfs-Brock 2009),依據這樣的定義,我們所要談的設計原則是可實地應用的,不過原則並非嚴格的設計規則,有如設計樣式(design patterns)一樣,僅在某種環境中使用黃為德http://www.blogger.com/profile/02964648045837160880noreply@blogger.com4tag:blogger.com,1999:blog-6528662161517981109.post-31944549153514250582009-06-19T16:49:00.004+08:002009-06-19T17:03:31.431+08:00分、時、天今天在研討會中聽到一個不錯的比喻。軟體工程度量在國內一直很難推動,這或許與國內對於工程量化的觀念比較不足有關係。這一點可以日常生活中的用語窺得一二,西方人說『wait a minute』,以『分』為單位台灣人稱火車慢了為『慢點』,以『小時』為單位印度人則說『等天』,以『天』為單位這讓我想起PSP (personal software process)方法要求以分為單位來記錄工時,但對於我們的工程師的確是很大的壓力。以我們逢甲資訊處為例,工時的紀錄幾乎都是以小時為單位。這之間的關聯是否為巧合?有趣。薛念林http://www.blogger.com/profile/12980029140541777743noreply@blogger.com1tag:blogger.com,1999:blog-6528662161517981109.post-81589621060046128402009-06-06T08:57:00.007+08:002017-07-28T10:49:00.795+08:00憑空產生的程式碼最近學生報告了一篇有趣的論文。研究團隊開發了一個系統 CodeConjurer(程式碼魔術師),說的是可以憑空產生的程式碼。你會想,這怎麼可能?
它的原理很簡單,首先各位都知道 google 搜尋引擎可以去找全世界網頁的資料,其實還有許多是針對程式碼的搜尋引擎。例如 Merobase。研究團隊利用 Merobase 到一些 opensouce 的地方(例如 SourceForge)找程式碼,程式設計者只要寫出你想要用的物件的功能(也就是定義他的介面),CodeConjurer 就幫你找出一些可能的軟體元件,你可以進去看裡面的程式碼檢驗是否這就是你要的元件,如果是的話,可以馬上下載並整合到你的專案中。這無疑的可以幫你節省一些時間。
當然,光是透過介面的定義就認定該原始碼就是你要的可能會有些風險。為了進行 semantic check, CodeConjurer 也與 JUnit薛念林http://www.blogger.com/profile/12980029140541777743noreply@blogger.com2tag:blogger.com,1999:blog-6528662161517981109.post-18312967239016752042009-03-31T23:24:00.006+08:002009-04-01T13:14:49.736+08:00新書介紹:Inside Steve's Brain『如果我問我的顧客想要什麼,他們會回答我一匹跑的更快的馬』- 亨利 福特最近上了一本新書『Inside Steve's Brain』,說的是蘋果賈柏斯對經營、設計的一些理念。我想大家對賈柏斯轟轟烈烈的事蹟一定很熟悉(特別是蘋果迷),在此不做贅述。我個人雖不是蘋果迷,但也深深的佩服他對設計的執著與相關產品的簡約。我一直覺得台灣需要的不是系統實作人才,應是軟體設計人才。設計是什麼?我所說的並不是什麼結構性設計、物件導向設計、架構設計等技術的東西。而是態度。一種對設計的態度。什麼是設計的態度?答案也許在這本書中。推薦各位看看。一般而言,軟體工程裡都教我們系統分析時要做需求訪談,聽顧客的話。但在某個領域中,特別是創新的領域中,傾聽自己內心的渴望(對產品的渴望)是更重要的:我們如何能做出讓人能夠感動的產品?Steve 相當欣賞亨利 福特的一句話:『如果我問我的顧客想要什麼,他們會回答我一匹跑的更快薛念林http://www.blogger.com/profile/12980029140541777743noreply@blogger.com3tag:blogger.com,1999:blog-6528662161517981109.post-22834030579527359752009-03-21T10:04:00.029+08:002009-03-24T09:33:00.860+08:00談談OCP看到「好人難為」一文,主角是一位專班學生,看來他似乎很委曲,因此我在意見箱內提議,他可以好好研究一下軟體設計的第一原則:Open-Closed Principle (OCP),或許可以解決他的困擾,這件事涉及到軟體工程的教育與訓練的問題,也就是說,學以致用的問題,因此有必要寫一篇短文以OCP為例,來談談軟體設計原則的運用,這些原則並非軟體發展的食譜(cookbook),而是發展者必須放在心裡的「指引」(guideline),這種指引必須落實成為diciplines,其他如設計樣式(design patterns)也具有指引特性,因此才能廣泛運用,也就是說,可以重覆使用(reuse),學習時最好蒐集一些範例,可能有助於這些設計原則或樣式的運用,有如念法律的人必須研究一些判例一樣,學習軟體發展方法時也不例外。OCP是物件導向方法的核心,1988年由Bertrand Meyer在他的著作"黃為德http://www.blogger.com/profile/02964648045837160880noreply@blogger.com7