今天和同事一起領了一個故事卡來做。看完用戶故事卡中的描述和驗收準則后一頭霧水，不知道從哪里下手。由于卡中提到了幾個模塊都屬于遺留系統中的功能，以前沒有觸及這些模塊，對業務、對代碼都不太了解。而且還要對這些模塊進行修改，而這部分代碼都是陳舊的EJB代碼，復雜冗長，配置繁瑣，修改點無法確定，影響范圍無法預估。
那么接下來該怎么辦那？
可能很多人都選擇深入代碼內部，從代碼入手來搞清楚功能。我們剛開始想嘗試這種方式，在EJB的代碼群里跳來跳去，還是不明就里。我想這樣不行啊，看到猴年馬月去了。
這時候我就意識到我的方向錯了。代碼是業務邏輯的實現，應該先有業務邏輯，再有代碼。我們這樣反推只能會深陷細節，很難從中了解到整個業務邏輯的來龍去脈。
咋辦那？找BA（需求分析師）唄。我們把BA拉過來，讓她挨個把這張故事卡中的關聯模塊講清楚。為什么我們要做這樣的事情？這樣做對用戶來說能帶來什么好處？做這樣事情的場景是怎樣的？…..
解答了這些問題以后，我們逐漸明白了這個故事卡的業務邏輯，也有信心來完成這張卡了。
接下來是不是要回到代碼來看具體實現了那？非也，我們并沒有急著看代碼，而是消化了業務知識以后，打開了我們的功能性測試的項目，在里面查與該模塊功能相關的功能性測試。由于這些測試是使用BDD框架寫的，所以可讀性非常強，并且本身就描述了使用場景與案例。看了這些功能性測試我們一可以加深對需求的了解；二知道了當前這張故事卡牽扯到的模塊的覆蓋率是個什么情況，有助于我們修改后不會破壞已有的功能；三是有助于我們為修改后的功能補上功能性測試。并且我們可以順著功能性測試來查看該功能模塊的調用情況，根據調用情況來深入該功能的代碼細節，找到潛在的修改點。
通過功能性測試入手，我們閱讀代碼確實快了不少，很快就找到了潛在修改點。那么現在要動手修改嗎？答案是否定的。我們又回到了功能性測試的項目，為我們即將要改變的功能加上了自動化測試。這個時候測試應該是跑不過的。然后我們才動手修改代碼，完成功能修改。然后再次運行針對新功能的測試，一切OK。
完成了這個故事卡給我帶來了成就感。不只是因為我們解決了這個故事卡上的問題，而是讓我們學到了額外的知識。我們不能整天只為寫代碼而寫代碼，而是應該真正的以業務需求為核心，把需求吃透。一個程序員能夠保證做正確的事是遠遠不夠的，而是能夠確保他做的事情是正確的。
一個程序員在領到一個故事卡時，不應當急著寫怎么實現，而是應該向業務分析師質疑，為什么我要做這個功能？加了這個功能能給用戶帶來什么價值？有沒有其他簡單的方式來達到甚至超越這個卡給用戶帶來的價值？只有當這些問題都被解決了以后，才能進行開發。現在你已經是了解需求的專家了，相信在編寫代碼考慮實現方式時，有足夠的上下文了。
文章列表
留言列表
