《人月神話》讀書筆記part2

標籤：軟體工程

第五章畫足添蛇（THE SECOND-SYSTEM EFFECT）

架構設計師面對過高的估算的兩個選擇：

1. 削減設計
2. 向開發人員建議用成本更低的實現方法

第2個選擇若要成功，架構設計師必須：

• 記住開發人員有發會創意完成實作的任務，所以架構設計師只能建議。
• 在建議時，提出一個能夠符合規格的實現方法，同時也接受其他能夠達到目標的方桉。
• 默默地，私底下提出建議。
• 準備放棄所作的改進建議。

這邊所謂的「第二系統效應」，是指一個人在設計系統的時候，第二個設計出來的系統，是最危險的一個。這是因為在第一個系統的時候，由於自知不夠熟系，所以會比較節制、也會比較簡單清爽；

但是設計第二個系統的時候，卻很容易把在做第一個系統時的所有構想，都加掛到這個自認已經熟系的第二個系統上，所以第二個系統很容易有過度設計的問題。再之後的系統（第三個及以後），由於會和之前的經驗做對比、相互印證，所以也就比較不會有問題了～

如何避免這個問題？
以設計師來說：

• 主要就是要靠「自律」了～同時，也要瞭解這個第二系統效應的原因，並提醒自己避免設計出不相關的功能、或是做出違反原先架設與目的的功能。
• 為每個小功能分配一個值：每次改進，功能x不超過m子節的記憶體和n微秒

專案經理來說：

• 要採用至少兩個以上系統設計經驗的架構設計老手的決定。
• 保持對特殊誘惑的警覺。

第六章貫徹執行（PASSING THE WORD）

這一章主要的主題，是著重於整個意思的傳達，以及精確的描述；因為唯有在所有參與專桉的人都能夠明確無誤地瞭解整個架構、規範、介面等等必須要溝通的東西時，才有可能真正完全按照計畫來進行。而針對了這個主題，作者也在本章內提出了許多建議：

書面規則／手冊

• 不僅要描述使用者將會看到的所有細節，也要避免描述使用者看不到的東西。
• 手冊的風格應該要準確、完整、詳細，各項定義與要點必須要保持一致；而為了做到這點，所以書面化的工作應該要由一到兩個個人來主筆。

形式化定義

• 採用「形式化標記法」（formal notation）。
• 為了精確，使用「形式化定義」（formal definition），
• 為了易懂，也需要「記述性定義」（prose definition）；
• 而這兩者之中，要有一個是主要標準，另一個則輔助描述。

－設計實現也可以當作正式定義，例如用模擬器來當作定義。

• 這樣的好處是只要實際測試一下，就知道他應該有什麼結果；
• 但是相對的，也有可能因此會因為這個實現，而導致定義的過度描述，而影響到之後實現的彈性。

開會

1周例會

• 由首席系統架構設計師擔任主席、時間較短（半天）
• 任何與會人員都可以提出問題和修改意見（但是要先提交書面資料），重點在於激發創意；
• 而在提桉後由架構設計師整理成為較精細的提桉報告。
• 會議決策權在首席系統架構設計師上，最後的結果要正式、即時、全面地公告。如此可以使各項決策迅速敲定、讓工作得以順利進行。

2年度大會

• 時間較長（兩周）
• 用來處理細瑣事務、公開討論，讓大家發洩不滿。

多重實現

一開始就開發兩個以上的實現產品，可以避免根據錯誤的實現去修改規格，將有助於維持架構定義的純淨與嚴謹。

電話日誌

• 允許實現人員直接詢問架構設計師（電話、或者電子郵件），而不要自行解釋。
• 而這些詢問都應該被記錄下來、整理後分發給所有實現人員和使用者。

產品測試

獨立的產品測試小組是必須的。

第七章為什麼巴比倫塔會失敗？（WHY DID THE TOWER OF BABEL FAIL?）

巴別塔失敗的原因是什麽？作者認為是「溝通」，以及隨之而來的「組織」；

怎樣溝通？

• 非正式的方法（電話、電子郵件）
• 會議
• 工作手冊 是一份對項目必須產出的一系列檔案的組織圖，包括目的，外部規格說明，介面說明，技術標準，內部說明和管理備忘錄。

使用工作手冊的原因？

1. 規範了專桉進行過程中即將產生的檔案，並可以用來儲存技術方面的說明；而為了讓工作手冊可以真正有用，他需要被儘早、小心地設計出來。
2. 控制資訊發布：確保需要資訊的人都能夠在適當的地方取得資訊的方法，每一個團隊的成員都應該要可以看到工作手冊的全部檔案內容（沒有必要所有人都要看完所有的東西，部分的細節應該要被封裝（encapsulated）起來，不屬於自己的東西，就不必、也不被允許去看裡面的細節，只需要看到簡介就夠了。）（對備忘錄編號，建立樹狀索引結構）；同時也要確保檔案的內容有被持續地更新，並且保有改版的紀錄，讓看的人知道版本間的修改狀況。在以往這點可能很難做到，但是現在網路、電子化檔案都很發達了，要做到基本上問題並不大。

大型編程項目的組織架構

「組織」的目的：減少溝通量。

• 人力配置
• 專業分工

傳統的樹狀結構組織主要是源自於權力的責任結構，但是以溝通結構來說，則是會是網狀的，這樣才可以避免溝通不良的問題。

樹狀編程隊伍：

1. 任務（a mission）
2. 產品負責人(a producer)
3. 技術主管或結構師（a technical director or architect）
4. 進度（a schedule）
5. 人力劃分（a division of labor）

2負責著急小組、指派工作、規劃時程、爭取掌握資源，以及和別的小組溝通，並且對時程負責；
3則是構思、分割系統，切割系統的外觀和內構，維持整個設計的和諧與整體性。

作者認為，這兩種腳色的搭配方法有三種：

• 管理者兼任技術總監 主要適合於小型團隊，不是用於大型團隊。
• 管理者是總指揮、技術總監是副手
• 技術總監是總指揮、管理者是副手

《人月神話》讀書筆記part2