一個(gè)非教條式的TDD例子

作者： Thoughtworks洞見 2022-10-19 11:31:49

本文我想借這個(gè)機(jī)會(huì)聊聊如何運(yùn)用TDD的方式去完成這個(gè)數(shù)據(jù)分批處理的設(shè)計(jì)和開發(fā)。

作者 | 袁慎建

問題背景

數(shù)據(jù)分批器這個(gè)名字是我臨時(shí)起的一個(gè)名字，源于我輔導(dǎo)的客戶團(tuán)隊(duì)開發(fā)人員在當(dāng)時(shí)的核心系統(tǒng)中要解決的一個(gè)實(shí)際業(yè)務(wù)問題 —— Oracle的數(shù)據(jù)庫(kù)刪除每次只支持1000條。這個(gè)問題更確切的講是因?yàn)镺racle對(duì)下面這句SQL語(yǔ)句的支持約束：

delete from t_table where id in (ids)

問題就出在這個(gè)where id in ...上，后面?zhèn)魅氲募蠀?shù)ids最大支持1000條。而實(shí)際業(yè)務(wù)場(chǎng)景中存在大于1000條數(shù)據(jù)，所以需要進(jìn)行分批處理。

針對(duì)這個(gè)問題，我暫時(shí)不去探究這個(gè)SQL機(jī)制本身的合理性[1]。本文我想借這個(gè)機(jī)會(huì)聊聊如何運(yùn)用TDD的方式去完成這個(gè)數(shù)據(jù)分批處理的設(shè)計(jì)和開發(fā)。

需求分解

基于這樣的問題，我的習(xí)慣是先對(duì)問題進(jìn)行分解，也就是TDD前要做的一個(gè)關(guān)鍵動(dòng)作 —— Tasking。我快速做了個(gè)Tasking：

(1)非1000的整數(shù)倍，小于1000條

(2)1000的整數(shù)倍

(3)非1000的整數(shù)倍，大于1000條

基于Tasking結(jié)果，對(duì)上述需求場(chǎng)景進(jìn)行實(shí)例化，實(shí)例化過程中，邊界值是我要考慮的重點(diǎn)：

(1)非1000的整數(shù)倍，小于1000條

0條
369條

(2)1000的整數(shù)倍

1000條
2000條

(3)非1000的整數(shù)倍，大于1000條

1369條
2222條

原有設(shè)計(jì)

上述代碼的for循環(huán)中做了兩件事，邊截取不同范圍的recordsId，邊調(diào)用了 CustomCustomerRiskScoreRepository 來做數(shù)據(jù)庫(kù)操作，分批邏輯和存儲(chǔ)夾雜在一起的過程式設(shè)計(jì)的好處是直接了當(dāng)，當(dāng)然也讓 deleteByRecordIds() 的職責(zé)過多。

新的設(shè)計(jì)

基于我對(duì)軟件設(shè)計(jì)淺薄的理解，我認(rèn)為這個(gè)分批邏輯和Repository數(shù)據(jù)存儲(chǔ)邏輯分開會(huì)更優(yōu)雅，支持我的幾個(gè)主要理由是：

數(shù)據(jù)存儲(chǔ)邏輯更加純粹，它只用關(guān)心數(shù)據(jù)的CRUD。
重要：分批邏輯可以很方便地進(jìn)行自動(dòng)化測(cè)試。
分批邏輯獨(dú)立出來，方便復(fù)用和維護(hù)。

基于以上的幾點(diǎn)理由，我在原來的過程式程序設(shè)計(jì)的基礎(chǔ)上引入一些OO的理念，進(jìn)行對(duì)象建模，比如抽象出一個(gè)數(shù)據(jù)分批器。我把對(duì)象建模過程看做在TDD之前的一些簡(jiǎn)單且必要的設(shè)計(jì)。

TDD不太提倡在開始前不做任何設(shè)計(jì)，恰恰它提倡做一些簡(jiǎn)單且必要的程序接口設(shè)計(jì) —— 非教條主義

通過對(duì)象建模分析，我設(shè)計(jì)了兩個(gè)簡(jiǎn)單的對(duì)象，一個(gè)是BatchDivider，另一個(gè)是Range，UML如下：

