###### tags: `讀書會筆記`
# 人月神話：Chapter 13-16

# Chapter 13 化整為零(如何除錯)
* **避免發生錯誤的設計方式**
1. 做好定義以防止誤解：包含定義清楚產品（詳細的功能定義、詳細的規格說明、規範良妤的防錯設施與錯誤處理技術），以達概念整體性
2. 規格審查：類似我們的BA 文件的確認
3. 由上而下的設計方式：持續細分精製的步驟（refinement steps)，由大到小的去細緻展開，以達到模組化，過程中可能會前前後後的不斷梳理。（有點像龍捲風思考模式？
4. 結構化的程式設計

* **組件除錯**
1. 上機除錯：實際上真的直接執行測試（必須細節規劃除錯程式）
2. 記憶體傾印：儘量縮短個人佔用電腦的時間
3. 記憶體即時擷取（選擇性傾印）
4. 交談式除錯：使用監督程式，分配不同程式在電腦記憶體上執行（分時除錯）
5. 測試案例

=>**現行作法應該已經不太類似上述提到的過程，因為電腦資源不如以前稀少。但某些概念仍適用，比如細節規劃除錯程式（log要長在哪）和測試案例的撰寫。**

* **系統除錯**
1. 使用除錯完成的組件：嘗試整合or讓組件彼此互測（較粗糙），但可以少掉建立測試鷹架的時間。不要累積一堆錯誤之後才解決。
2. 建立充分的測試鷹架：dummy or miniature file (類似pytest?)，甚至有輔助程式分析
3. 控制改變
4. 一次只整合一個組件（上線前）
5. 固定改版（上線後）

=> **現行的做法中，我們好像很難針對系統做除錯，通常都是看到跑DevOp的流程失敗，慢慢找log再去問DE，而DE是否有辦法有效監控？還是他們用什麼方式監控呢？我們是否也能自己看？是否有任何系統除錯的方式發想?**

# Chapter 14 釀成大災難(專案延宕怎麼辦)
* **明確的里程碑才不會讓人無所適從**
eg., 明確的里程碑如下
「規格文件已被架構設計師和實作人員簽署」、
「程式碼已全部完成、打完孔，並且已存入了硬碟中的程式庫」、「除錯完成的版本通過了全部的測試案」

* **無形的幹勁**
1. 激發成員解決問題的鬥志 -> 是否可以讓技術人員知道問題的嚴重性，甚至是激發他們思考問題嚴重性？
2. PERT chart or critical-path scheduling (確認可以有一點點延誤的點和不能被延誤的點是什麼）-> 可以知道Task之間的相依性
https://ithelp.ithome.com.tw/articles/10212208

* **順利的表象之下？(高階主管如何掌握專案狀態)**
1. 基層主管需掌握小組落後的狀態，並處理
2. 老闆須知道未如計畫進行的意外和計劃執行狀況。若要避免老闆無法得知意外與計劃：
1. 降低角色衝突 （不要干涉部署自己有能力處理的問題，也不在了解階段就馬上處理問題）
2. 定期審查（里程碑的執行狀態）-> 規劃和預估的日期都可以寫出來

=>議題討論：
**1. 是否需要計劃監控小組？
2. 大家都會怎麼激勵自己的小組呢？
3. 大家的里程碑都會怎麼訂?**

# Chapter 15 一體兩面(如何文件化與其重要性)

* **文件必備：**(可以思考看看專案文件是否時常包含這些內容)
1. 概觀性的描述 (overview）
2. 目的
3. 環境：程式要在哪種機器上跑？硬體和作業系統的組態該如何設定？
4. 輪入值域與輸出值域：程式輸人與輸出資料的合理範圍為何？
5. 欲達成的功能與使用的演算法：很精確地說出程式到底要做什麼事情？
6. 輸出入格式：要精確而完整地描述
7. 執行過程中的指示
8. 選項使用者在功能上有哪些選擇彈性？這些選項該如何正確地加以指定？
9. 執行時間
10. 輸出結果的精準度跟檢驗方式

* **測試文件**
1. 主案例
2. 罕見的合法案例（合理邊界值）
3. 罕見的不合法案例（不合理的邊界值是否有辦法處理）

* **修改紀錄文件**
1. 流程圖或副程式的結構圖
2. 演算法的完整描述
3. 所有運用到的檔案的一份設計說明
4. 解譯階段結構（pass structure）的概觀：從硬碟中載入資料的程序紀錄
5. 與修改相關的研討紀錄，包括原設計構想、可插入點 （hooks)與離開點 （exits）的類型與位置，以及原設計者對一些可能的變化所做的推論與提供的因應之道。對於一些修改上的潛在陷阱，他的評論是具參考價值的。

**=> 解譯階段結構（pass structure）的概觀好像比較偏DE在紀錄？我們是否需要獲得這樣的資訊？要如何才能快速獲得這樣的資訊？**

* **流程圖or 程式架構圖**
（非必要，但若無，會需要自我說明程式）

* **自我說明程式**
1. 程式跟說明融合
2. 利用coding style 來協助閱讀
3. 為每次的執行 都取一個獨立的工作名稱，並以此名稱來維護用以記載目的、時間、結果的執行紀錄。
4. 易記的程式名稱。名稱中包含版本的識別碼
5. 以一般口語化的叙述方式為此程序 (PROCEDURE）加上註解。
6. 記錄程式中所使用的演算法可供參考的文獻。
7. 指出程式與文獻中所記載的演算法之間的關係：
a. 改變 b. 使用上的特例 c. 代表性的做法
8. 宣告所有的變數，並使用易記的名稱，以註解來對所宣告（DECLARE）的變數做更進一步的解釋。
9. 以標籤來標明一個區塊的程式片段，表示出同屬一個演算法
10. 以縮排來突顯結構與分段

=>議題討論：
**1. 大家的測試文件通常都怎麼訂? 是否有建議的方式?**

# Chapter 16 沒有銀彈：軟體工程的本質性與附屬性工作

(這章重點少少的，感覺就是想說寫程式本質上有其困難性，所以想要有辦法解決大家的真正痛點(耗時耗腦)很難)

* 軟體工程本質上的困難點：
* 複雜性
* 配合性
* 易變性
* 隱匿性
* 嘗試過解決本質上問題但僅解決附屬性問題的方法：
* 高階語言
* 分時技術
* 統一的軟體開發環境
* 尚未嘗試過解決本質上問題但作者認為僅解決附屬性問題的方法：
* 其他高階語言
* 物件導向程式設計
* 人工智慧
* 專家系統
* 自動化程式設計（只是更高階的語言而已）
* 圖形化程式設計
* 軟體驗證
* 作者覺得有機會解決本質上問題的方法：
* 外購軟體(利用各家新創公司的新技術)
* 需求的提煉與快速原型製作(明確的需求)
* 漸進式的開發(基於前人的肩膀來開發)
* 偉大的工程師(如何吸引更厲害的工程師)

**=> 我們有什麼方式可以協助解決軟體工程上的本質問題？**