我們?cè)撊绾伍_(kāi)始進(jìn)行項(xiàng)目管理
引言 誰(shuí)應(yīng)該對(duì)項(xiàng)目進(jìn)行管理
項(xiàng)目管理的的文章和書(shū)籍到處都是，我也不敢在這班門(mén)弄斧。所以以下的文字主要關(guān)注從沒(méi)有管理到開(kāi)始對(duì)項(xiàng)目進(jìn)行一些管理這個(gè)過(guò)程，通常沒(méi)有進(jìn)行管理或者很少進(jìn)行管理的項(xiàng)目也不會(huì)特別大，所以本文并不一定適合大型項(xiàng)目。本文也不完全符合某***程或者標(biāo)準(zhǔn)，其中一些只是我個(gè)人的一些淺見(jiàn)，如果能拋磚引玉，那就再好不過(guò)了；如果哪里說(shuō)的不對(duì)，肯定各位筒子們盡管拍磚。
作為項(xiàng)目組的成員之一，不論你是開(kāi)發(fā)工程師，測(cè)試工程師還是數(shù)據(jù)庫(kù)工程師，你都對(duì)項(xiàng)目管理負(fù)有責(zé)任。在工作中，工程師應(yīng)該精通自己的部分，優(yōu)秀的工程師還應(yīng)該熟悉別人的部分，實(shí)際情況中的工程師通常還需要在必要的時(shí)候（有人離開(kāi)）頂上去做任何一個(gè)部分，此時(shí)，對(duì)項(xiàng)目的整體的把握至關(guān)重要。在參與到管理的過(guò)程中，也會(huì)提高自己的項(xiàng)目管理能力。其實(shí)，“項(xiàng)目管理”四個(gè)字重點(diǎn)不在管理，而在項(xiàng)目，當(dāng)你的心在項(xiàng)目上，你就是管理者，項(xiàng)目就有可能因?yàn)槟愣晒?；反之，即使你是個(gè)小角色，項(xiàng)目也可能因你而面臨失敗的危險(xiǎn)。
?。ㄒ唬?我們需要什么樣的人
在前面的文字中，我提到項(xiàng)目中的人員。我個(gè)人通常喜歡稱項(xiàng)目的參與者為“工程師”，不管是開(kāi)發(fā)，測(cè)試還是數(shù)據(jù)庫(kù)管理，還是需求分析，項(xiàng)目管理人員。工程師這個(gè)詞，其實(shí)包含了很多內(nèi)容，不僅僅是壘代碼，而是要像做一個(gè)建筑工程一樣，考慮自己的部分對(duì)其他部分的影響，設(shè)計(jì)自己的部分，構(gòu)建自己的部分，測(cè)試自己的部分，這是一個(gè)有機(jī)互動(dòng)的過(guò)程，不是一個(gè)簡(jiǎn)單機(jī)械運(yùn)動(dòng)。我要強(qiáng)調(diào)的是工程師是技術(shù)工種，不是熟練工種，作為項(xiàng)目組的一員，我們也要從內(nèi)心去做一個(gè)技術(shù)工種而不是熟練工種。
基于以上的考慮，我認(rèn)為項(xiàng)目組成員應(yīng)該至少具備如下三個(gè)特征：
1， 具有本領(lǐng)域內(nèi)基本的技術(shù)能力和學(xué)習(xí)能力。我堅(jiān)信不知道開(kāi)機(jī)按鈕在哪的同志確實(shí)干不了修理電腦的活兒，也不認(rèn)為三天學(xué)不會(huì)hello world的程序員還有在這個(gè)領(lǐng)域生存的機(jī)會(huì)。
2， 專(zhuān)注于工作的精神。哪怕你工作一分鐘，也請(qǐng)專(zhuān)注的工作，專(zhuān)注的思考。專(zhuān)注成就價(jià)值，只有專(zhuān)注的做事情，才能有所斬獲。
3， 能夠與人溝通。眾所周知，溝通對(duì)于項(xiàng)目的成功有多么重要，所以溝通是項(xiàng)目組成員比不可少的素質(zhì)之一。
工程師，還是代碼工人。你的選擇？
?。ǘ?始終關(guān)注交付物--不管是項(xiàng)目經(jīng)理還是開(kāi)發(fā)人員（項(xiàng)目中的所有人）
項(xiàng)目一開(kāi)始，我們就開(kāi)始和客戶談需求。“汽車(chē)怎么賣(mài)跟我程序員有什么關(guān)系？如何讓你的客戶滿意又關(guān)我什么事？只要告訴我你要什么就行了嘛，廢話這么多”，很多程序員都這么想。
隨著這些我們并不關(guān)心的事情越談越多越談越深入，我們?cè)讲荒蜔?，越想早點(diǎn)兒結(jié)束，進(jìn)入我們自己的代碼的世界。此時(shí)，我們忘記了真正重要的真正最核心的東西：我們要交付什么東西！此時(shí)你會(huì)說(shuō)，我沒(méi)有忘記，我就是要做個(gè)B2B的電子交易平臺(tái)。沒(méi)錯(cuò)兒，就是它，但是它是什么呢？包括什么呢？為什么是這樣的呢？將來(lái)有可能會(huì)變成什么樣呢？甚至這個(gè)平臺(tái)能為我們的客戶帶來(lái)什么呢？不知道你能回答上來(lái)多少。
我們的交付物---它可能是一個(gè)獨(dú)立工作的功能，可能是一個(gè)部署的方案，也可能是一個(gè)幫助文檔， 它才是值得我們一直關(guān)注并且必須要關(guān)注的東西。對(duì)于它，我們應(yīng)該深入的去了解，它能干什么？ 為什么要這么干或者能為客戶帶來(lái)什么？在整個(gè)項(xiàng)目中處于什么位置？關(guān)鍵的挑戰(zhàn)在哪里？何時(shí)交付最給力？最晚何時(shí)交付還能有效？如果沒(méi)能交付會(huì)有什么后果，還有替代方案嗎？
為了了解我們的交付物，我們必須深入的了解客戶的需求。當(dāng)我說(shuō)到需求，我不想你聯(lián)想到海量的客戶業(yè)務(wù)信息，雖然那也是我們需要了解的；我只想讓你去深入了解當(dāng)前你在思考的交付物，以及跟它有關(guān)聯(lián)的業(yè)務(wù)接口，當(dāng)然，還有它產(chǎn)生的影響。關(guān)注交付物的***好處就是能夠保證項(xiàng)目的交付，而最核心的技術(shù)就是學(xué)習(xí)客戶的業(yè)務(wù)—雖然我們是程序員，但其實(shí)我們應(yīng)該是全才。
在此過(guò)程中，原型法是個(gè)不錯(cuò)的主意。原型不一定是一個(gè)客戶看的東西，我不太看重那些重型的花費(fèi)太多精力的原型。有時(shí)候，一個(gè)流程圖，簡(jiǎn)單的幾行字，幾條描述業(yè)務(wù)的問(wèn)題，一段與用戶關(guān)于功能點(diǎn)的深入短暫的交談，都是很好的原型。原型其實(shí)就是將你理解的東西，讓用戶理解，并得到用戶的反饋，不管用什么方式，只要達(dá)到這個(gè)目的，那你的原型就成功了。
***，一切關(guān)注交付物的努力都將迎來(lái)收獲的季節(jié)：驗(yàn)收。項(xiàng)目組員可能關(guān)注交付物，而項(xiàng)目***可能更關(guān)注驗(yàn)收。其實(shí)關(guān)注交付物，就是關(guān)注驗(yàn)收，因?yàn)轵?yàn)收就是由一系列的交付物組成。乍一看，驗(yàn)收貌似就是一堆代碼或者一堆文檔，其實(shí)不然。驗(yàn)收其實(shí)是一個(gè)過(guò)程，是一個(gè)從開(kāi)始就需要得到關(guān)注的過(guò)程。在項(xiàng)目開(kāi)始的計(jì)劃和設(shè)計(jì)階段，每一個(gè)交付物都應(yīng)該有一個(gè)完成的標(biāo)準(zhǔn)，即做到什么時(shí)候?yàn)橹?，一切交付物都?yīng)該是可驗(yàn)證的，而這種驗(yàn)證方式應(yīng)該得到客戶的認(rèn)可。這些驗(yàn)證方式可以是一些測(cè)試用例，也可以是一些其它的標(biāo)準(zhǔn)，但是必須得有，我們一切的工作都要圍繞這個(gè)驗(yàn)證標(biāo)準(zhǔn)進(jìn)行。要努力讓客戶相信：驗(yàn)收就是跑完客戶已經(jīng)簽字的測(cè)試用例，系統(tǒng)出現(xiàn)的錯(cuò)誤在可以接受的范圍之內(nèi)。我們并不是欺騙客戶，而是要客戶進(jìn)行深度參與，讓它們意識(shí)到這些測(cè)試用例的重要性，從而更好的實(shí)現(xiàn)雙贏。
（三） 我們需要哪些文檔，工具和努力
軟件項(xiàng)目肯定離不了文檔和管理工具，如果您的項(xiàng)目還沒(méi)有它們，那么請(qǐng)從現(xiàn)在開(kāi)始。那么文檔是不是越多越好呢？老話說(shuō)的好，合適的才是***的。小而精的文檔和工具會(huì)讓我們事半功倍，大而全的文檔會(huì)讓我們疲于奔命，***迷失在文檔的海洋中。
我們寫(xiě)代碼的都知道，錯(cuò)誤的注釋比沒(méi)有注釋更可怕；同樣的，沒(méi)有及時(shí)得到更新的文檔比沒(méi)有文檔更可怕，因?yàn)槲臋n就是項(xiàng)目的注釋。那么我們是否有必要去更新那些我們根本沒(méi)有用到的文檔呢？很顯然，那是非常沒(méi)有必要的，是對(duì)資源的浪費(fèi)。文檔說(shuō)起來(lái)其實(shí)就是一個(gè)工具，是一個(gè)讓我們開(kāi)發(fā)時(shí)有依據(jù)，可以追溯開(kāi)發(fā)過(guò)程以及記錄開(kāi)發(fā)結(jié)果的工具。我們只有用到它，它才有存在的必要。
那么文檔過(guò)于少或者干脆沒(méi)有文檔，不是更簡(jiǎn)潔？我想說(shuō)：不寫(xiě)代碼不是更簡(jiǎn)潔？玩笑歸玩笑，沒(méi)有文檔或者文檔太少會(huì)導(dǎo)致的問(wèn)題大家可能也都遇到過(guò)：那就是過(guò)程不可追溯，有些非常重要的邏輯沒(méi)有記錄，需要用到時(shí)團(tuán)隊(duì)成員各執(zhí)一詞，甚至需要重新找客戶確認(rèn)而是客戶認(rèn)為我們不夠?qū)I(yè)；有些非常重要的設(shè)計(jì)沒(méi)有記錄，導(dǎo)致代碼維護(hù)困難，以至于維護(hù)人員破口大罵開(kāi)發(fā)人員寫(xiě)的什么垃圾代碼做的什么垃圾設(shè)計(jì)。有些設(shè)計(jì)非常的巧妙，非常的值得學(xué)習(xí)，然而就是因?yàn)闆](méi)有留下記錄而被初學(xué)者如我一樣的人罵了N次。在反省自己不夠聰明時(shí)，是否也該讓寫(xiě)代碼的人反省一下為什么沒(méi)能留下點(diǎn)兒記錄？
有一種觀點(diǎn)是***的設(shè)計(jì)就是代碼，意思是代碼就是設(shè)計(jì)，代碼應(yīng)該非常的優(yōu)秀，可讀性特別好，讓人一看就明白，我完全同意。如果代碼寫(xiě)到這種程度，那文檔就真的沒(méi)用了。那么請(qǐng)自問(wèn)，您是這樣嗎？如果是，沒(méi)文檔，沒(méi)問(wèn)題；如果不是，請(qǐng)把重要的東西寫(xiě)下來(lái)。那么，哪些是重要的呢？
哪些是必須的， 哪些是Optional的。對(duì)于哪些文檔更重要些，應(yīng)該由項(xiàng)目的具體情況而定，特別是項(xiàng)目的大小，邏輯的復(fù)雜程度，人員的情況等等很多因素。在我做過(guò)的項(xiàng)目中，我個(gè)人認(rèn)為最重要的一些文檔和工具如下所述：
1， 功能說(shuō)明書(shū)（Functional Specification）------按獨(dú)立功能劃分優(yōu)先級(jí)，每一條記錄都是一個(gè)可交付物，都是一個(gè)功能。整個(gè)文檔就描述了整個(gè)項(xiàng)目的交付功能和優(yōu)先級(jí)。項(xiàng)目中的所有人，都應(yīng)該關(guān)注這個(gè)文檔：測(cè)試用它來(lái)寫(xiě)測(cè)試用例；開(kāi)發(fā)人員用它來(lái)決定先開(kāi)發(fā)哪個(gè)功能；PM用它來(lái)查看功能的完成和驗(yàn)證狀態(tài)。它通常不應(yīng)該內(nèi)容過(guò)多（由項(xiàng)目規(guī)模決定），我覺(jué)得最多兩行字就可以描述一個(gè)獨(dú)立工作的功能，至于對(duì)這個(gè)功能的理解，應(yīng)該由負(fù)責(zé)它的程序員來(lái)完成。
2， 核心流程圖。這個(gè)流程圖可能描述了用戶使用該系統(tǒng)的過(guò)程；也可能描述系統(tǒng)中數(shù)據(jù)的流轉(zhuǎn)；也可能描述表單的流轉(zhuǎn)。總之，它描述一個(gè)過(guò)程，這個(gè)過(guò)程對(duì)用戶來(lái)說(shuō)非常重要。這個(gè)圖有時(shí)候也會(huì)被其它的圖，如順序圖代替。
3， 部署文檔。該文檔描述了該系統(tǒng)應(yīng)該如何部署，它不一定非要是一個(gè)word文檔，也可能僅是一個(gè)bat文件而已。這個(gè)文檔應(yīng)該描述該項(xiàng)目如何部署，步驟是怎么樣的，需要哪些文件，需要哪些硬件支持，以及需要注意什么。部署歷來(lái)都不太被重視，大家覺(jué)得只要東西做出來(lái)了，部署不就是放上去嗎？其實(shí)不然。在經(jīng)歷了一定周期的開(kāi)發(fā)后，開(kāi)發(fā)過(guò)程中積累的配置，對(duì)環(huán)境的要求，在真正部署的時(shí)候很多就忘了，所以部署可能會(huì)花費(fèi)很多沒(méi)必要的時(shí)間，我覺(jué)得這也是微軟要做daily build的原因之一，每天都build一個(gè)可用的版本，當(dāng)然部署就沒(méi)有問(wèn)題了。我們剛開(kāi)始可能不需要每天都build一個(gè)版本，但最少要一周或者兩周部署一個(gè)版本吧。每次部署都整理一個(gè)自動(dòng)化的腳本或者文檔，會(huì)讓你***上線的時(shí)候非常的從容。
4， 測(cè)試用例。我不是一個(gè)測(cè)試人員，測(cè)試也是我覺(jué)得一直沒(méi)有做到位的地方?？陀^的說(shuō)，我覺(jué)得用例應(yīng)該花很大心思去編寫(xiě)，就像用戶真正的在使用軟件一樣。項(xiàng)目應(yīng)該在設(shè)計(jì)和開(kāi)發(fā)的時(shí)候就以滿足用例為目標(biāo)，而不是開(kāi)發(fā)完了才想起來(lái)用例，去測(cè)試，發(fā)現(xiàn)問(wèn)題再修改，回頭想想，這可能就是測(cè)試驅(qū)動(dòng)開(kāi)發(fā)產(chǎn)生的原因吧。我們知道用戶發(fā)現(xiàn)錯(cuò)誤修改的成本高于我們自己發(fā)現(xiàn)的錯(cuò)誤；同樣的，設(shè)計(jì)和開(kāi)發(fā)階段就解決的問(wèn)題成本也遠(yuǎn)遠(yuǎn)小于測(cè)試階段發(fā)現(xiàn)的。正是，問(wèn)題發(fā)現(xiàn)的越早，解決起來(lái)就越容易，成本就越低。
5， Bug管理工具。這個(gè)管理工具可以是一個(gè)excel，當(dāng)然，我并不推薦這么做，畢竟excel卻是不那么自動(dòng)化。但是，只要比excel自動(dòng)化一點(diǎn)點(diǎn)兒的信息系統(tǒng)就可以了，它需要可以記錄問(wèn)題，可以傳截圖，這就夠了。我推薦使用bug tracker，這是個(gè)dotnet開(kāi)發(fā)的開(kāi)源的bug管理工具，其實(shí)也可以管理需求，是非常實(shí)用的。
以上五個(gè)是我認(rèn)為最重要的，我覺(jué)得是項(xiàng)目開(kāi)始進(jìn)行管理的階段必不可少的；而下面幾個(gè)，則是大家視情況可選的。
6， 核心類(lèi)圖。這個(gè)可能是可選的，因?yàn)橛袝r(shí)候，類(lèi)的關(guān)于沒(méi)那么復(fù)雜，也就沒(méi)有必要有這個(gè)圖；相反，則需要進(jìn)行記錄。
7， 數(shù)據(jù)庫(kù)設(shè)計(jì)。數(shù)據(jù)庫(kù)設(shè)計(jì)文檔可能在review的時(shí)候用到。
8， 系統(tǒng)間接口圖。如果產(chǎn)品有若干個(gè)子系統(tǒng)，如web service等等，那么我認(rèn)為需要一個(gè)描述系統(tǒng)間接口和交互關(guān)系的圖，這個(gè)圖應(yīng)該在設(shè)計(jì)的早期就開(kāi)發(fā)出來(lái)供大家使用并且隨時(shí)保持更新和關(guān)注。
有了文檔和工具，是不是就一切OK了呢？不對(duì)，就像大而全的文檔并不能幫助我們成功一樣，有了文檔并不代表項(xiàng)目就能成功，如何維護(hù)和使用這些文檔和工具是相當(dāng)重要的。每個(gè)文檔都應(yīng)該有人去維護(hù)，那么誰(shuí)去做這個(gè)事呢？我認(rèn)為項(xiàng)目經(jīng)理應(yīng)該經(jīng)常拿著功能說(shuō)明書(shū)開(kāi)會(huì)，它也可以被看做是WBS的初級(jí)版本，可以被標(biāo)注狀態(tài)和優(yōu)先級(jí)；所有人都應(yīng)該熟悉流程圖，并隨時(shí)提出對(duì)流程圖進(jìn)行檢驗(yàn)和review；應(yīng)該指定一個(gè)人負(fù)責(zé)構(gòu)建，這并不需要花費(fèi)很多時(shí)間，但是需要細(xì)心和一些***主義精神；測(cè)試人員自然要維護(hù)好測(cè)試用例；每個(gè)人特別是開(kāi)發(fā)人員，都應(yīng)該有一種覺(jué)悟，那就是一旦想起了哪些重要的邏輯，不管是業(yè)務(wù)的邏輯還是系統(tǒng)的算法，都應(yīng)該記錄到bug管理工具上。Bug管理工具完全可以記錄這些零散但卻重要的東西，以便將來(lái)方便查詢。
在這里我也是根據(jù)自己的經(jīng)歷簡(jiǎn)單的談了一些我的看法，這并不是金科玉律，我還得說(shuō)，合適你的才是***的。
（四） 代碼規(guī)范的選擇
做開(kāi)發(fā)不可避免的遇到代碼規(guī)范，從上學(xué)時(shí)就會(huì)學(xué)習(xí)到一些規(guī)范，但是每個(gè)公司都不同，那么我們到底要遵守哪些規(guī)范呢？我個(gè)人認(rèn)為，一個(gè)合格的程序員應(yīng)該可以隨時(shí)調(diào)整自己適應(yīng)任何一種規(guī)范，這是一種職業(yè)素養(yǎng)和能力。而何時(shí)該遵循何種規(guī)范，這也有一定的原則。
1， 在現(xiàn)有系統(tǒng)（代碼）基礎(chǔ)上進(jìn)行開(kāi)發(fā)。這種情況下，我們應(yīng)該盡量的去遵循原有系統(tǒng)的規(guī)范，不論是命名還是注釋。因?yàn)槿绻@時(shí)你非要按照自己的習(xí)慣寫(xiě)，那么系統(tǒng)就會(huì)出現(xiàn)兩種完全不同風(fēng)格的代碼，這對(duì)將來(lái)的維護(hù)是一種噩夢(mèng)。但是，遵循原有規(guī)范不是遷就原有錯(cuò)誤。如果發(fā)現(xiàn)原有的規(guī)范會(huì)造成一定的問(wèn)題，就要立刻改正，不能裝傻充愣假裝看不見(jiàn)。
2， 新建團(tuán)隊(duì)開(kāi)發(fā)新的系統(tǒng)。新建的團(tuán)隊(duì)中團(tuán)隊(duì)成員可能來(lái)自不同的環(huán)境，對(duì)規(guī)范的選擇傾向一定是不完全一樣的，此時(shí)要怎么做呢？這時(shí)，項(xiàng)目的***應(yīng)該組織大家一起做一個(gè)決定，討論如何定義變量，如何給控件取名等等。在出現(xiàn)意見(jiàn)不統(tǒng)一又誰(shuí)都說(shuō)服不了誰(shuí)的情況時(shí)，項(xiàng)目經(jīng)理應(yīng)該做出明確的決定。此時(shí)選擇一種規(guī)范遠(yuǎn)比同時(shí)遷就兩個(gè)人要來(lái)的好，不然造成新系統(tǒng)中存在兩種規(guī)范，同樣是維護(hù)的噩夢(mèng)。
3， 穩(wěn)定團(tuán)隊(duì)開(kāi)發(fā)新的系統(tǒng)。這種情況就容易得多，團(tuán)隊(duì)穩(wěn)定后團(tuán)隊(duì)成員漸漸的了解了互相的習(xí)慣，互相學(xué)習(xí)后就更容易達(dá)成妥協(xié)。只要注意讓新加入的成員適應(yīng)就可以了。
有人可能覺(jué)得代碼規(guī)范沒(méi)什么大不了，功能正確沒(méi)有bug不就行了？當(dāng)然，如果沒(méi)有bug那肯定沒(méi)問(wèn)題，然而一個(gè)系統(tǒng)運(yùn)行到退休還沒(méi)有bug，哪位見(jiàn)過(guò)呢？我做了一些運(yùn)維工作之后才漸漸了解到，不同風(fēng)格的代碼讀起來(lái)就像是一會(huì)兒在赤道，一會(huì)兒在南極，非常的痛苦，有時(shí)甚至?xí)斐上到y(tǒng)很多的不一致，大大增加了維護(hù)的工作量。我們的目標(biāo)之一不就是增加系統(tǒng)的可維護(hù)性嗎？
?。ㄎ澹?review和重構(gòu)
說(shuō)到review，有些筒子可能立刻就想到了：吵架。確實(shí)，有的時(shí)候review真的可能演變成吵架，但是我們?yōu)榱隧?xiàng)目的成功，這個(gè)風(fēng)險(xiǎn)一定要冒，慢慢成熟以后，被人批評(píng)的次數(shù)多了，臉皮厚點(diǎn)兒就好了。；）玩笑歸玩笑，review確實(shí)是需要技巧的：在review別人的代碼時(shí)，要注意你的話語(yǔ)有時(shí)會(huì)傷害別人的自尊心，讓別人覺(jué)得你是在雞蛋里頭挑骨頭；在別人review你的代碼時(shí)，同樣的你也會(huì)覺(jué)得別人是在雞蛋里頭挑骨頭，傷害你的自尊心。這里我也沒(méi)有太多的技巧可言，一句話，換位思考，臉皮厚點(diǎn)兒吧。哈。
Review可能分成以下幾種：
1， 設(shè)計(jì)的review。說(shuō)起review大家更多想到的是大家坐在一起邊侃大山邊看別人的代碼，其實(shí)設(shè)計(jì)的review是更加重要的和更加高級(jí)的，也是更有價(jià)值的，問(wèn)題發(fā)現(xiàn)的早解決的代價(jià)就小嘛。在review別人或者自己的設(shè)計(jì)時(shí)，我們都能學(xué)到別人的設(shè)計(jì)理念，方法和技巧，這能大大提高團(tuán)隊(duì)成員的能力。項(xiàng)目中的技術(shù)牛人，項(xiàng)目經(jīng)理和技術(shù)骨干應(yīng)該作為設(shè)計(jì)review的主力人員，多多談?wù)勛约旱目捶?；同時(shí)也要注意尊重設(shè)計(jì)者的感情，讓大家都有收獲的同時(shí)，把項(xiàng)目做好。
2， 代碼的review。代碼review的形式可以多種多樣，兩個(gè)人坐在一起看看代碼也是一種review，也沒(méi)有必要非得所有人都湊齊。Review代碼的可以讓自己迅速成長(zhǎng)，也能讓項(xiàng)目組成員熟悉別人的業(yè)務(wù)和代碼，以***程度減少人員變動(dòng)造成的損失；同時(shí)也能讓代碼規(guī)范更加一致。
不管是設(shè)計(jì)review還是代碼review，都不一定要全部人員到場(chǎng)，這可能會(huì)浪費(fèi)一些時(shí)間；但是設(shè)計(jì)的review最少要有一個(gè)技術(shù)骨干或者項(xiàng)目經(jīng)理在場(chǎng)，否則review就會(huì)變成討論會(huì)進(jìn)而升級(jí)成戰(zhàn)爭(zhēng)。
Review有時(shí)候也會(huì)被認(rèn)為浪費(fèi)時(shí)間，特別是很多程序員對(duì)review別人的代碼沒(méi)有任何興趣，也不愿意讓別人對(duì)自己的代碼說(shuō)三道四。我想說(shuō)，作為一個(gè)二十一世紀(jì)的軟件工程師，我們不但要善于對(duì)技術(shù)進(jìn)行鉆研，更要善于把自己的技術(shù)傳播出去，也要善于通過(guò)別人的指點(diǎn)更快的提高自己的工作能力。這是一個(gè)開(kāi)放的時(shí)代，是一個(gè)需要交流的時(shí)代，是一個(gè)迅速發(fā)展的時(shí)代，你慢，就就完蛋。
在review發(fā)現(xiàn)了很多問(wèn)題之后，我們要怎么辦呢？對(duì)，重構(gòu)。這幾年重構(gòu)這個(gè)詞已經(jīng)非常的火了，大家都說(shuō)重構(gòu)很重要，但是又有幾個(gè)人真正的去重構(gòu)呢？有幾個(gè)人真正的不允許自己寫(xiě)重復(fù)代碼呢？大家是不是還在說(shuō)：“項(xiàng)目schedule太緊了，等有空了再優(yōu)化吧”？我認(rèn)為，這句話是有問(wèn)題的，項(xiàng)目的總時(shí)間短，任務(wù)重，我們沒(méi)辦法；但是優(yōu)化（重構(gòu)）卻不會(huì)增加這種時(shí)間的壓力，相反的，重構(gòu)會(huì)大大減少后續(xù)的開(kāi)發(fā)和debug時(shí)間。因?yàn)橹貥?gòu)后，出現(xiàn)的bug更容易被定為，更容易被fix；相反垃圾代碼引起的debug和fix bug的時(shí)間將遠(yuǎn)遠(yuǎn)大于重構(gòu)的時(shí)間。
原文鏈接：http://www.cnblogs.com/wisdomsoft/archive/2011/08/16/2140148.html
【編輯推薦】