BatchDivider接收一個(gè)總數(shù)，然后能夠返回一個(gè)包含了起止的范圍的集合，比如接收1369條，返回集合[Range(0, 1000), (1000, 1369)]，起止信息我用Range對(duì)象來表示。

前期的設(shè)計(jì)就做到這，我沒有花太多時(shí)間去糾結(jié)細(xì)節(jié)，因?yàn)楝F(xiàn)在的設(shè)計(jì)足夠讓我起步了。如果在后續(xù)發(fā)現(xiàn)了不完善的地方，交給后續(xù)的驅(qū)動(dòng)和重構(gòu)。

編碼落地

至此，我已經(jīng)把需求進(jìn)行了分解和實(shí)例化，然后也做了簡(jiǎn)單的程序設(shè)計(jì)，跑步前的熱身完畢，接下來我就打算采用TDD的跑姿小跑起來。

之前的實(shí)例化我寫得比較簡(jiǎn)單，由于我習(xí)慣用Given-When-Then的方式來描述，我把之前簡(jiǎn)單的實(shí)例化再結(jié)合當(dāng)前的程序設(shè)計(jì)做了細(xì)化：

非1000的整數(shù)倍，小于1000條

(1)0條

Given 待分批數(shù)據(jù)是0條
When 分批處理
Then 批次結(jié)果為空集合, []

(2)369條

Given 待分批數(shù)據(jù)是369條
When 分批處理
Then 批次結(jié)果包含1個(gè)Range的集合，[(0, 369)]

1000的整數(shù)倍

(1)1000條

Given 待分批數(shù)據(jù)是1000條
When 分批處理
Then 批次結(jié)果包含1個(gè)Range的集合，[(0, 1000)]

(2)2000條

Given 待分批數(shù)據(jù)是2000條
When 分批處理
Then 批次結(jié)果包含2個(gè)Range的集合，[(0, 1000), (1000, 2000)]

非1000的整數(shù)倍，大于1000條

(1)1369條

Given 待分批數(shù)據(jù)是1369條
When 分批處理
Then 批次結(jié)果包含2個(gè)Range的集合，[(0, 1000), (1000, 1369)]

(2)2222條

Given 待分批數(shù)據(jù)是2222條
When 分批處理
Then 批次結(jié)果包含3個(gè)Range的集合，[(0, 1000), (1000, 2000), (2000, 2222)]

第1個(gè)測(cè)試

Given 待分批數(shù)據(jù)是0條
When 分批處理
Then 批次結(jié)果為空集合, []

在編寫測(cè)試代碼時(shí)，有一種做法是從結(jié)果往前驅(qū)動(dòng)，比如我會(huì)先寫assert，然后按照思維意圖一步一步往前倒逼我去命名變量，去給變量賦值。下面是我寫的第1個(gè)測(cè)試用例：

你現(xiàn)在看到的5 ~ 11行代碼，我的編寫順序是11 --> 5。這僅僅是我個(gè)人的習(xí)慣，因?yàn)槭艿揭越K為始和意圖導(dǎo)向編程觀念的影響，養(yǎng)成了這樣的習(xí)慣。Kent Beck在《測(cè)試驅(qū)動(dòng)開發(fā)》也提到了這種方式。

按照反向驅(qū)動(dòng)的方式寫出來的代碼，我發(fā)現(xiàn)測(cè)試代碼中的一些沒必要的臨時(shí)變量，但我先不著急去重構(gòu)，我先聚焦讓這個(gè)測(cè)試通過，至少現(xiàn)在的代碼可讀性也非常好。很快，借助IDE的快捷鍵，我編寫了讓測(cè)試通過的實(shí)現(xiàn)代碼：

我使用了偽實(shí)現(xiàn)讓測(cè)試快速通過，緊接著借助Inline手法清除了測(cè)試代碼中沒必要的臨時(shí)變量totalItemSum和batchCount。

第2個(gè)測(cè)試

Given 待分批數(shù)據(jù)是369條
When 分批處理
Then 批次結(jié)果包含1個(gè)Range的集合，[(0, 369)]

第二個(gè)測(cè)試起名為 given_item_count_below_1000 ，這里我沒有使用具體的實(shí)例化數(shù)據(jù)369，你或許會(huì)起名為 given_item_count_is_369。我個(gè)人習(xí)慣采用抽象場(chǎng)景來命名，因?yàn)槲矣X得能夠更直觀的提供業(yè)務(wù)場(chǎng)景的信息。

