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

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

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

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

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

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

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

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

管理資料

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

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

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

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

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

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

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

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

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

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