引入變革的建議方式，先把團隊的目標、痛點、瓶頸點整理出來，以終為始，重點是達到目標、改善瓶頸、消除痛點，而使用何種方式只是達成目標的一種手段或工具。避免賣弄名詞，追逐 buzzword。捲起袖子，加入團隊跟大家一起幹，從行動的過程中去影響團隊，讓大家體認實踐的核心精神。
因此有蠻多人為了測試方便，就將原本 SUT 的待測程式抽了幾個 private function，並直接透過這類 API 的內容撰寫測試，因為顆粒度很小，就誤以為這叫做「單元測試」。
這篇文章將說明，為什麼我不建議你「直接針對 private function 」進行測試。
這個世界唯一不變的，就是「不斷在變」。
「生存能力」考驗的是「適應變化的能力」，如何以小博大？靠的就是適應變化、掌握變化、創造變化，讓大企業跟不上變化的速度，讓「變化」成為「大衛王」手裡用來擊敗「巨人歌利亞」的石子。
而這，也是敏捷的本質，也是《反脆弱》一書中所強調：適應變化，並且從變化中獲得競爭優勢，進而進化自己的能力與體質。
Fake it till you make it，大家一般聽過這句話，卻不知道在實際程式開發過程中是什麼模樣。這裡用大家熟悉的 tennis，但刻意將所有產品程式碼的判斷跟結果都寫死，來練習一下如何重構成真實商業邏輯吧。
巢狀的 if/else block 在實務 legacy 產品上履見不鮮，在很多時候其實可以用多型的設計來取代這些重複的判斷式。
低谷，基本上就是進入門檻，門檻越高，越難通過，通過後從稀缺性所獲得的價值就更大。那麼該如何選擇戰場，發揮自己獨特的價值呢？
讓大家依據實務需求完成代碼、加入單元測試、code review 、code smells 辨識，且依照成員的 legacy code 現場示範重構並指導練習重構、測試案例探索/分群/排序、邏輯樹拆分、TDD 循環與 baby step、迭代堆砌產品代碼增量。
生產力 = 你的設計功力（能力） + 最佳化開發環境與設定（神兵） + 對的開發方式（招式）
【極速開發】就是用來解決實務上大家總說「時間不夠」的問題，因為時間不夠，所以我沒法子寫單元測試，沒法子重構，沒法子 TDD，沒法子 code review，沒法子把事情作到最好。
我認同「時間不夠」是個問題，然而卻很少人去改善或解決這個問題。各位將會從此學到，如何建立自我刻意練習的模型，將所有工具的整合起來發揮最大綜效，透過正確的開發方式與順序，讓你寫代碼時能行雲流水，並且兼顧設計、品質與生產力。
單元測試是開發軟體產品過程中，與品質、設計相關最重要的基本工程實踐，如果不會單元測試，很多重構無從下手。如果不會單元測試，無法駕馭測試驅動開發。
單元測試是開發軟體產品過程中，與品質、設計相關最重要的基本工程實踐，如果不會單元測試，很多重構無從下手。如果不會單元測試，無法駕馭測試驅動開發。