除舊佈新 (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 也想賺大錢啊！