第二個(gè)測(cè)試，我直接給ranges添加了一個(gè)Range對(duì)象，并保留了上一個(gè)測(cè)試的判斷，快速地讓測(cè)試通過了：

第3個(gè)測(cè)試

Given 待分批數(shù)據(jù)是1000條
When 分批處理
Then 批次結(jié)果包含1個(gè)Range的集合，[(0, 1000)]

這個(gè)測(cè)試運(yùn)行之后直接通過了，萬(wàn)事大吉，運(yùn)氣還不錯(cuò)。

第4個(gè)測(cè)試

Given 待分批數(shù)據(jù)是2000條
When 分批處理
Then 批次結(jié)果包含2個(gè)Range的集合，[(0, 1000), (1000, 2000)]

為了通過這個(gè)測(cè)試，我編寫了如下的功能代碼，節(jié)省篇幅，我只摘取了核心的batchProcess方法：

很順利，我通過了第四個(gè)測(cè)試，我發(fā)現(xiàn)該方法中1000這個(gè)數(shù)字出現(xiàn)了好幾次，這是個(gè)魔法數(shù)字，而且重復(fù)出現(xiàn)，在我看來這就是一只攜帶了兩種味道的惡魔，于是抽取一個(gè)常量ONE_BATCH_SIZE。

正當(dāng)我準(zhǔn)備寫下一個(gè)測(cè)試時(shí)，我運(yùn)行了之前的所有測(cè)試，發(fā)現(xiàn)第2個(gè)測(cè)試掛了 —— 我破壞了原來的功能。我回頭檢查了 batchProcess 方法的實(shí)現(xiàn)，原來是 totalItemCount / ONE_BATCH_SIZE 這個(gè)運(yùn)算出了問題，當(dāng)totalItemCount = 369的時(shí)候，整除結(jié)果為0。

定位到問題，基于之前的開發(fā)經(jīng)驗(yàn)，我嘗試了Math函數(shù)的幾個(gè)方法，最終找到了 Math.ceil(double) 方法：

?? 修復(fù)第2個(gè)測(cè)試之后，我心里給TDD點(diǎn)了個(gè)贊：TDD所構(gòu)建的測(cè)試安全網(wǎng)可以為重構(gòu)提供保護(hù)，如果功能被破壞，測(cè)試很快就能發(fā)現(xiàn)，這讓我去更有勇氣去重構(gòu)。

第5個(gè)測(cè)試

Given 待分批數(shù)據(jù)是1369條
When 分批處理
Then 批次結(jié)果包含2個(gè)Range的集合，[(0, 1000), (1000, 1369)]

第6個(gè)測(cè)試

Given 待分批數(shù)據(jù)是2222條
When 分批處理
Then 批次結(jié)果包含3個(gè)Range的集合，[(0, 1000), (1000, 2000), (2000, 2222)]

這個(gè)測(cè)試也直接通過了，到目前為止，所有的測(cè)試運(yùn)行結(jié)果都是綠色的?；诋?dāng)前的6個(gè)測(cè)試，我對(duì)當(dāng)前的程序非常有信心了，先前實(shí)例化的場(chǎng)景也都覆蓋了，所以我準(zhǔn)備停下來去倒杯水。

可規(guī)避的教條

教條：提前設(shè)計(jì)不可有

不是說TDD指Test-Driven Design，設(shè)計(jì)是由測(cè)試驅(qū)動(dòng)出來的嗎，提前設(shè)計(jì)怎么交待呢？

TDD通常也會(huì)被解讀為：測(cè)試驅(qū)動(dòng)設(shè)計(jì)。關(guān)于測(cè)試驅(qū)動(dòng)設(shè)計(jì)，我覺得一點(diǎn)點(diǎn)提前設(shè)計(jì)是有必要的，它給了我一個(gè)宏觀的方向，讓我能夠順利地開始。我的個(gè)人習(xí)慣是，在開始寫測(cè)試代碼前我會(huì)做一些簡(jiǎn)單的紙面設(shè)計(jì)，做一些簡(jiǎn)單的對(duì)象建模，定義好一些對(duì)外的接口。在早期，我也不會(huì)寫紙面的設(shè)計(jì)，而是直接開始寫測(cè)試代碼，實(shí)際上我在寫測(cè)試的時(shí)候腦海里是有設(shè)計(jì)的，只是我沒有顯性化出來。

