多些時間能少寫些代碼（轉自酷殼 – CoolShell.cn）

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

@左耳朵耗子：聰明的程序員使用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）迭代過程當中力求架構和程序邏輯的簡單，簡單，再簡單，力求代碼間的高內聚，低耦合。否則，重構的時候你就好玩了。

• 創業團隊必須要快。作得快就是作得好嗎？不少時候，不是誰快誰就能笑到最後的。這樣的例子太多了。第一個作出來的人並不必定就會佔領市場，其頗有可能會成爲先驅。

• 有錢的公司纔會讓團隊用更多的時間去思考。錯了，大家沒有見過有錢的公司，有錢的公司能夠招一堆幹不成活的人，能夠把事搞亂了再新來過，甚至能夠把作失敗的項目換個名字再從新立項。這些真正的有錢的公司只求快，只求人多，不怕作錯決定。像咱們這些沒錢的人，幹什麼事都是當心翼翼地，生怕作錯決定。

關於軟件項目管理的文章，還能夠參看《軟件公司的兩種管理方式》，最後，歡迎你們表達觀點。

（全文完）