Oct. 30 18:14~19:00; 20:24~21:18
上禮拜六（10/27）下午到天瓏買了《Software Architecture in Practice》 第三版。以前念研究所時讀過第二版，裡面的 QAS（Quality Attribute Scenario）作為描述非功能需求還蠻有用的。在第二版中，六種QAS全部在一章裡面介紹完畢，第三版裡面除了多了Interoperability這個QAS之外，每一個QAS都單獨用一章來介紹，可見QAS的重要性日益增大。
關於第二版所介紹的六種QAS，Teddy曾經在《Quality Attribute Scenarios（1）：簡介》、《Quality Attribute Scenarios（2）：會不會太理論了一點？》、《Quality Attribute Scenarios（3）：Availability》、《Quality Attribute Scenarios（4）：Availability General Scenarios》、《 Quality Attribute Scenarios（5）：Modifiability》、《Quality Attribute Scenarios（6）：Modifiability General Scenarios》、《Quality Attribute Scenarios（7）：Performance》、《Quality Attribute Scenarios（8）：Performance General Scenarios》、《Quality Attribute Scenarios（9）：Security》、《Quality Attribute Scenarios（10）：Security General Scenarios》、《Quality Attribute Scenarios（11）：Testability》、《Quality Attribute Scenarios（12）：Testability General Scenarios》、《Quality Attribute Scenarios（13）：Usability》、《Quality Attribute Scenarios（14）：Usability General Scenarios》介紹過。今天要談的不是QAS，而是第三版第15章的新內容「Architecture in Agile Projects」。
***
Teddy在很多介紹Scrum或是敏捷開發的場合中，經常會被鄉民們問到一個問題：「軟體架構勒？採用Scrum何時要設計軟體架構？沒有設計好架構要怎麼估算 story point？」這類的問題。雖然Teddy寫過《軟體架構也可逐步成長》、《軟體架構也可逐步成長（2）》、《軟體架構也可逐步成長（3）：往下展開實例》，但是好像沒什麼鄉民買單 
先引用書中第275頁的一段話，證明 說明「軟體架構也可逐步成長」真的是可行的，至少人家都寫在書中了：「The question for a software project is not "Should I do Agile or architecture?", but rather questions such as "How much architecture should I do up front versus how much should I defer until the project's requirements have solidified somewhat?", "When and how should I refactor?", and "How much of the architecture should I formally document, and when?"」。
書中提到一個例子，Boehm和Turner兩位學者研究161個業界專案，試圖找出up-front design（事先設計）和rework（事後重工）之間的關係。理論上，如果軟體需求變動不大，做越多的up-front design，可以減少事後rework的工作量。這個研究將專案大小用行數（LOC，Line of Code）來區分成三個區間：
- 10 KLOC（一萬行）
- 100 KLOC（十萬行）
- 1000 KLOC（一百萬行）
該研究顯示，假設在相同的應用領域中，對一萬行大小的專案而言，花太多時間（超過5%的專案時間）在up-front design上將形成浪費。對十萬行的專案而言，20%的時間在up-front design是合理的。而對一百萬行的專案，合理的up-front design時間則是40%的專案時程。對於這樣的數據，鄉民們當作參考就好，其中的變數還很多，不要當成絕對的標準答案。書中有提到，專案的應用領域、可靠度與安全性要求、開發團隊的經驗等等，都會影響這個數據。。
Teddy之前有一個經驗，一個80幾萬行的專案，剛開始的第一年，大概只花5%的時間在軟體架構的設計上面。但是這個專案第一年結束的時候，當然不到80萬行，當時也沒計算到底有幾行
關於「軟體架構逐步成長」這件事，書中也有提到一些作法。例如：
- 在設計軟體架構時，要同時採用top-down（從軟體架構層面，分析架構是否可以滿足quality attribute requirements）與bottom-up（分析實作面以及環境相關的限制，例如，有哪些現成的軟體元件、框架、或技術可以使用，取捨的依據是什麼）的設計。
- 當專案開始時，要能夠快速地建立一個初始的軟體系統，用以驗證軟體架構的概念。然後依據使用者的需求優先順序，按步就班實作與修正架構（這一點頗有RUP所提到的use-case driven的味道，幾年前Teddy在開發系統的時候，也是借用這樣的概念）。
- 當新需求冒出的時候，或是團隊成員對於問題領域有更深入的了解之後，團隊成員調整現有架構，並且重構設計（Teddy注釋：要能夠調整架構並且執行重構，顯然需要自動化測試與持續整合的幫忙）。
- 隨著專案演進，持續地實驗與評估軟體架構是否合用。
***
軟體架構要能夠逐步成長，軟體系統的 modifiability（可修改性）是很重要的關鍵。快速翻完這一章，書中講了一些敏捷專案與軟體架構設計的觀念，實際上要有能力讓軟體架構逐步成長的具體方法當然還是要回歸到技術面：architecture and design patterns、 refactoring、automated testing、continuous integration、rapid feedback（這些都是硬功夫啊）。
Teddy 覺得第三版比較合適用來當做現代的教科書，第二版是10年前出版的，裡面的很多內容用現在的角度來看有點不合時宜，而第三版除了保留QAS、ATAM、CBAM 這些歷久彌新的方法以外，增加了不少新的內容，對軟體架構有興趣的鄉民可以參考一下。
最後下一個結論，要具備「軟體架構逐步成長」基本功，快來報名第二梯次的「Design Patterns這樣學就會了：入門實作班」
***
友藏內心獨白：教科書還是有它存在的意義啊。
。
），但是也不能完全排除這種浪費。例如，雖然系統是自己一個人開發的，但是需求有可能是PM（專案經理）告訴你的，這就算是一種交接。好，那如果從需求訪談、實作、交貨都是自己一個人包辦的話，這樣就幾乎沒什麼交接的浪費。但是，因為只有一個人做案子，所以有可能無法加速專案開發，或是自己遇到問題卡住，而增加了「延遲」這種浪費。由於需要自己一個人完成專案所需的所有不同類型的工作，因此自己需要在不同的工作中進行切換，也可能會造成 「工作切換」這種浪費。 
。前兩次的分享者與分享主題為：
。
。
。
。
。非常豐富的味道，翻成白話文就是，好臭啊。從味道就可以肯定，這裡真的是下水道，而不是什麼後現代藝術館 
。