l

2011年2月10日 星期四

除舊佈新 (1)

Feb. 10 21:29~23:16

又是新的一年,以前小時候每到舊年底新年初,老師都會告訴學生要『除舊佈新』,改掉過去一年的壞習慣,立定新年的希望。現在年紀大了,也沒人會跟你講要你『除舊佈新』。想一想這是一件很可怕的事,因為這表示你已經老到『江山易改,本性難移』的階段,只能混一天算一天。

對軟體開發團隊而言,『除舊佈新』也是一件年年都希望達成,卻年年『槓龜』的願望(可能只比中 18 億大樂透要簡單一點點)。因為 Teddy 過年期間在看 Software Architecture: Foundations, Theory, and Practice 這本書,今天就來談一個 Software Architecture 領域最需要被除去的『舊』。

Architecture is a development phase

軟體架構設計是軟體開發(早期)的一個 phase (階段),這個  phase 結束之後,將產生軟體架構設計。大家都知道,軟體架構將主導後續分工與實做的方式,而且軟體架構的修改是一件很大的工程,為了避免在專案進行過程中(coding phase)需要回頭修改軟體架構,在開始寫程式之前,就應該要投資很多時間在軟體架構設計上(big up-front design)。

以上觀念需要被修正。首先, Architecture is not a phase of development(大聲念三次)。為什麼軟體架構設計不是軟體開發的一個 phase?因為軟體開發隨時都在做 architecture design,只是程度多寡的差別。假設你有一個新的專案,預計 20 個 sprints (iterations) 完成。以一個 sprint 兩週來算,共計 40 周(約 10 個月)。如果以傳統 waterfall 的觀點,你在跟客戶預約工作進度的方式大體是:
  • 第1-2 月:需求分析。
  • 第3-4 月:系統(架構)設計。
  • 第5-6 月:程式撰寫。
  • 第7-8 月:測試。 
  • 第9 月:文件撰寫。 
  • 第 10 月:佈署與驗收。
Teddy 不知道現在是否還有人真的依據這種方式來執行軟體開發專案,如果有,相信專案開發成員一定時常有機會問候客戶,業務,PM,或是主管的家人。Teddy 在此祝你好運。

現今的軟體開發流程,不管是比較 heavyweight 的 UP(Unified Process),或是 lightweight 的 agile methods, 都屬於 IID (iterative and incremental) 開發方法。在這種方法之下,不會出現(也不應該出現)architecture phase,不然又回到 waterfall 的老路子。


當然,在專案進行的前幾個 sprints,開發活動中有可能花比較多的時間在確立基本的軟體架構,但這並不是說整個 sprint 除了『設計軟體架構』以外啥事都不幹。而是,舉的例子,前 2 - 4 個 sprint 只完成少數(例如 1 或 2 個) stories,利用完成這些 stories 的過程來逐步確立軟體架構基礎。在軟體架構逐步成型的過程中,陸續增加每個 sprint 可完成的 story 數目。如果專案做到一半,發現原本的軟體架構不足以支撐新的 story,則此時又可以減少該 sprint 完成 story 的數目(因為要利用完成 story 的同時來擴展新的軟體架構,所以該 sprint 可完成的 story 數目就自然變少了)。

大致上就是這個味道,講起來很簡單,但是做起來不容易。看起來採用 IID 好像沒有投資『專屬的時間』在做設計,但事實上 IID 是把設計的時間『打散』到每一個 sprints 中,到專案結束之後,所有投資在設計上的時間反而是更多的。

***

路人甲:為什麼要這麼麻煩?如果一開始不把架構都設計好,怎麼開始寫程式?如果架構是慢慢長出來的,怎麼知道整個系統會不會亂掉,以至於最後要整個打掉重練?


相信許多鄉民們會有和路人甲一樣的疑問,這可能是因為傳統 waterfall 的觀念太成功的深植人心,以至於很多人都『深信』一定要把架構『一口氣全部設計完』才可以開始寫程式。事實上,這個世界上應該沒有什麼『一口氣全部設計完』這一回事。大家都知道的一件事,軟體開發唯一不變的一件事,就是『變』。需求會變,就算是你花了 N 個月設計出一份宇宙無敵,世界無雙的軟體架構,只要需求一變,這份架構就很有可能也許要改變。不服氣的你可能會說,那好,那我就設計一種『可以應付各種改變的架構』...  很抱歉,這種東西在地球上還沒被發明出來。而且一個軟體專案也不可能讓你花太多的時間全部只在『設計軟體架構上面』。在許多情況下,開始寫程式的時間越晚,內心會愈慌亂。Over design (過度設計)的壞處絕對遠遠大於好處。通常 over design 唯一個好處只是營造一種『自我感覺良好』的假象,爽到你(architect),艱苦到我(programmers)。此外, over design 也算是一種『浪費』,應該被消除(請參考 軟體庫存消除浪費 (2):Extra Features )。

