聪明的程序员使用50%-70%的时间用来思考

       不過對于文章里很多觀點我個人覺得都有值得推敲的地方。首先我感覺作者對Agile有些誤解。下面把我的觀點一一道來。


　　軟件開發真是這樣的嗎？難道不需要花時間去思考嗎？


　　Agile里定義的開發應該不止是Coding吧？研究，計劃，設計都是開發活動。用Agile不是說把所有開發活動都變為Coding了。


　　TDD、快速原型和迭代可能會對軟件和團隊產生負面影響。一開始，你需要花很大的精力來讓你的軟件從無到有（做過軟件的人都知道，從零開始寫代碼是很痛苦的事），但是因為你沒有想好，先做再說，所以，后期你會面臨更多的質量問題而讓你需要花更多的時間精力。。。TDD、迭代、原型只關注功能性需求，其不會關注非功能性需求，比如性能問題，高可用性問題，系統維護問題（模塊的耦合問題），等等。而這些問題往往都可以讓你的軟件設計重新來過。


　　同理，如果你把研究計劃設計定義都算為Agile里的開發，這個論點的依據就不成立了。此外還有一個我覺得普遍的觀點就是傳統開發由于計劃周全，所以后期出現的意外質量問題少。其實很多問題早期設想根本不可能看到，只有實際deploy后才會發現。而如果從0到開始部署周期太長的話問題會出現的很晚，解決起來更痛苦。


　　重構是惡夢，重構應該越少越好。


　　我個人反而喜歡重構。比如以前寫了10個method現在重新設計為3個，或者基本沒什么變化但是變量，縮進設計和method安排使得代碼可讀性更高了，其實都是增加了價值。我覺得代碼就要經常重構，大的或者小的。這樣才能改進產品和個人能力。當然一般的老板意識不到重構也是做產品。本人是Clean Code和Beatiful Code這兩本書的忠實執行者。


　　所以可能對重構的抵觸也是和Agile不兼容的原因之一？但是很多傳統的開發方式不是避免了重構，而是把重構的成本變的很高所以公司會選擇能拖則拖，最后technical debt越滾越大。


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


　　我們公司用的是scrum。在寫新系統的時候，大部分任務都是investigate，或是benchmark不同的solution，或是按照想法做demo。可見我們花在計劃上的時間也不少。所以這個和你用不用敏捷是無關的，而是思考和計劃在公司里的位置。


　　最后聲明一下，我對Agile的知識都是在公司里工作學來的，沒怎么看過理論。而公司里用的是Scrum。我個人對開發方法沒什么喜好，什么管用用什么。但是我們公司開發情況比2年前用Waterfall時好太多了。