開發人員守則：避免無謂的隱形成本（下）

企業的複雜度

上一篇講完代碼、系統和產品複雜度，這些問題繼而衍生出組織的複雜度。團隊需要雇用更多人手來處理和維護已開發的所有東西。越大的團隊意味著越多的溝通成本、越多的協調和和越低的效率。當然，新員工不得不被培訓就立即接手任務。替代方法可以是劃分成更小的團隊，或至是一人小組來承擔較多代碼、系統和產品週邊的工作。這降低了溝通成本，但是一人小組有他們自己的成本。一旦遇到難題，就完全拖延了項目中的唯一人手，因為有更少的人來分享這些低谷期，這種體驗對於士氣是有害的。與其他人合作的機會少了，會影響工作情緒及離職意願。除非每個人比較自覺，而且主動詢問回饋，否則個人收到的工作回饋會較少。這意味著降低代碼品質、或因疏忽導致的複雜度引入到代碼庫或基礎架構裡。

如何應付複雜度

軟件設計有兩種取向：一種是簡單，明顯地沒有缺陷；另一種方法是使其複雜，卻沒有明顯的缺陷。由於複雜度而導致的非明顯的缺陷可能造成損失，下面是團隊負責人能夠用到的一些策略：

為簡單而優化：抵制增加複雜的主張，深思維護成本，要自問，為了解決 20% 的問題而引入的複雜是否值得，或者 80% 的解決方案已經足夠了。

為你的團隊或產品定義一種任務說明以統一思想，鼓勵組員寫下任務說明。接下來對於任務說明的內容和形式的爭論，表明了首席工程師並不真正認同產品方向，如果隊員間不能儘早找出這些區別，隨之而來的努力上的分散，危險就會擴大。

用較小的Block組成大型系統，Google 就是個例子，致力於構建健壯的核心抽象，然後被非常寬泛的應用程式廣為使用。他們有基礎的構建塊，像 Protocol Buffers、Google File System 和遠端程式調用的 Stubby 伺服器。基於這些Block之上，他們還建立了其它抽象，比如 MapReduce 和 BigTable。在此之上，包括大型 web 索引、Google Analytics 網站追蹤、Google News 聚合、Google Earth 資料處理、Google Zeitgeist 資料分析在內的數以千計的應用程式，還有很多程式都是這樣構建的。

清晰地定義模組和服務之間的介面，Amazon於2002年宣稱公司將轉向面向服務的架構，所有團隊只能通過服務層級的介面彼此交流。雖然這個轉變造成了本身巨大的開發成本，但是它強制分離了代碼和服務背後的邏輯，為現在的AWS建立基礎。

優先償還技術債務，程式員總是在資訊不完全的條件下開發軟件，因此條件變化而令代碼庫增大，增加的複雜度成為了未來開發的代價。很多工程師和團隊在專案之間預算一些時間作Code Purge Day（代碼消除日），比起開一次性的會議更有幫助。工程師在這一天全力專注刪除無用代碼，刪除自己的代碼也是一種趣味。

使用工具修剪沒用的功能，在Yammer，工程師或產品經理發現在代碼重構時，強化或保留一個功能將花費不菲的時間，他們將查看使用資料，以確定這項功能是否真正被使用了。如果沒有，他們將和團隊一起決定，他們是否應該只是砍掉這個功能以降低整體工作量，這個策略也減少了技術債務。

總結:對進行中的專案分組：使同事分享同樣的環境、更容易地參與討論、代碼評審或構建可複用的資源庫。所有這些活動有助於提供檢查和平衡掉單個人或其他人所引發的問題。