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