我在我的微博上說(shuō)過(guò)這樣一段話，我想在這里把我的這個(gè)觀點(diǎn)闡述地更完整一些。

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

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

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

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

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

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

　　所以，如果你能有多一些時(shí)間去和客戶討論一下需求和未來(lái)可能的變化，去調(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ì)在未來(lái)少寫很多代碼，從而你的軟件開(kāi)發(fā)會(huì)越來(lái)越輕松，直到技術(shù)開(kāi)始換代。

　　我現(xiàn)在在做的項(xiàng)目，花了幾乎4個(gè)月的時(shí)間來(lái)做設(shè)計(jì)，在這個(gè)過(guò)程中，我們反復(fù)思考、討論和權(quán)衡若干種實(shí)現(xiàn)方法，并盡可能地窮舉所有的場(chǎng)景和細(xì)節(jié)以及未來(lái)可能的變化（那怕是那些簡(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á)到完美。現(xiàn)在看來(lái)，沒(méi)有貿(mào)然使用 Scrum 是明智的。

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

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

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

• 首當(dāng)其沖的一定會(huì)是項(xiàng)目的 deadline，或是那種你沒(méi)有活語(yǔ)權(quán)的項(xiàng)目。比如做那種“甲乙方合同式的項(xiàng)目”，我把這種項(xiàng)目統(tǒng)一認(rèn)為是“外包項(xiàng)目”，在這種項(xiàng)目性質(zhì)下，你很難有話語(yǔ)權(quán)。對(duì)此，我覺(jué)得，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)他們害怕什么，嘿嘿）

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

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

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

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

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

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

it知識(shí)庫(kù)：多些時(shí)間能少寫些代碼，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。