開發人員守則：避免無謂的隱形成本（下）
企業的複雜度
上一篇講完代碼、系統和產品複雜度，這些問題繼而衍生出組織的複雜度。團隊需要雇用更多人手來處理和維護已開發的所有東西。越大的團隊意味著越多的溝通成本、越多的協調和越低的效率。當然，新員工不得不被培訓就立即接手任務。替代方法可以是劃分成更小的團隊，或是一人小組來承擔較多代碼、系統和產品週邊的工作。這降低了溝通成本，但是一人小組有他們自己的成本。一旦遇到難題，就完全拖延了項目中的唯一人手，因為更少的人來分享這些低谷期，這種體驗對於士氣是有害的。與其他人合作的機會少了，會影響工作情緒及增加離職意願。除非每個人比較自覺，而且主動詢問，否則個人收到的工作 Feedback 會較少。這意味著降低代碼品質、或因疏忽導致的複雜度引入到代碼庫或基礎架構裡。
如何應付複雜度
軟件設計有兩種方向：一種是簡單，明顯地沒有缺陷；另一種方法是使其複雜，卻沒有明顯的缺陷。由於複雜度而導致的非明顯缺陷可能造成損失，下面是團隊負責人能夠用到的一些策略：
為簡單而優化：抵制增加複雜的動作，想想維護成本，要自問，為了解決 20% 的問題而引入的複雜工作是否值得？或者解決了 80% 就已經足夠了？
為你的團隊或產品定義一種任務說明以統一思想，鼓勵組員寫下任務說明。接下來對於任務說明的內容和形式的爭論，表明了首席工程師並不真正認同產品方向，如果隊員間不能盡早找出這些不同的想法，隨之而來的就是努力上的分散，危險就會擴大。
用較小的 Block 組成大型系統，Google 就是個例子，致力於建立強壯的核心抽象，然後被非常寬泛的應用程式廣為使用。他們有基礎的構建塊，像 Protocol Buffers、Google File System 和遠端程式用的 Stubby 伺服器。基於這些 Block 之上，他們還建立了其它抽象，如 MapReduce 和 BigTable。在此之上，包括大型 web 索引、Google Analytics 網站追蹤、Google News Feed、Google Earth 資料處理、Google Zeitgeist 資料分析在內的數以千計的應用程式，還有很多程式都是這樣建的。
清晰地定義模組和服務之間的介面，Amazon 於 2002 年宣稱公司將轉向面向服務的架構，所有團隊只能通過服務層級的介面彼此交流。雖然這個轉變造成了本身巨大的開發成本，但是它強制分離了代碼和服務背後的邏輯，為現在的 AWS 建立基礎。
優先償還技術債務，程式員總是在資訊不完全的條件下開發軟件，因此條件變化而令代碼庫增大，增加的複雜度成為了未來開發的代價。很多工程師和團隊在專案之間預了一些時間作 Code Purge Day（代碼消除日），比起開一次性的會議更有幫助。工程師在這一天全力專注刪除無用代碼，刪除自己的代碼也是一種趣味。
使用工具修剪沒用的功能，在 Yammer，工程師或產品經理發現在代碼重構時，強化或保留一個功能將花費不菲的時間，他們將查看使用資料，以確定這項功能是否真正被使用了。如果沒有，他們將和團隊一起決定，他們是否應該只是砍掉這個功能以降低整體工作量，這個策略也減少了技術債務。
總結:對進行中的專案分組：使同事分享同樣的環境、更容易地參與討論、代碼評審或建立可複用的資源庫。所有這些活動有助於提供檢查和平衡其他人所引發的問題。
相關文章：