當然,要讓軟體架構可以隨著軟體開發『逐步成長』也不是一件容易的事(不然 Teddy 要靠什麼專長混口飯吃)。如果 Teddy 說出等各位累積個 10 年以上開發經驗就可以達到這種境界的屁話,那就遜掉了。Teddy 當然要指點一條明路給各位善男信女們,答案就在前一篇文章中(軟體這條路:Architect 篇 )。什麼,這樣還嫌太麻煩?。好吧,再報一支明牌,去把 Software Architecture: Foundations, Theory, and Practice 這本書的第 4 章 Designing Architectures 看完先,保證功力大增。什麼,都這樣還嫌太麻煩?來人啊,關門放狗....。最後還有一招,花錢請 Teddy 幫你也可以,這樣最快。

***
 
最後提醒一下本部落格的『不忠實觀眾』,如果還沒看過『你的軟體架構有多軟』,趕快回頭補看 。善哉,善哉。

***

友藏『自我感覺良好』之內心獨白:像 Teddy  這麼強的人怎麼都沒獵人頭公司來高薪挖角啊。Teddy 也想賺大錢啊!

12 則留言:

  1. 我是五股的軟先生,本組正是以這樣的waterfall 模式 with UML 開發,但東西都很小所以沒出過什麼問題...:P

    我沒念過軟工,一開始還覺得這樣的方式很合理,有制度。做了一兩個東西後就覺得怪怪的,但是自已也不是很懂,就去找UML的書來看,因為我們的方法據說是UML的方式

    一看不得了,跟據UML作者(發明人)的說法,一個project可以分成很多個iteration,每個iteration 可以再分exploration, design, implementation, testing。每個iteration 完,需要有一個可以動或完整的小成品(還沒看完不很確定)。

    iteration -> sprint
    完整的小成品 -> 可以出貨的產品

    軟工的精神沒有因為換個名字就不同,只是大家強調的點不同。

    心得:waterfall 就是只有一個iteration 的 UML 開發

    回覆刪除
  2. To 軟先生:

    Waterfall 其實也不是十惡不赦,有些專案的特性就真的是需求變異極少,這種情況下用 waterfall 是很合適的。

    Teddy 以前也是沒念過軟工(念電子的),很多知識都是靠自己土法煉鋼與看一堆書自學。工作了了 6-7 年後才重回學校念資工。

    感謝您留言這麼一大篇... Teddy 的部落格留言的風氣還滿... 冷清的...XD

    回覆刪除
  3. 像 Teddy 這麼強的人都還有那麼多時間發表高見,總有人會知道您的厲害之處,會有機會的。
    像 ChrisTorng 這麼強又雞婆的人,什麼事都要參一腳,忙得沒時間發表高見,沒人認識我,一定不會有獵人頭公司來高薪挖角啊。

    回覆刪除
  4. 用什麼流程我覺得還是視project、使用的framework及平台而異,不過可以確定的是架構是活的,而不是一成不變,但架構的變動幅度越大,programmer通常也越痛苦,所以適度的架構設計是必要的,事實上,『大的』架構設計應該不會花太多時間才對,細部的設計(不管稱作架構還是設計)則是隨著需求變化慢慢作調整,如果有一個需求突然要大幅的改動『大架構』,要不是一開始忽略那個需求所以設計錯的架構,就是這個新需求和當初的專案目標有很明顯的差異,也許該重新討論專案的時程、預算等等了,甚至重啟一個新專案。

    回覆刪除
  5. To Spirit Du:

    你好像很久沒寫部落格了耶?忙著寫論文?

    回覆刪除
  6. To ChrisTorng:

    錢夠用就好,問題是... 大家的錢都不夠用啊...所以,繼續等下次的 18 億大樂透吧。

    回覆刪除
  7. 請問一下,傳統的遊戲軟體開發一直是用waterfall的方式進行,小的有幸看見了很多開發失敗例子,但是開發遊戲軟體也可以使用agile的方法嗎??

    回覆刪除
  8. To 湯米:

    Teddy 沒有開發遊戲軟體的經驗,但只要是開發軟體(扣除到核能電廠,登陸月球或火星之類的專案)應該沒什麼特別理由不能用 agile methods。有興趣的話建議你可以參考一下 Agile Game Development with Scrum 這本書。

    回覆刪除
  9. 對不起,請問teddy大大有沒有推薦一些給新手看的agile的書本??如果是中文的便更好.你之前介紹給我的那本書對我幫助很大,令我更想認識一下agile.謝謝你

    回覆刪除
  10. To 湯米:

    如果要求『快』,Scrum and XP from the Trenches 這一本還不錯,簡單易懂,一,兩天之內就可以快速看完,網路上應該有『合法免費』的 pdf 可以下載。台灣有善心人士將此書翻成中文,你可以參考一下。

    回覆刪除
  11. 給湯米:
    敝小遊戲公司,online 到單機都有專案使用scrum 的開發模式(雖然有的run的怪怪的)

    回覆刪除