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