@左耳朵耗子：聰明的程序員使用50%-70%的時(shí)間用來思考，嘗試和權(quán)衡各種設(shè)計(jì)和實(shí)現(xiàn)，而用30% – 50%的時(shí)間是在忙碌著編碼，調(diào)試和測(cè)試。聰明的老板也會(huì)讓團(tuán)隊(duì)這樣做。而 的老板，苦逼的程序員會(huì)拿出來100%-150%的時(shí)間來忙著趕進(jìn)度，返工，重構(gòu)，fix 大量的bug… 所以， 越差的團(tuán)隊(duì)一般會(huì)越忙，而且還忙不完。

    在現(xiàn)在這個(gè)浮躁的時(shí)期，再加上敏捷咨詢師們念的歪經(jīng)，他們讓人感覺上就像是軟件產(chǎn)品是可以在很短的時(shí)間內(nèi)高質(zhì)量的完成的，這令那些管理者們很興奮，就像巴甫洛夫的條件反射實(shí)驗(yàn)中的狗看到了肉就會(huì)流口水那樣興奮。他們使用TDD，快速迭代，不斷重構(gòu)，持續(xù)集成直至持續(xù)部署的方法在進(jìn)行軟件開發(fā)。

    軟件開發(fā)真是這樣的嗎？難道不需要花時(shí)間去思考嗎？對(duì)此，有些觀點(diǎn)在Todd的《“品質(zhì)在于構(gòu)建過程”嗎？》以及《Bob大叔和Jim Coplien對(duì)TDD的論戰(zhàn)》中談到過了。我只想想表達(dá)下面的觀點(diǎn)：

軟件的精髓在于設(shè)計(jì)，設(shè)計(jì)是一件很費(fèi)大腦的事件。對(duì)于軟件來說，設(shè)計(jì)沒有完美的，它總是一件需要取舍需要權(quán)衡的事，比如：時(shí)間換空間，空間換時(shí)間，TCP或UDP，同步還是異步，數(shù)據(jù)冗余還不冗余等等。那怕是一個(gè)小小的observers模式是pull方式還是push方式 都需要仔細(xì)討論。這些的東西需要時(shí)間和做前期嘗試。

TDD、快速原型和迭代可能會(huì)對(duì)軟件和團(tuán)隊(duì)產(chǎn)生負(fù)面影響。在一開始，你需要花很大的精力來讓你的軟件從無到有（做過軟件的人都知道，從零開始寫代碼是很痛苦的事），但是因?yàn)槟銢]有想好，先做再說，所以，后期你會(huì)面臨更多的質(zhì)量問題而讓你需要花更多的時(shí)間精力。當(dāng)然，那些咨詢師會(huì)讓你用持續(xù)集成和持續(xù)部署這樣的方法。但我想告訴你，這并不解決你軟件設(shè)計(jì)的缺陷。舉個(gè)例子——TDD、迭代、原型只關(guān)注功能性需求，其不會(huì)關(guān)注非功能性需求，比如性能問題，高可用性問題，系統(tǒng)維護(hù)問題（模塊的耦合問題），等等。而這些問題往往都可以讓你的軟件設(shè)計(jì)重新來過。

重構(gòu)是惡夢(mèng)，重構(gòu)應(yīng)該越少越好。當(dāng)你維護(hù)一個(gè)復(fù)雜的系統(tǒng)時(shí)你會(huì)知道重構(gòu)是一件多么恐怖的事情（參看《重構(gòu)代碼的7個(gè)階段》）。如果一開始沒有想好，你要面臨的不單單是re-design, re-architect，還要面對(duì)時(shí)間和人力成本的增加，最難的是你還要面對(duì)的是團(tuán)隊(duì)士氣因?yàn)椴粩嗟膔ework而逐漸低落并產(chǎn)生厭倦和懈怠情緒。

    所以，如果你能有多一些時(shí)間去和客戶討論一下需求和未來可能的變化，去調(diào)查一下實(shí)現(xiàn)的技術(shù)難點(diǎn)和細(xì)節(jié)，去和其他有經(jīng)驗(yàn)的人討論并推敲一下架構(gòu)和設(shè)計(jì)，去思考設(shè)計(jì)上的缺陷，那么，你的coding會(huì)變得非常地直，直到你一眼就看到盡頭，你的測(cè)試案例也會(huì)寫得非常地好，你會(huì)幾乎不需要重構(gòu)，于是，你會(huì)在未來少寫很多代碼，從而你的軟件開發(fā)會(huì)越來越輕松，直到技術(shù)開始換代。

    我現(xiàn)在在做的項(xiàng)目，花了幾乎4個(gè)月的時(shí)間來做設(shè)計(jì)，在這個(gè)過程中，我們反復(fù)思考、討論和權(quán)衡若干種實(shí)現(xiàn)方法，并盡可能地窮舉所有的場(chǎng)景和細(xì)節(jié)以及未來可能的變化（那怕是那些簡(jiǎn)單的模塊），有個(gè)模塊被重寫了至少三次，每次都是寫到一半就被推翻重寫，我們整個(gè)團(tuán)隊(duì)不斷地在和其它團(tuán)隊(duì)討論，并在對(duì)系統(tǒng)不斷地認(rèn)識(shí)中對(duì)系統(tǒng)進(jìn)行簡(jiǎn)化和優(yōu)化，并力求達(dá)到完美，

