我在我的微博上說過這樣一段話，我想在這里把我的這個觀點闡述地更完整一些。

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

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

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

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

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

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

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

　　我現在在做的項目，花了幾乎4個月的時間來做設計，在這個過程中，我們反復思考、討論和權衡若干種實現方法，并盡可能地窮舉所有的場景和細節以及未來可能的變化（那怕是那些簡單的模塊）。有個模塊被重寫了至少三次，每次都是寫到一半就被推翻重寫，我們整個團隊不斷地在和其它團隊討論，并在對系統不斷地認識中對系統進行簡化和優化，并力求達到完美。現在看來，沒有貿然使用 Scrum 是明智的。

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

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

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

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

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

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

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

• 創業團隊必需要快。做得快就是做得好嗎？很多時候，不是誰快誰就能笑到最后的。這樣的例子太多了。第一個做出來的人并不一定就會占領市場，其很有可能會成為先驅。

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

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