91 tdd 持續重構
Why so important?
目前公司有大量的外包專案與運行年限很久的程式碼，由於大部分程式未作Code Review或是未有自動化測試或單元測試(甚至文件缺失，往往到手上來的程式都已經具有一定的急迫性與問題性，除了架構設計缺失外，我希望能找尋一種合理的開發方式增加程式修改的可行性與正確性，會上這麼課是希望透過91在業界的開發與維護經驗，讓我找到一條在公司生存的路XD
What
這是一門兼顧需求分析、系統分析、tdd實戰與legacy code重構技巧的一門課，非常不建議直上這門課，沒有「極速開發」、「針對遺留代碼加入單元測試的藝術」打底的狀況下是非常吃力的，是一門超級重武裝火力展現的一門課。
課程上會從需求分析、發問、規劃編排、測試到開發一氣呵成，直指問題核心，讓你能理解與體會敏捷開發上的意義與想解決的問題。
這門課非常實做派，從需求分析、發問、規劃編排、測試到開發，91提點我們許多常犯的問題與需要重點關注的細節，尤其是發問，合理的發問方式與技巧往往都是建立業務邏輯Domain的關鍵；
規劃編排、測試到開發則是合理的收攏發散式開發造成的Feature（某人：bug就bug講什麼feature)，用一些案例與提問讓我們反思目前開發策略的合理性。
How
91讓我們從簡單的Tennis Kata開始，從需求分析到開發策略編排，設計了許多陷阱，讓我們從而發現目前專案執行或是思考的不足處，讓我們初步體驗TDD 開發的節奏與專案執行的Whole picture，讓我們體驗初步pair programming 的體驗與思路，正當覺得我可能可以做得還不賴的時候，91來個一記重拳，用計算日常成本的案例讓我們回到日常在公司開發的泥沼裡，91再拿著我們產出的屍體來證明平常開發習慣的不合理性，再用火力展現將專案重構成較易維護的樣子。
Where should I start?
上這門課以前會覺得TDD、重構這兩種技巧很學術，不容易運用在日常專案上(更多覺得不切實際吧，直到有一次發生專案程式因為安全性問題修改時，發生連帶相關不相關程式大規模的修改，意外造成更多不確定性因素時，才狠下心要克服這tdd 與 重構的技巧，目前透過網路更上更多的Kata練習相關技巧與多看幾次91推薦的書籍去學習，從而改善軟體開發的品質。
小結
其實這門課可以改名啦！應該叫做「程式設計師逃生實戰演練」，這門課幫助我克服專案處理上的恐懼與沮喪，利用科學化方法分析解構開發處理流程，找出問題點並改善，從建立單元測試降低開發專案風險，到合理分析編排開發方向降低複雜度，讓TDD不只是Test first那麼簡單的一句話而已，這門課能幫助開發人員安全找到迭代開發與重構的安全性，讓開發人員幫專案找到持續改善的一條路。
ＰＳ這次的課程，總結出未來需額外學習的方向
- 敏捷開發中的XP
- 敏捷式設計
- Design Sprint
