“程序”一聽代碼這倆個字，大多人第一反應就是程序員了，也令很多人毛骨悚然。有人說：“聰明的程序員使用50%-70%的時間來總結(jié)和思考，為提高工作效率而思考，而用30%–50%的時間做好自己的本分，調(diào)試和測試。而愚蠢的程序員會拿出100%-150%的時間來忙著趕進度，返工，重構(gòu)，fix大量的bug…所以，越差的團隊一般會越忙，而且還忙不完。”所以不管你是從事什么行業(yè)，都要懂得去思考。
在現(xiàn)在這個浮躁的時期，再加上敏捷咨詢師們念的歪經(jīng)，他們讓人感覺上就像是軟件產(chǎn)品是可以在很短的時間內(nèi)高質(zhì)量的完成的，這令那些管理者們很興奮，就像巴甫洛夫的條件反射實驗中的狗看到了肉就像流口水那樣興奮。他們使用TDD，快速迭代，不斷重構(gòu)，持續(xù)集成直至持續(xù)部署的方法在進行軟件開發(fā)。
軟件開發(fā)真是這樣的嗎？難道不需要花時間去思考嗎？對此，有些觀點在Todd的《“品質(zhì)在于構(gòu)建過程”嗎？》以及《Bob大叔和Jim Coplien對TDD的論戰(zhàn)》中談到過了。我只想想表達下面的觀點：
?軟件的精髓在于設(shè)計，設(shè)計是一件很費大腦的事件。對于軟件來說，設(shè)計沒有完美的，它總是一件需要取舍需要權(quán)衡的事，比如：時間換空間，空間換時間，TCP或UDP，同步還是異步，數(shù)據(jù)冗余還不冗余等等。那怕是一個小小的observers模式是pull方式還是push方式都需要仔細討論。這些的東西需要時間和做前期嘗試。
?TDD、快速原型和迭代可能會對軟件和團隊產(chǎn)生負面影響。在一開始，你需要花很大的精力來讓你的軟件從無到有（做過軟件的人都知道，從零開始寫代碼是很痛苦的事），但是因為你沒有想好，先做再說，所以，后期你會面臨更多的質(zhì)量問題而讓你需要花更多的時間精力。當然，那些咨詢師會讓你用持續(xù)集成和持續(xù)部署這樣的方法。但我想告訴你，這并不解決你軟件設(shè)計的缺陷。舉個例子——TDD、迭代、原型只關(guān)注功能性需求，其不會關(guān)注非功能性需求，比如性能問題，高可用性問題，系統(tǒng)維護問題（模塊的耦合問題），等等。而這些問題往往都可以讓你的軟件設(shè)計重新來過。
?重構(gòu)是惡夢，重構(gòu)應該越少越好。當你維護一個復雜的系統(tǒng)時你會知道重構(gòu)是一件多么恐怖的事情（參看《重構(gòu)代碼的7個階段》）。如果一開始沒有想好，你要面臨的不單單是re-design, re-architect，還要面對時間和人力成本的增加，最難的是你還要面對的是團隊士氣因為不斷的rework而逐漸低落并產(chǎn)生厭倦和懈怠情緒。
所以，如果你能有多一些時間去和客戶討論一下需求和未來可能的變化，去調(diào)查一下實現(xiàn)的技術(shù)難點和細節(jié)，去和其他有經(jīng)驗的人討論并推敲一下架構(gòu)和設(shè)計，去思考設(shè)計上的缺陷，那么，你的coding會變得非常地直，直到你一眼就看到盡頭，你的測試案例也會寫得非常地好，你會幾乎不需要重構(gòu)，于是，你會在未來少寫很多代碼，從而你的軟件開發(fā)會越來越輕松，直到技術(shù)開始換代。
我現(xiàn)在在做的項目，花了幾乎4個月的時間來做設(shè)計，在這個過程中，我們反復思考、討論和權(quán)衡若干種實現(xiàn)方法，并盡可能地窮舉所有的場景和細節(jié)以及未來可能的變化（那怕是那些簡單的模塊），有個模塊被重寫了至少三次，每次都是寫到一半就被推翻重寫，我們整個團隊不斷地在和其它團隊討論，并在對系統(tǒng)不斷地認識中對系統(tǒng)進行簡化和優(yōu)化，并力求達到完美?，F(xiàn)在看來，沒有貿(mào)然使用Scrum是明智的。
這就好像我們修路造橋一樣，我們需要花大量的時間勘測地形地質(zhì)，分析數(shù)據(jù)，思考可能出現(xiàn)的各種問題（各種自然災害），評估不同的設(shè)計方案，而不是先盡快建好再說。
所以，多一些時間，不是讓你多做幾次迭代，多完成幾個模塊，而是可以讓你少寫一些代碼，更