上周參加了一次TDD的開發培訓，敏捷教練演示如何通過測試驅動出求質數的公式，借此向我們展示了TDD的巨大魅力。
"紅燈-綠燈-重構"的開發節奏為我們開啟了另外一條軟件開發的思路，從底往上推導出整體業務邏輯。而我們傳統的開發思維里總是要先進行頂層的業務設計，然后分解有多少業務接口，從上往下進行。兩種模式當然互有利弊，TDD看上去更加的直觀，更能讓人感覺與正確性相關，讓程序沒有BUG、有完善的測試保護、再也不用當心重構會影響原有的業務邏輯。
有感于次此，回來的時候我們組織了一個代碼編程比賽，借此向開發介紹單元測試的重要性，以及簡單重構的好處。簡單的套用了一個教練提供的網球比賽列子，為了增加一些難度，增加了幾個復雜的case，對代碼行數做了限制。在花了15分鐘給開發門簡單的介紹了一下比賽的規則后比賽開始。特意把比賽開始的時候定在的周5的下班后，希望大家周末有時間可以去找找資料，有更多的時間去反復重構代碼，且不占用工作時間。
結果很意外，30分鐘后，便有一位開發完成了任務， 還是一位沒有參加TDD的人（原來沒有練習過）。采用了類似窮舉法的方式，將20個結果弄成一個數組，然后通過一個TDD的方式推導出了一個很牛逼的函數，將結果返回回來。于推廣的意義來說 我覺得違背了我本來的意圖，但對于比賽規則說，確實有效的。那么問題來了，在敏捷的模式里是否代碼功能達到要求就認為是一個好的設計？
聯想到我們敏捷的開過過程中，我們經常糾結的一個問題：簡單夠用的標準在哪里。在傳統的開發模式中，我們總是被要求或則要求別人需要為代碼后續維護做準備，尤其是在一些存在研發和實施由兩撥人來做的公司。作為產品研發團隊的人，總是在想未來變化的點在哪里，我該如何的設計才能滿足需求。而在敏捷的開發環境中，總是強調MVP,強調盡快的交付。為了能夠在一個sprint中完成,往往采用的是最簡單實現的方案。日積月累這些方案就會成為心中的隱患，而事實上我們做的很多高價值的功能都可能運行在簡單粗暴的方法上。
為什么敏捷和TDD能夠共生，既然你選擇了敏捷你就不應該背上那么多的沉重的包袱。當你的思緒總是羈絆在未來不可知中變化中，你就無法對你的當下做出選擇。
