做一張故事卡時的感悟

今天和同僚一起領了一個故事卡來做。看完使用者故事卡中的描述和驗收準則後一頭霧水，不知道從哪裡下手。由于卡中提到了幾個子產品都屬于遺留系統中的功能，以前沒有觸及這些子產品，對業務、對代碼都不太了解。而且還要對這些子產品進行修改，而這部分代碼都是陳舊的EJB代碼，複雜冗長，配置繁瑣，修改點無法确定，影響範圍無法預估。

那麼接下來該怎麼辦那？

可能很多人都選擇深入代碼内部，從代碼入手來搞清楚功能。我們剛開始想嘗試這種方式，在EJB的代碼群裡跳來跳去，還是不明就裡。我想這樣不行啊，看到猴年馬月去了。

這時候我就意識到我的方向錯了。代碼是業務邏輯的實作，應該先有業務邏輯，再有代碼。我們這樣反推隻能會深陷細節，很難從中了解到整個業務邏輯的來龍去脈。

咋辦那？找BA（需求分析師）呗。我們把BA拉過來，讓她挨個把這張故事卡中的關聯子產品講清楚。為什麼我們要做這樣的事情？這樣做對使用者來說能帶來什麼好處？做這樣事情的場景是怎樣的？…..

解答了這些問題以後，我們逐漸明白了這個故事卡的業務邏輯，也有信心來完成這張卡了。

接下來是不是要回到代碼來看具體實作了那？非也，我們并沒有急着看代碼，而是消化了業務知識以後，打開了我們的功能性測試的項目，在裡面查與該子產品功能相關的功能性測試。由于這些測試是使用BDD架構寫的，是以可讀性非常強，并且本身就描述了使用場景與案例。看了這些功能性測試我們一可以加深對需求的了解；二知道了目前這張故事卡牽扯到的子產品的覆寫率是個什麼情況，有助于我們修改後不會破壞已有的功能；三是有助于我們為修改後的功能補上功能性測試。并且我們可以順着功能性測試來檢視該功能子產品的調用情況，根據調用情況來深入該功能的代碼細節，找到潛在的修改點。

通過功能性測試入手，我們閱讀代碼确實快了不少，很快就找到了潛在修改點。那麼現在要動手修改嗎？答案是否定的。我們又回到了功能性測試的項目，為我們即将要改變的功能加上了自動化測試。這個時候測試應該是跑不過的。然後我們才動手修改代碼，完成功能修改。然後再次運作針對新功能的測試，一切OK。

完成了這個故事卡給我帶來了成就感。不隻是因為我們解決了這個故事卡上的問題，而是讓我們學到了額外的知識。我們不能整天隻為寫代碼而寫代碼，而是應該真正的以業務需求為核心，把需求吃透。一個程式員能夠保證做正确的事是遠遠不夠的，而是能夠確定他做的事情是正确的。

一個程式員在領到一個故事卡時，不應當急着寫怎麼實作，而是應該向業務分析師質疑，為什麼我要做這個功能？加了這個功能能給使用者帶來什麼價值？有沒有其他簡單的方式來達到甚至超越這個卡給使用者帶來的價值？隻有當這些問題都被解決了以後，才能進行開發。現在你已經是了解需求的專家了，相信在編寫代碼考慮實作方式時，有足夠的上下文了。