管理資料

    這就好像我們修路造橋一樣，我們需要花大量的時(shí)間勘測(cè)地形地質(zhì)，分析數(shù)據(jù)，思考可能出現(xiàn)的各種問題（各種自然災(zāi)害），評(píng)估不同的設(shè)計(jì)方案，而不是先盡快建好再說。

    所以，多一些時(shí)間，不是讓你多做幾次迭代，多完成幾個(gè)模塊，而是可以讓你少寫一些代碼，更快的交付一個(gè)更好的產(chǎn)品。

    我相信你會(huì)有很多疑問，下面是我覺得你可能會(huì)有下面的一些觀點(diǎn)，讓我一條一條來回復(fù)：

首當(dāng)其沖的一定會(huì)是項(xiàng)目的deadline，或是那種你沒有活語權(quán)的項(xiàng)目。比如做那種“甲乙方合同式的項(xiàng)目”，我把這種項(xiàng)目統(tǒng)一認(rèn)為是“外包項(xiàng)目”，在這種項(xiàng)目性質(zhì)下，你很難有話語權(quán)。對(duì)此，我覺得，1）作為乙方的你還是應(yīng)該和甲方在項(xiàng)目計(jì)劃上爭(zhēng)取一下，曉之以情，動(dòng)之以理。2）如果不行，只能在時(shí)間、需求范圍和質(zhì)量上做一個(gè)權(quán)衡。另外，在這種情況下你要找一個(gè)方法，把你的壓力和痛苦分擔(dān)給用戶和領(lǐng)導(dǎo)。（找到這個(gè)方法的前提需要你找到用戶和領(lǐng)導(dǎo)他們害怕什么，嘿嘿）

過度設(shè)計(jì)和紙上談兵。有人說會(huì)不會(huì)設(shè)計(jì)太多，造成過度設(shè)計(jì)，或是在設(shè)計(jì)上花太多的時(shí)間。這有可能。我上一家公司的一個(gè)項(xiàng)目團(tuán)隊(duì)就花了1年多的時(shí)間來不停不停的開會(huì)和做設(shè)計(jì)，結(jié)果release的時(shí)候還有1000多個(gè)bug。這個(gè)問題的原因是，這個(gè)團(tuán)隊(duì)的設(shè)計(jì)是在紙上談兵，開會(huì)是開神仙會(huì)，討論的設(shè)計(jì)都是浮云。所以，設(shè)計(jì)并不是討論和思考，還需要去嘗試，我認(rèn)為當(dāng)你的設(shè)計(jì)完成的時(shí)候，你的骨干核心代碼都基本完成了。

我的團(tuán)隊(duì)成員水平太差，不會(huì)思考。首先，先恭喜你找到一堆碼農(nóng)，當(dāng)然，這不怪你，這是中國教育和大環(huán)境的問題，讓人不會(huì)思考。對(duì)于這樣的情況，我有兩個(gè)建議，1）量力而行，使多大的碗就吃多少飯。2）鼓勵(lì)思考，那怕那些想法很不靠譜，因?yàn)槿绻�不開始，那么將永遠(yuǎn)不會(huì)思考。

必需使用快速迭代。很多公司都在強(qiáng)行上敏捷，他們希望產(chǎn)品越快release越好，而沒有充分的時(shí)間思考和討論。對(duì)于這種項(xiàng)目，我的建議是，1）找有豐富經(jīng)驗(yàn)的人來做。2）迭代過程中力求架構(gòu)和程序邏輯的簡(jiǎn)單，簡(jiǎn)單，再簡(jiǎn)單，力求代碼間的高內(nèi)聚，低耦合。不然，重構(gòu)的時(shí)候你就好玩了。

創(chuàng)業(yè)團(tuán)隊(duì)必需要快。做得快就是做得好嗎？很多時(shí)候，不是誰快誰就能笑到最后的。這樣的例子太多了。第一個(gè)做出來的人并不一定就會(huì)占領(lǐng)市場(chǎng)，其很有可能會(huì)成為先驅(qū)。

有錢的公司才會(huì)讓團(tuán)隊(duì)用更多的時(shí)間去思考。錯(cuò)了，你們沒有見過有錢的公司，有錢的公司可以招一堆干不成活的人，可以把事搞亂了再新來過，甚至可以把做失敗的項(xiàng)目換個(gè)名字再重新立項(xiàng)。這些真正的有錢的公司只求快，只求人多，不怕做錯(cuò)決定。像我們這些沒錢的人，干什么事都是小心翼翼地，生怕做錯(cuò)決定。

    關(guān)于軟件項(xiàng)目管理的文章，還可以參看《軟件公司的兩種管理方式》，最后，歡迎大家表達(dá)觀點(diǎn)。