一方面由于年齡增加，另一方面，面臨的問題很多時(shí)候沒這么簡(jiǎn)單，顯性化出來可以減輕我大腦負(fù)載，并且還能帶來一些其他的好處。

另外，我發(fā)現(xiàn)Uncle Bob在做TDD的時(shí)候也會(huì)做一些簡(jiǎn)單必要的提前設(shè)計(jì)。比如，他在演示TDD Kata 保齡球的時(shí)候就這么干過。

教條：新增測(cè)試要見紅

TDD循環(huán)圈紅-綠-重構(gòu)，新增的測(cè)試必須要掛掉，上面第3、5、6，三個(gè)測(cè)試都直接綠了，你這TDD是在騙人的吧？

之前公司有Senior的同事就和我恨恨地討論過這點(diǎn)，說實(shí)話我沒有什么理由去反駁這個(gè)觀點(diǎn)，但我沒想明白的是為什么新增一個(gè)測(cè)試如果直接通過了就不是TDD了呢。測(cè)試直接通過了不是更好嘛？當(dāng)然前提是你的測(cè)試是對(duì)的。

后來我觀察了很多初學(xué)者在練習(xí)TDD時(shí)的做法，搞明白這種想法背后的擔(dān)心。我看有人寫了第一個(gè)測(cè)試，然后花很多時(shí)間去寫實(shí)現(xiàn)，結(jié)果一股腦實(shí)現(xiàn)了很多場(chǎng)景的功能。講真，這樣做也未嘗不可，但從體會(huì)TDD的聚焦性和驅(qū)動(dòng)性上來看，這個(gè)做法恐怕難以達(dá)到目的，這也是TDD門檻高的原因之一 —— 難以控制自己。但從實(shí)用性來看，一股腦寫完好幾個(gè)場(chǎng)景的功能實(shí)現(xiàn)，然后補(bǔ)上后面幾個(gè)場(chǎng)景的測(cè)試，也并非不可。要知道咱們寫代碼的初衷是什么 —— 交付可用軟件，或美其名曰交付可用的高質(zhì)量軟件。

所以，為了在學(xué)習(xí)TDD時(shí)更好自控，就有了這樣的一個(gè)教條 —— 新增的測(cè)試一定得是掛的。但很多時(shí)候在編碼過程中，由于編程語(yǔ)言的便捷性，我們?cè)诳焖佟⒑?jiǎn)單地實(shí)現(xiàn)了某個(gè)邊界場(chǎng)景用例時(shí)難免會(huì)存在讓下一個(gè)測(cè)試直接通過的情況，比如我在寫第4個(gè)測(cè)試的時(shí)候，我直接使用了這個(gè)算法：

int batchCount = (int) Math.ceil(totalItemCount / (double) ONE_BATCH_SIZE);

我沒有再花心思去想怎么搞個(gè)hard code參數(shù)是2000，再加一個(gè)if判斷。因?yàn)榛谇懊鎺讉€(gè)測(cè)試的知識(shí)和經(jīng)驗(yàn)積累，我已經(jīng)掌握了讓當(dāng)前測(cè)試通過的算法，而且不會(huì)比我hard code更花時(shí)間。要說快，我直接上這個(gè)會(huì)更快。寫完后我其實(shí)能預(yù)測(cè)到后面兩個(gè)測(cè)試會(huì)直接通過，但我還是會(huì)加上后面兩個(gè)測(cè)試，因?yàn)檫@不僅僅關(guān)乎TDD的姿勢(shì)，更關(guān)乎TDD本真的東西 —— 測(cè)試保護(hù)網(wǎng)。

另外，也可能是由于在拆分任務(wù)的時(shí)候太細(xì)，使用了不同的數(shù)據(jù)來實(shí)例化了同一類場(chǎng)景，導(dǎo)致測(cè)試用例有交叉，又或者是拆分場(chǎng)景不合理產(chǎn)生了重復(fù)，此時(shí)也是一個(gè)反饋調(diào)整任務(wù)列表的契機(jī)。

教條：通過測(cè)試唯快不破

