假如你是一個Leader，那么你敢對你的自己的項目Refactor嗎？當然我這兒所說的Refactor不是僅僅修改幾個Class而已，而是將舊有的框架完全拋棄，而建立一個全新的框架。你能面對Release的壓力，還有項目成敗的挑戰嗎？
當一個Project越來越大，Logic越來越復雜的時候，就有的框架體系往往不能滿足新Feature的要求，于是程序員們有兩種選擇，要么重構，要么打補丁。對于后者，如果開發人員水平高一點，補丁的痕跡還不會很明顯，如果水平一般的話，這段代碼往往就會形成一個惡夢。久而久之，整個項目都會積重難返，直至崩潰。
很幸運的是，我所在的Team從一開始就定位于堅持Refactor。基本上每個MileStone，都會有1-2個人手上的活不是new feature，而是refactor。也許剛剛開始refactor的時候會無從下手，畢竟很大的一塊，不是說動就動的。但是不管怎么樣，refactor之后的效果是顯而易見的，新的擴展很容易實現，往往只要覆寫某個方法就可以實現一個新的feature。磨刀不誤砍柴工，refactor很好的詮釋了這一點。
看過《重構》這本書的人，都會知道重構須從小處做起，不斷堅持，但這樣的重構也只僅僅局限于某些功能點的重用性而已。真正的重構，是需要大刀闊斧的。一個項目，你很難知道后期的行為，因此代碼框架也很難一直適應新的需求。當需求不斷變更的同時，如果固步自封，渾身打上狗皮膏藥，補丁越多，維護越累。當量變達到質變的時候，也就是項目崩潰的時候。只有堅持對框架進行調整，才能夠不斷的滿足新的需求。
說到這兒就不得不說到團隊間的合作問題，一個產品，往往是由幾個Team共同協作完成的。基本上每個Team都只需要負責自己的模塊，并且根據工作量的大小有相應的人手。那么你認為在這兒Team之間，大家工作的感覺會想差不多嗎？實際上，每個Team內部的情況完全不一樣，有的Team，一個人平均每天只能該1個Bug，有的Team能夠該3-5個。歸根結底，還是由于框架的問題。如果框架結構清晰明了，改起來自然簡單，往往一行代碼的修改就能解決問題。框架結構復雜的話，那就不好收拾了。框架的作用就是增加重用性，降低耦合度。我們這兒有一個Team，框架3年都沒有什么改變了，而且由于人員的更迭，很多代碼都和黑盒一樣，沒有人能夠看明白。我敢說，我一天改10個Bug都不在話下，他們能說嗎？
一個Leader要維護Team之間的平衡真得很累，結構好了，自然就做的快了，可那又不是自己的錯，做得慢的Team不但拖累自己，到頭來還硬要說你出風頭。開發人員第一個需要擁有的素質就是能夠不斷自省，要學會先懷疑自己。把所有的責任都推卸出去了，到最后問題沒解決那還是自己的。一個項目的成敗也往往是由Leader的管理水平來決定的。如果Leader都怕失敗，不敢去承擔責任，那么手下的人自然也沒有這個義務了。
我只想說一句，不敢對自己現有的框架體系做出挑戰的，不能夠自省的Leader，都是對自己的項目，自己的手下不負責任。一個項目最終的成敗，也可能就毀在這些人手上。