管理建構 | CODE COMPLETE

軟體專案管理是一項艱巨的挑戰，而本章聚焦於與建構直接相關的管理議題：如何鼓勵良好的編碼實踐、控制變更、估算時程、度量過程，以及把程式設計師當人看。

28.1 鼓勵撰寫良好的程式#

由管理層強制推行嚴格的技術標準通常不是好主意——程式設計師傾向認為管理者的技術水準不足以制定規範。如果要定義標準，應由受人尊敬的**架構師（Architect）**來制定。

技巧	說明
指派兩人負責每個部分	從結對程式設計到導師-學徒配對，確保至少兩人認為程式碼可行且可讀
審查每一行程式碼	程式碼審查讓至少三人閱讀每行程式碼，也是推動團隊編碼標準的隱性力量
要求程式碼簽核	由資深技術人員簽署程式碼清單，如同工程圖紙需要工程師簽章
傳閱優秀程式碼範例	比用文字描述標準更容易理解與更新
強調程式碼是公共資產	程式碼不是私有財產，而是專案資產
獎勵優秀程式碼	確保獎勵對象的技術實力真的值得肯定，否則反而損害公信力
一個簡單標準	「我必須能夠讀懂專案中的所有程式碼」，能有效抑制過度「聰明」的寫法

設定管理（Configuration Management, CM） 是識別專案產出物並系統化處理變更的實踐，也稱為變更控制（Change Control）。它包括評估提案的變更、追蹤變更，以及保存系統在各時間點的狀態。

SCM 最大的系統性問題是過度控制。必須謹慎規劃，使其成為資產而非累贅。小型專案可能只需非正式的定期備份；大型專案則需要完整的 SCM 方案。

缺乏紀律的變更控制是軟體產業面臨的最大管理問題之一。許多被認為「延遲」的專案，若能追蹤未記錄的變更影響，其實是準時的。

版本控制軟體（Version-Control Software） 是團隊協作的基石：避免多人衝突、一鍵更新至最新版、可回溯任何已簽入版本、取得完整變更紀錄，且本身即為安全備份。

備份計畫應涵蓋定期備份、異地存放與所有重要專案資料。別忘了測試你的還原程序。

大型軟體專案平均超支 100%，開發者的估算通常帶有 20-30% 的樂觀因子（Optimism Factor）。

「被度量的事情就會被執行」（What gets measured, gets done）——人們會關注被度量的面向而忽略未被度量的。謹慎選擇度量的項目。

任何專案屬性都能找到優於完全不度量的度量方式，即使不完美也能提供對開發流程的掌握。

從簡單的度量開始（缺陷數、工作月數、總金額、總程式碼行數），跨專案標準化後逐步精煉。先設定目標，再決定需要回答什麼問題。

高度技術性的工作需要以自然、人性化的環境來平衡。最成功的技術公司結合了高科技（High-Tech）與高接觸（High-Touch） 的元素。

研究顯示程式設計師之間存在數量級的差異：初始編碼時間最佳與最差比率約 20:1，除錯時間超過 25:1。經驗年數與程式碼品質或生產力之間沒有直接關聯。團隊層面，第 15 百分位能力的團隊通常需要第 90 百分位團隊約 3.5 倍的工作月數。

若需要多付薪資才能雇到前 10% 的程式設計師，絕對值得。你會在品質和生產力上立刻獲得回報，並在留住其他優秀人才方面產生正向循環。

某些議題屬於個人風格的信仰問題（Religious Issues），管理者應避免強制規定，包括：程式語言、縮排風格、大括號位置、IDE 選擇、命名慣例等。應使用「建議」而非「規則」，讓程式設計師自行發展團隊標準。

DeMarco 與 Lister 的研究顯示，表現前 25% 的程式設計師擁有更大、更安靜、更私密的辦公空間，其生產力是後 25% 的 2.6 倍。投資改善工作環境可帶來約 40-100% 的生產力提升。

技術上稱職且跟得上時代的管理者相當罕見。若你的管理者屬於多數情況，你需要學會「向上管理」：

策略	說明
植入想法	提出構想後，等待管理者「靈光一現」地採納你的點子
持續教育管理者	這是長期工程，因為管理者經常調動
聚焦管理者的利益	做他真正想要你做的事，不要用不必要的實作細節分散注意力（把它當作工作的「封裝」）
拒絕不當指令	堅持用正確的方式做事
換工作	如果以上都行不通