爭辯一下：敏捷開發(fā)不是XP
其實敏捷開發(fā)也是最近幾年比較火的一個概念，和開源一樣，火歸火，在中國就是水土不服。要說原因，恐怕60%以上都會說，程序員素質(zhì)達不到XP的標(biāo)準(zhǔn)，其實每每看到這里我都很奇怪。我也試圖去跟別人溝通過敏捷的思想，但一說敏捷開發(fā)，一般對方都會說，著是個好東西，但是程序員素質(zhì)參差不齊，怎么搞什么結(jié)對編程啊。
敏捷，是敏捷，極限編程，是極限編程。敏捷不一定要極限編程，極限編程也不一定就是敏捷的（也可能是遲鈍的）。
在這篇文章里面，首先我打算分清楚這兩個概念，然后談?wù)勎业姆菢O限編程敏捷實踐。
正如剛才所說的，敏捷是一套軟件開發(fā)的理念和方法，并非特指某種編碼方式（XP），也不要求必須采取什么開發(fā)方式。其實在我看來，包括迭代在內(nèi)，也不是鐵板一塊，非如此不敏捷的。
敏捷開發(fā)的原則，理念，相信大多數(shù)人都能背出個N條出來，極限編程自然是敏捷思想的一個很好的貫徹，但如果條件不許可，比如說一堆應(yīng)屆畢業(yè)生，或者沒有你看得順眼的結(jié)伴對象，又何必去強求呢？
但，誰說不能搞極限編程就無法實踐敏捷了？
我記得我剛接觸極限編程的時候，覺得真是個好東西啊，要這么開發(fā)效率該多高啊，工資該漲個N倍吧，想著想著就一大堆哈喇子。想著以后要掌了權(quán)就要大刀闊斧，來人，給咱倆上XP。
但越干到后面越覺得不是那么回事，你看得上眼的人，看不上你，你看不上的人，怎么結(jié)對？找個人來結(jié)對編程，比找個GF更難，何況現(xiàn)在GF都還沒著落。
在這么多年的開發(fā)中，老實說也有過可以實踐XP的機會。那是一個潛質(zhì)很好的小弟，雖然我們還是有很多分歧，在OOD上還有很大的距離，但從OOP上的差距已經(jīng)不遠了?？上У氖?，公司可沒有打算讓你去XP，每天你除了編程，還要負責(zé)去跟別的部門吵架，搶資源，最后，還有幾個后進的同學(xué)要你帶呢。XP的事情最后還是不了了之。
這么多年下來，我越來越覺得，XP更像是一個美麗的女神，可遠觀而不可褻玩也。雖然一直有著沒有XP過的遺憾，但這些年我卻一直保持著敏捷的實踐。我教我的小弟們，先用代碼和注釋來確定自己的工作，比如說：
- public 給什么 干什么( 要什么 )
- {
- //TODO 第一步你打算怎么干
- //TODO 第二步你打算怎么干
- //...
- }
交給我審核后再去完形填空。
最后交叉代碼審核，所有看不明白的代碼全部發(fā)還重寫，如果說看明白了，又說不清所以然的重打四十。
由于一直實踐著敏捷開發(fā)，所以實際上這么些年都沒寫什么文檔，交叉的代碼審核很好的保證了代碼文檔化的貫徹。而預(yù)先的代碼模板則確保了先設(shè)計后編碼，保證了思路的條理清晰。
這比那些格式文檔少了很多廢話又最大限度內(nèi)降低了工作量。
但敏捷開發(fā)并不是說完全的拋棄文檔，我也設(shè)計過很多廢話很多的文檔，尤其是對于腦子經(jīng)常短路的小弟，有時候文檔、規(guī)范和流程能夠自動的提醒他：你想哪里去了。
但我永遠沒有在問題出現(xiàn)前就設(shè)計文檔，每次我的小弟工作出現(xiàn)了問題，我就給發(fā)明個文檔來保證他不再犯同樣的錯誤：
有一次漏掉了關(guān)鍵的需求，設(shè)計了需求確認表。
有一次忘了定時檢查服務(wù)器，設(shè)計了服務(wù)器檢查表，定期檢查，簽字負責(zé)。
有一次忘了把項目結(jié)束報告發(fā)給上頭，結(jié)果害得我們獎金沒按時給，發(fā)明了項目跟蹤表，告訴他公司的官僚部門需要你做些什么，一個個確認。
…………
……
諸如此類，不一列舉。
在問題出現(xiàn)前就加以杜防范，避免出現(xiàn)問題當(dāng)然是好的，但可能出現(xiàn)的問題成千上萬，你能都想到？又能都防住么？亡羊補牢，猶未晚矣。
文檔和規(guī)范是手段，是避免出現(xiàn)問題的方法，如果確認問題不會再出現(xiàn)，就可以撤掉這些影響程序員心情的東西。
所以我發(fā)明的那些文檔一般半年到一年就會逐漸廢止，因為那些東西通過長時間的重復(fù)，已經(jīng)成為他的習(xí)慣，這時候文檔就變成了一種強制性的負擔(dān)。。。
【編輯推薦】