TDD循環(huán)圈強(qiáng)調(diào)要以最快的速度、最簡(jiǎn)單丑陋的方式讓測(cè)試快速通過，你這寫多了??？

這個(gè)教條跟上一個(gè)是緊密相關(guān)的，在上一條后半部分也在解釋這個(gè)。有時(shí)候我明明寫一個(gè)功能完整的代碼比簡(jiǎn)單、丑陋的代碼要更快，我就不會(huì)再去hard code，然后假裝慶祝自己是在做“真”TDD。Kent Beck在《測(cè)試驅(qū)動(dòng)開發(fā)》一書的可運(yùn)行模式中提到，快速讓測(cè)試通過的三種方法：

偽實(shí)現(xiàn)
三角法
顯明實(shí)現(xiàn)

我理解這種觀點(diǎn)的支撐點(diǎn)在于對(duì)偽實(shí)現(xiàn)和三角法使用，它認(rèn)為設(shè)計(jì)應(yīng)該是通過大量實(shí)例化的測(cè)試用例驅(qū)動(dòng)出來的。對(duì)于那些很復(fù)雜的業(yè)務(wù)場(chǎng)景，通過簡(jiǎn)單的幾個(gè)用例確實(shí)沒法有效看清抽象模式，浮現(xiàn)不出良好的設(shè)計(jì)，偽實(shí)現(xiàn)和三角法不失為一種好的驅(qū)動(dòng)方式。但有時(shí)候，你對(duì)設(shè)計(jì)很清楚，實(shí)現(xiàn)很明顯，這個(gè)時(shí)候何不直接上呢？我在第2個(gè)測(cè)試的實(shí)現(xiàn)中采用了偽實(shí)現(xiàn)，而在第4個(gè)中由于我破壞了之前的測(cè)試，我直接上了Math.ceil函數(shù)，沒想到實(shí)現(xiàn)了最終的功能。

我提倡的“教條”

提倡：顯性化知識(shí)

這么簡(jiǎn)單的業(yè)務(wù)需求，我腦袋瓜子完全夠用，有必要這么麻煩顯性地呈現(xiàn)出來嗎？

我認(rèn)為有必要寫出來，俗話說好記性不如爛筆頭。在整理呈現(xiàn)的過程中，我會(huì)投入更多的時(shí)間思考，思考有沒有準(zhǔn)確理解業(yè)務(wù)？思考如何能夠讓別人更容易理解？另外，它還可以作為一個(gè)顯性的計(jì)劃工具，幫助我評(píng)估我未來的工作。有了它，我跟團(tuán)隊(duì)成員溝通起來也更高效，并且在后續(xù)非單線程的工作模式中更容易聚焦重點(diǎn)，更方便我去檢查任務(wù)進(jìn)展。在我看來，可視化的動(dòng)作能讓Tasking發(fā)揮以下四個(gè)工具價(jià)值：

顯性的計(jì)劃工具
高效的溝通工具
便捷的檢查工具
進(jìn)化的思維工具

話說回來，寫出來并不會(huì)花太多時(shí)間吧，寫不出來就去做，有可能是因?yàn)檫€想不清楚，想不清楚的話就有危險(xiǎn)了。問題域越復(fù)雜，這里越值得花時(shí)間去想。

提倡：夯實(shí)基本功

總是拿玩具代碼來忽悠新人，在實(shí)際項(xiàng)目中遠(yuǎn)比這復(fù)雜的多，還是搞不定呀？

說到這個(gè)，我想起了我跟羽毛球的故事。我是2020年8月份的時(shí)候才正式接觸羽毛球，在這之前我平均一年打球不到5次，在這之后我最多的時(shí)候一周就超過了5次。以前，我無(wú)知地以為羽毛球沒什么復(fù)雜的，拿個(gè)拍子，場(chǎng)上跑跑，基本上人人都會(huì)，壓根用不著花錢找教練。后來場(chǎng)上數(shù)次被虐的“恥辱”讓我不得不去好好了解一下羽毛球。不學(xué)不知道，一學(xué)嚇一跳，簡(jiǎn)單羅列一下：

身體基本功：體能、爆發(fā)力、耐力、反應(yīng)速度、彈跳
基礎(chǔ)：發(fā)力、握拍、舉拍、步伐（6個(gè)方向，1~3步）
技巧：發(fā)球、接發(fā)球、吊球、勾對(duì)角、平抽、高遠(yuǎn)球、殺球、接殺球、封網(wǎng)、搓球
站位：男單、女單、男雙、混雙

