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