近在與一位總經(jīng)理交流的時候，他談到他們公司的軟件研發(fā)管理，說：“我們公司大的問題是項目不能按時完成，總要一拖再拖。”他問我有什么辦法能改變這個境況。從這樣一個問題開始，在隨后的交談中，又引出他一連串在軟件研發(fā)管理中的遇到的問題，包括：
現(xiàn)有代碼質量不高，新來的開發(fā)人員接手時寧愿重寫，也不愿意看別人留下的“爛”代碼，怎么辦？
重構會造成回退，怎樣避免？
有些開發(fā)人員水平相對不高，如何保證他們的代碼質量？
軟件研發(fā)到底需不需要文檔？
要求提交代碼前做Code Review，而開發(fā)人員不做，或敷衍了事，怎么辦？
當有開發(fā)人員在開發(fā)過程中遇到難題，工作無法繼續(xù)，因而拖延進度，怎么解決？
如何提高開發(fā)人員的主觀能動性？
其實，每個軟件研發(fā)團隊的管理者都面臨著或曾經(jīng)面臨過這些問題，也都有著自己的管理“套路”來應對這些問題。我把我的“套路”再此絮叨絮叨。
1. 項目不能按時完成，總要一拖再拖，怎么改變？
找解決辦法前，當然要先知道問題為什么會出現(xiàn)。這位總經(jīng)理說：“總會不斷地有需求要改變和新需求提出來，使原來的開發(fā)計劃不得不延長。”原來如此。知道根源，當然解決辦法也有了，那是“敏捷”。敏捷開發(fā)因其迭代（Iterative）和增量（Incremental）的思想與實踐，正好適合“需求經(jīng)常變化和增加”的項目和產(chǎn)品。在我講述了敏捷的一些概念，特別是Scrum的框架后，總經(jīng)理也表示了對“敏捷”的認同。
其實仔細想想，這里面還有一個非常普遍的問題。對于產(chǎn)品的交付時間或項目的完成時間，往往由高級管理層根據(jù)市場情況決策和確定。在很多軟件企業(yè)中，這些決策者在決策時往往忽略了一個重要的參數(shù)，那是團隊的生產(chǎn)率（Velocity）。生產(chǎn)率需要量化，而不是“拍腦門子”感覺出來的。敏捷開發(fā)中有關于如何估算生產(chǎn)率的方法。所以使用敏捷，在估算產(chǎn)品交付時間或項目完成時間時，是相對較準確的。Scrum創(chuàng)始人之一的Jeff Sutherland說，他在一個風險投資團隊做敏捷教練時，團隊中的合伙人會向所有的待投資企業(yè)問同一個問題：“你們是否清楚團隊的生產(chǎn)率？”而這些企業(yè)都很難做出明確的答復。軟件企業(yè)要想給產(chǎn)品定一個較實際的交付日期，首先要弄清楚自己的軟件生產(chǎn)率。
2. 現(xiàn)有代碼質量不高，新來的開發(fā)人員接手時寧愿重寫，也不愿意看別人留下的“爛”代碼，怎么辦？
這可能是很多軟件開發(fā)工程師都有過的體驗，在接手別人的代碼時，看不懂、無法加新功能，讀代碼讀的頭疼。這說明什么？排除接手人個人水平的因素，這說明舊代碼可讀性、可擴展性比較差。怎么辦？這時，也許重構是一種兩全其美的辦法。接手人重構代碼，既能改善舊代碼的可讀性和可擴展性，又不至于因重寫代碼帶來的時間上的風險。
從接手人心理的角度看，重構還有一個好的副作用，是代碼重構之后，接手人覺得那些原來的“爛”代碼被修改成為自己引以自豪的新成�！禨crum敏捷軟件開發(fā)》的作者Mike Cohn寫到過：“我的女兒們畫了一幅特別令人贊嘆的杰作后，她們會將它從學校帶回家，并想把它展示在一個明顯的位置，也是冰箱上面。有，在工作中，我用C++代碼實現(xiàn)了某個特別有用的策略模式的程序。因為我認定冰箱門適合展示我們引以為豪的任何東西，所以我將它放上去了。如果我們一直對自己工作的質量特別自豪，可以驕傲地將它和孩子的藝術品一樣展示在冰箱上，那不是很好嗎？”所以這個積極的促進作用，將使得接手人感覺修改的代碼是自己的了，而且期望能夠找到更多的可以重構的東西。
3. 重構會造成回退，怎樣避免？
重構確實很容易造成回退（Regression）。這時，重構會起到與其初衷相反的作用。所以我們應該盡可能多地增加單元測試。有些老產(chǎn)品，舊代碼，可能沒有或者沒有那么多的單元測試。但我們至少要在重構前，增加對要重構部分代碼的單元測試�；谥貥嬆康牡膯卧獪y試，應該遵循以下的原則（見《重構》第4章：構筑測試體系）：
- 編寫未臻完善的測試并實際運行，好過對完美測試的無盡等待。測試應該是一種風險驅動行為，所以不要去測試那些僅僅讀寫一個值域的訪問函數(shù)，應為它們太簡單了，不大可能出錯。
- 考慮可能出錯的邊界條件，把測試火力集中在哪兒。扮演“程序公敵”，縱容你心智中比較促狹的那一部分，積極思考如何破壞代碼。
- 當事情被公認應該會出錯時，別忘了檢查是否有異常如期被拋出。
- 不要因為“測試無法捕捉所有Bug”，不撰寫測試代碼，因為測試的確可以捕捉到大多數(shù)Bug。
- “花合理時間抓出大多數(shù)Bug”要好過“窮盡一生抓出所有Bug”。因為當測試數(shù)量達到一定程度之后，測試效益會呈現(xiàn)遞減態(tài)勢，而非持續(xù)遞增。
說到《重構》這本書，其實在每個重構方法中都有“作法（Mechanics）”一段，在重構的實踐中按照上面所述的步驟進行是比較穩(wěn)妥的，同時也能避免很多不經(jīng)意間制造的回退出現(xiàn)。