上面列出來的還不齊全，并且基本功和技巧都涵蓋了正手和反手。羽毛球的技巧和戰(zhàn)術(shù)如此之多，每一個(gè)都?jí)蚓毩?xí)一陣子，羽毛球的羽字：一分為二，學(xué)習(xí) + 練習(xí)，這個(gè)字讓我感慨真不是隨意取的（為了幫助廣大球友快速成長(zhǎng)，我整理了羽球知識(shí)庫(kù)，請(qǐng)?jiān)谖哪┇@取[2]）。

我可以在這些技巧都不會(huì)或者都不嫻熟的情況下，跳過針對(duì)性的基本功練習(xí)，直接上場(chǎng)叫囂要跟高手拉練，難免自取其辱還得不到有效提升。認(rèn)識(shí)到這點(diǎn)之后，唯有日練揮拍近千次來夯實(shí)基本功方可讓我有勇氣嘗試挑戰(zhàn)高手。

“練球不練功，打球一場(chǎng)空”。我認(rèn)為學(xué)習(xí)TDD也是一樣的道理，實(shí)際項(xiàng)目中確實(shí)業(yè)務(wù)和架構(gòu)復(fù)雜得多，但這不該成為你拒絕以簡(jiǎn)單的案例入手去練習(xí)基本功的理由。再?gòu)?fù)雜的案例，元能力是類似的。

早在2018年底的，我給武漢某Offshore團(tuán)隊(duì)做了一場(chǎng)OOBootcamp，大家覺得ParkingLot不過癮，在訓(xùn)練營(yíng)快結(jié)束的時(shí)候，我?guī)Т蠹姨接懥嗽谝粋€(gè)Java SpringBoot后端分層架構(gòu)中如何落地TDD。有了訓(xùn)練營(yíng)的刻意練習(xí)，團(tuán)隊(duì)很快在后端分層架構(gòu)中實(shí)踐落地了TDD。

所以，我個(gè)人認(rèn)為基本功是首要的，如果你還沒有嘗試過TDD，不妨先拋開懷疑，先去嘗試一下。

寫在最后

我接觸TDD有7年多時(shí)間了，至今未通透，仍在努力學(xué)習(xí)中。在實(shí)際項(xiàng)目落地TDD以及在TDD訓(xùn)練營(yíng)中，我會(huì)堅(jiān)持一些原則，主要有以下三點(diǎn)：

Tasking優(yōu)先性
設(shè)計(jì)輕量性
知識(shí)明顯性

對(duì)業(yè)務(wù)需求進(jìn)行Tasking的過程能夠讓我重新梳理業(yè)務(wù)，并且減少理解上的偏差和遺漏，避免在后續(xù)開發(fā)過程出現(xiàn)返工，造成更高的修改成本。即便你做不到測(cè)試先行，Tasking也值得去做好。

設(shè)計(jì)本身就是一種不可言說的知識(shí)，何為簡(jiǎn)單且必要的設(shè)計(jì)？何為恰到好處的設(shè)計(jì)？不是看了幾本書、借用幾個(gè)大牛的三兩句話就能說清的，更多源自于日常實(shí)踐中的思考和總結(jié)。

針對(duì)Tasking的產(chǎn)出物，我會(huì)使用可視化和結(jié)構(gòu)化的方式顯性化管理起來，以便跟業(yè)務(wù)人員溝通確認(rèn)，并更好地在團(tuán)隊(duì)內(nèi)共享。

三條中前兩條對(duì)個(gè)人底層勝任力提出了要求。Tasking做得質(zhì)量如何，比較依賴個(gè)人的分析性思維，設(shè)計(jì)做的好不好，考驗(yàn)的是一個(gè)人對(duì)設(shè)計(jì)的Sense。這些能力不會(huì)那么輕易通過短期的培訓(xùn)得到提升，但好在我們每個(gè)人都具備一些基礎(chǔ)。在這樣的基礎(chǔ)前提下，結(jié)合一些結(jié)構(gòu)化良好的顯性知識(shí)管理方式，堅(jiān)持跟時(shí)間賽跑吧。