上周參加了一次TDD的開發(fā)培訓(xùn)司倚，敏捷教練演示如何通過測試驅(qū)動出求質(zhì)數(shù)的公式员辩，借此向我們展示了TDD的巨大魅力盒粮。
"紅燈-綠燈-重構(gòu)"的開發(fā)節(jié)奏為我們開啟了另外一條軟件開發(fā)的思路，從底往上推導(dǎo)出整體業(yè)務(wù)邏輯奠滑。而我們傳統(tǒng)的開發(fā)思維里總是要先進行頂層的業(yè)務(wù)設(shè)計丹皱，然后分解有多少業(yè)務(wù)接口，從上往下進行宋税。兩種模式當(dāng)然互有利弊摊崭，TDD看上去更加的直觀，更能讓人感覺與正確性相關(guān)杰赛，讓程序沒有BUG爽室、有完善的測試保護、再也不用當(dāng)心重構(gòu)會影響原有的業(yè)務(wù)邏輯。
有感于次此阔墩，回來的時候我們組織了一個代碼編程比賽嘿架，借此向開發(fā)介紹單元測試的重要性，以及簡單重構(gòu)的好處啸箫。簡單的套用了一個教練提供的網(wǎng)球比賽列子耸彪，為了增加一些難度，增加了幾個復(fù)雜的case忘苛，對代碼行數(shù)做了限制蝉娜。在花了15分鐘給開發(fā)門簡單的介紹了一下比賽的規(guī)則后比賽開始。特意把比賽開始的時候定在的周5的下班后扎唾，希望大家周末有時間可以去找找資料召川，有更多的時間去反復(fù)重構(gòu)代碼，且不占用工作時間胸遇。
結(jié)果很意外荧呐，30分鐘后，便有一位開發(fā)完成了任務(wù)纸镊， 還是一位沒有參加TDD的人（原來沒有練習(xí)過）倍阐。采用了類似窮舉法的方式，將20個結(jié)果弄成一個數(shù)組逗威，然后通過一個TDD的方式推導(dǎo)出了一個很牛逼的函數(shù)峰搪，將結(jié)果返回回來。于推廣的意義來說 我覺得違背了我本來的意圖凯旭，但對于比賽規(guī)則說概耻，確實有效的。那么問題來了罐呼，在敏捷的模式里是否代碼功能達到要求就認為是一個好的設(shè)計咐蚯？
聯(lián)想到我們敏捷的開過過程中，我們經(jīng)常糾結(jié)的一個問題：簡單夠用的標準在哪里弄贿。在傳統(tǒng)的開發(fā)模式中，我們總是被要求或則要求別人需要為代碼后續(xù)維護做準備矫膨，尤其是在一些存在研發(fā)和實施由兩撥人來做的公司差凹。作為產(chǎn)品研發(fā)團隊的人，總是在想未來變化的點在哪里侧馅，我該如何的設(shè)計才能滿足需求危尿。而在敏捷的開發(fā)環(huán)境中，總是強調(diào)MVP,強調(diào)盡快的交付馁痴。為了能夠在一個sprint中完成,往往采用的是最簡單實現(xiàn)的方案谊娇。日積月累這些方案就會成為心中的隱患，而事實上我們做的很多高價值的功能都可能運行在簡單粗暴的方法上罗晕。
為什么敏捷和TDD能夠共生济欢，既然你選擇了敏捷你就不應(yīng)該背上那么多的沉重的包袱赠堵。當(dāng)你的思緒總是羈絆在未來不可知中變化中，你就無法對你的當(dāng)下做出選擇法褥。
