最近跟團隊成員**tdd引入時，有許多見解，結合自己的一些體會，寫在下面
首先需要明確的一點是，技術是為商業服務的，哪怕技術再優秀，創造不了商業價值，那麼技術是沒有意義的
在這麼乙個前提下，我們再來考慮問題
1、是否應該一開始把**設計得很優秀（無解耦、擴容性強，高效能）？
這個是不必要的，如果公司的要求是3個月內完成專案，時間不夠了，還有啥精力放在**優化上。根據個人經驗，寫出優秀**是有成本代價的
2、面對業務的頻繁變化，如何應對過去趕時間出來的爛攤子？
爛攤子之所以爛，是因為這些爛攤子的可維護性差，這個時候採取的解決方法是重構，重構最怕引起的是**不穩定，最好的保證方案是有足夠的測試，這樣就不怕改。先重構再擴充套件功能，省事
上面兩點已經很好解答了tdd的意義，下面再做一些總結
1、集中時間在需要解決的問題上，而不是一味追求技術
2、降低維護的成本，提高維護的可控性
3、使用**幫助思考（集中精神在需要解決的問題上）
4、縮短測試週期
5、。。。（還有很多）
我認同的敏捷開發模式在以下幾點體現
1、良好的專案管理把控
2、團隊具有相互幫忙，相互學習的氣氛，善於溝通
3、架構支援短迭代的方式推動產品發展（如web應用不同板塊之間互不相關）
4、採取tdd模式提高工作效率
這些才是敏捷專案取勝的關鍵
對於龐然大物的開發，架構上面應該採取可模組拆分的系統模式（考慮一下linux的系統架構），對個別模組實在無法拆分且技術難度、規模及重要性高，採取傳統的開發流程如rup的方式，效果要比敏捷更好
我對TDD的實踐
上周五的討論又錯過了！真可惜。可是實在沒有辦法，最近忙的厲害。就是發表一篇blog也要趕在7 30之前，8 00監考，提前10分鐘進教室 不多說了，現在連會議記錄還沒有看完，還有寒楓天傷 wayfarer idior的文章也沒顧得上看。先把我去年的一部分教案放上來，就算對tdd的乙個補償吧。內容很簡...
對TDD原則的理解
1,在編寫好失敗的單元測試之前,不要編寫任何產品 如果不先寫測試,那麼各個函式就會耦合在一起,最後變得無法測試 如果後寫測試,你也許能對大塊大塊的 進行測試,但是無法對每個函式進行測試 先寫測試是進攻,後寫測試是防守 2,只要有乙個單元測試失敗了,就不要再寫測試 編譯失敗也是失敗 乙個地方漏水了就趕...
對商業智慧型BI的總結
涉足商業智慧型系統是在一次老總要一大堆報表後,當時老總要一大堆銷售報表和庫存報表,當時erp有報表,但是報表的形式比較單一,比如採購就是一張採購清單,從erp系統匯入到excel中,沒有經過任何加工,偶爾經過手工加工,還僅僅是對 商的考評,然而這花費採購部一mm忙活一大上午,才搞好一張 而且顯示出來...