兩天的Agile培訓

    這周5和周6參加了兩天公司組織的Agile相關知識的培訓，對Agile的認識比以前更多了一些。初次接觸Agile大概在四五年前，大約是剛上研究生的時候。在學校的圖書館中看到了敏捷開發和極限編程(XP)等字眼的書，當時沒太在意，感覺自身的專業方向不搭邊，隨便翻翻看，發現也沒怎麼看懂，囧。
     從這幾年的工作經驗來開，當時沒看懂是應該的，看懂了纔是怪事。Agile的開發模式需要有相當經歷的開發經驗的人才能夠理解，因爲這是一個“草根”的開發模式，或者說做事哲學。
         1. Agile是什麼?
                很難對Agile有個明確的定義說明什麼是Agile的，什麼不是Agile的。Agile從出生開始即是爲了解決軟件開發中過重的開發模式而誕生的，爲了減少文檔驅動的開發模型中反饋週期過長，難以應對需求變化而誕生的。它是針對這些缺點而提出的改進方式。Agile的哲學是“結果是最重要的，所有的過程手段都是爲結果服務的；如果過程導致結果不理想，那就改進這個過程”。因此，Agile的開發模式是一個逐漸改進的方式，直到Team能夠應付不斷的需求變化，能夠快速響應，能夠快速的給客戶創造價值。我的理解：能夠滿足上述要求的開發模式都可以認爲是Agile的。
         2. 文檔驅動 VS 測試驅動
               常規的開發模式是以文檔驅動的。需要有很詳細的需求文檔，根據需求文檔進行初始設計、詳細設計，然後是編碼實現和測試。這種模式有其優點存在，比較適用於需求變化不是很大，變化速度不快的項目，典型的例子就是軍方的武器系統的開發。但這種模式對民用軟件行業，特別是互聯網行業的項目而言就顯的太沉重了，基本上完全不能快速的響應政策、市場和客戶的變化。
                Agile提出了以測試驅動的開發模式。Agile中的測試強調自動化的單元測試和自動化的集成測試。以大量的可以自動化運行的單元測試保證任何微小的改動在check in代碼庫中之前都是邏輯正確的，自動化的集成測試則可以保證不同模塊之間的漏洞能夠儘早的發現，能夠儘早的fix bug，減少後期修改bug的成本。
              Agile的開發模式中，是測試先行的方式。它的特點如下：
              首先根據User Story編寫測試代碼，然後根據測試代碼的要求完成邏輯代碼。在這個階段不關注邏輯代碼的任何編碼標準和規範，也不關注代碼性能，以最小的時間代價實現正確的功能爲終極目標。完成後開始運行測試代碼，直到所有的測試點都通過。
              完成上述任務後，我們就已經初步擁有了一個可以正常運行，完成核心功能的系統了，這時候可以讓客戶參與進來，和客戶確認做出來的東西是不是真的是用戶需要的。與此同時，開發team需要對代碼進行重構，每次重構都需要進行所有的測試代碼進行測試，保證重構後不會引入新的bug。好的代碼結構是不停重構出來的。
        3. Agile與技術架構的矛盾
             Agile要求迅速響應變化，但變化經常給原有的設計帶來挑戰。Agile並不是不要設計直接進行開發，Agile模式仍然是需要一定的預先設計的。特別是系統的核心，如數據存儲是DB還是文件系統，而且這些核心設計是不能夠被推翻的，否則代價巨大不可接受。