不過對於文章裡很多觀點我個人覺得都有值得推敲的地方。首先我感覺作者對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年前用wate***ll時好太多了。
高效程式設計師的特徵 聰明，懶惰
這裡我使用了聰明，懶惰和程式設計師這幾個詞。我說的這幾個詞的意思是 聰明 能夠周全的思考問題 不是那些耍小聰明的人 懶惰 就像是程式中的lazy loading，是指延後寫 的時間 而不是無所事事的人 正確的軟體開發應該是懶惰式開發，也被稱作忍耐式開發 這種開發方式的表現是，在真正動手寫 前，程式設...
高效程式設計師的特徵 聰明，懶惰
這裡我使用了聰明，懶惰和程式設計師這幾個詞。我說的這幾個詞的意思是 正確的軟體開發應該是懶惰式開發，也被稱作忍耐式開發 這種開發方式的表現是，在真正動手寫 前，程式設計師要花大量的時間通盤考慮所有可能的解決方案和途徑。這可以看作是延緩寫 在沒有完全理解問題前絕不動手寫 先把問題理解清楚，確保將要寫的...
高效的程式設計師是聰明和懶惰的
我之所以要用聰明和懶惰來形容高效的程式設計師，原因有以下幾點 聰明是因為能找出問題的正解 懶惰是因為不願寫多餘的 即不會長時間地坐在電腦前 好的軟體開發過程應該是懶惰的軟體開發，亦稱耐心開發，原因是開發人員在寫 之前會先將時間花在透徹地考慮各種解決方案上。這是懶惰開發的主旨，即在不了解之前就不會開始...