)
被“改了三輪”逼出來(lái)的 t3code我給自己定的一套編碼流程如果你也是那種團(tuán)隊(duì)里天天改需求、天天聯(lián)調(diào)吵架、天天上線后半夜看告警的開(kāi)發(fā)者我猜你對(duì)下面這個(gè)場(chǎng)景會(huì)很有共鳴產(chǎn)品經(jīng)理丟過(guò)來(lái)一句話“把列表頁(yè)加個(gè)篩選”然后就沒(méi)有然后了。你憑著直覺(jué)寫了前端、調(diào)了接口、塞了幾個(gè)參數(shù)第二天聯(lián)調(diào)的時(shí)候發(fā)現(xiàn)后端返回的字段結(jié)構(gòu)跟你預(yù)想的完全不一樣產(chǎn)品又補(bǔ)了一句“篩選條件要支持組合”。一個(gè)看起來(lái)半天能搞完的功能硬是來(lái)回改了三個(gè)版本才穩(wěn)住。三個(gè)月前我決定不再讓這種“先寫著看”的狀態(tài)繼續(xù)消耗大家。我給自己所在的開(kāi)發(fā)小組定了一套非常輕量的編碼流程代號(hào)就叫 t3code。t3code 拆開(kāi)來(lái)看就是三個(gè)以 T 開(kāi)頭的動(dòng)作Think想清楚、Transform寫明白、Test驗(yàn)證透。它的核心思路只有一句話把動(dòng)手寫代碼之前的模糊地帶全部顯性化把驗(yàn)收這件事從“上線再說(shuō)”提前到“寫碼前就說(shuō)清”。這篇文章我會(huì)把 t3code 的完整結(jié)構(gòu)、我們團(tuán)隊(duì)實(shí)際用下來(lái)的效果、踩過(guò)的坑以及可以直接抄走的模板都整理出來(lái)。如果你正在被需求反復(fù)、接口扯皮、返工率和線上 bug 折磨而且你所在的團(tuán)隊(duì)沒(méi)有專職測(cè)試、沒(méi)有完整文檔體系那這幾千字應(yīng)該能幫你少走不少?gòu)澛贰?. 被“改了三輪”逼出來(lái)的 t3code它到底解決什么問(wèn)題1.1 那個(gè)熟悉的崩潰現(xiàn)場(chǎng)我們小組負(fù)責(zé)一個(gè) B 端管理后臺(tái)功能不復(fù)雜但節(jié)奏很快通常一個(gè)迭代要排七八個(gè)需求。最常見(jiàn)的流程是需求會(huì)開(kāi)完一句話描述進(jìn)了迭代開(kāi)發(fā)直接開(kāi)寫。聽(tīng)起來(lái)很高效實(shí)際上處處是雷。舉一個(gè)真實(shí)發(fā)生的案例。有人提了個(gè)需求“導(dǎo)出列表數(shù)據(jù)”。開(kāi)發(fā)同學(xué)打開(kāi)代碼就開(kāi)始拼 Excel拼到一半發(fā)現(xiàn)要導(dǎo)出的是過(guò)濾后的數(shù)據(jù)但過(guò)濾狀態(tài)存在前端后端接口不認(rèn)于是開(kāi)始改接口。改完接口又發(fā)現(xiàn)產(chǎn)品要的不只是當(dāng)前列表頁(yè)的數(shù)據(jù)范圍而是要按時(shí)間段跨分頁(yè)導(dǎo)出于是再加參數(shù)。改到第二輪時(shí)發(fā)現(xiàn)導(dǎo)出的字段和后臺(tái)列表展示的字段不一致因?yàn)榱斜眄?yè)做過(guò)字段權(quán)限控制后端接口沒(méi)做。第三輪結(jié)束時(shí)一個(gè)本來(lái)標(biāo)注為 1 天的需求用了 3 天。最要命的是這三天里的每一次改動(dòng)都讓原本以為“已經(jīng)談好”的接口和頁(yè)面結(jié)構(gòu)再松動(dòng)一次。整個(gè)開(kāi)發(fā)過(guò)程不是在寫代碼而是在滅火。問(wèn)題真的出在“需求沒(méi)說(shuō)清”嗎不全是。需求永遠(yuǎn)不可能完全說(shuō)清。真正的問(wèn)題是我們把決策點(diǎn)拖到了寫代碼之后所有模糊地帶都要等到代碼跑起來(lái)才能暴露。1.2 t3code 的三段結(jié)構(gòu)Think、Transform、Testt3code 的模型特別簡(jiǎn)單就是三個(gè)字母T、3、code。T 代表 take3 代表三步code 就是代碼本身。這是我當(dāng)初起名時(shí)偷懶的產(chǎn)物但沒(méi)想到這套結(jié)構(gòu)意外地好記。具體來(lái)說(shuō)Think在寫代碼之前把“到底要做什么”用一張卡片寫下來(lái)。寫清楚用戶訴求、驗(yàn)收標(biāo)準(zhǔn)、涉及面、風(fēng)險(xiǎn)點(diǎn)。這一步逼著你把需求語(yǔ)言翻譯成實(shí)現(xiàn)語(yǔ)言。Transform把卡片上的內(nèi)容轉(zhuǎn)化成技術(shù)方案。數(shù)據(jù)從哪來(lái)、狀態(tài)放哪、異常怎么處理、接口怎么定義、用哪個(gè)技術(shù)方案全部落地成一張 mapping 表。這一步逼著你在動(dòng)手前后心里有數(shù)。Test寫完代碼不是終點(diǎn)。對(duì)照驗(yàn)收標(biāo)準(zhǔn)逐條打勾換一個(gè)視角重新走一遍流程讓第二個(gè)人來(lái)做 code review。這一步逼著你把“我以為做完了”變成“確實(shí)做完了”。三段不是三個(gè)獨(dú)立階段而是一個(gè)閉環(huán)。尤其是 Test 階段發(fā)現(xiàn)的東西要能回溯到 Think 階段的卡片里去修需求理解的偏差而不只是修代碼。我把這個(gè)叫做“回環(huán)式交付”這也是 t3code 和普通開(kāi)發(fā)流程最大的區(qū)別。1.3 它不替代敏捷也不替代代碼規(guī)范很多人一聽(tīng)到“流程”兩個(gè)字就皺眉以為又要開(kāi)會(huì)、寫文檔、做一堆形式主義的東西。我特別能理解這種反感因?yàn)槲乙彩潜桓鞣N重流程折磨過(guò)的人。所以這里先劃清邊界t3code 不是來(lái)替代敏捷開(kāi)發(fā)、TAPD、Jira、代碼規(guī)范這些東西的。敏捷管的是迭代節(jié)奏和協(xié)作儀式規(guī)范管的是代碼長(zhǎng)什么樣Commit 消息怎么寫函數(shù)怎么拆。t3code 管的是另一件事每一次動(dòng)手寫代碼之前的決策鏈。它很小小到一個(gè)人寫腳本也能用小到不需要任何工具一張紙一支筆就能跑。所以我在團(tuán)隊(duì)里推的時(shí)候沒(méi)有要求大家改變?cè)械捻?xiàng)目管理和代碼評(píng)審流程只是要求在原有流程里嵌入三個(gè)新的動(dòng)作寫卡、畫 mapping、跑 test loop。這也是它能堅(jiān)持下來(lái)的原因—— 加入的成本足夠低大家才愿意用。2. Task Card把需求從“大概”逼到“顆?！?.1 先寫卡片再動(dòng)手卡片長(zhǎng)什么樣t3code 的第一步是寫 Task Card也就是任務(wù)卡。這是整個(gè)流程的地基。我見(jiàn)過(guò)太多需求描述就是一句話“優(yōu)化加載速度”“列表加個(gè)導(dǎo)出”這種描述寫完代碼之后你根本無(wú)法判斷自己到底做沒(méi)做對(duì)標(biāo)準(zhǔn)太模糊了。我們的 Task Card 固定包含下面幾個(gè)字段任務(wù)編號(hào)對(duì)應(yīng)迭代里的編號(hào)方便追溯。用戶訴求誰(shuí)在什么場(chǎng)景下遇到了什么問(wèn)題希望得到什么結(jié)果。必須寫具體的人具體的場(chǎng)景。驗(yàn)收標(biāo)準(zhǔn)做到什么程度算完成。這是整張卡片最核心的部分必須是可以驗(yàn)證的、可勾選的要點(diǎn)。涉及面改動(dòng)會(huì)碰哪些模塊哪些地方明確不動(dòng)。風(fēng)險(xiǎn)點(diǎn)這個(gè)任務(wù)里你不知道的事、可能出問(wèn)題的地方。預(yù)估時(shí)間只做粗粒度評(píng)估不搞精細(xì)估點(diǎn)。舉個(gè)例子。我們做一個(gè)“給管理后臺(tái)加導(dǎo)出日志”的需求卡片是這么寫的用戶訴求運(yùn)營(yíng)同學(xué)每天早晨要看前一日的操作記錄目前只能一頁(yè)一頁(yè)翻效率低希望可以一鍵導(dǎo)出 Excel。驗(yàn)收標(biāo)準(zhǔn)導(dǎo)出文件為.xlsx格式文件名帶日期。導(dǎo)出內(nèi)容包含當(dāng)前篩選條件下的全部數(shù)據(jù)超過(guò) 10000 條時(shí)自動(dòng)分文件。導(dǎo)出時(shí)間超過(guò) 10 秒時(shí)后臺(tái)異步生成用戶生成后收到下載提示。涉及面操作日志查詢接口、前端導(dǎo)出按鈕、后臺(tái)文件生成服務(wù)。權(quán)限邏輯不動(dòng)。風(fēng)險(xiǎn)點(diǎn)導(dǎo)出的數(shù)據(jù)量如果過(guò)大服務(wù)端內(nèi)存可能吃緊需要考慮分批查詢。預(yù)估時(shí)間1 人天。寫這張卡片的過(guò)程其實(shí)就是把需求逼到可執(zhí)行的過(guò)程。你會(huì)發(fā)現(xiàn)很多原來(lái)看起來(lái)“很簡(jiǎn)單”的需求在填寫這些字段時(shí)會(huì)暴露出大量空白。比如什么叫“一鍵導(dǎo)出”導(dǎo)出當(dāng)前頁(yè)還是全部要不要帶篩選條件這些問(wèn)題的答案在卡片階段就找出來(lái)總比在代碼寫完以后被人追著問(wèn)強(qiáng)。2.2 拆分顆粒度的兩小時(shí)原則Task Card 拆多細(xì)是個(gè)非常實(shí)際的問(wèn)題。拆太粗卡片失去指導(dǎo)意義寫出來(lái)跟需求描述沒(méi)區(qū)別拆太細(xì)一天產(chǎn)生幾十張卡片管理卡片的時(shí)間比寫代碼還多。我實(shí)踐下來(lái)最好用的標(biāo)準(zhǔn)是“兩小時(shí)原則”一張卡片的主體編碼工作量應(yīng)該在兩小時(shí)左右完成。這個(gè)原則不是寫死的規(guī)定它是一個(gè)信號(hào)。如果你發(fā)現(xiàn)一張卡片要寫兩天說(shuō)明任務(wù)沒(méi)有拆透里面還藏著多個(gè)決策點(diǎn)。比如“實(shí)現(xiàn)用戶登錄”這個(gè)描述就是典型的大顆?？ㄋ鋵?shí)可以拆成“前端登錄表單與校驗(yàn)”“后端登錄接口與 token 簽發(fā)”“登錄態(tài)刷新與過(guò)期處理”“記住密碼功能”四張卡每一張都對(duì)應(yīng)一個(gè)可以獨(dú)立驗(yàn)證的成果。反過(guò)來(lái)如果你發(fā)現(xiàn)寫卡片的時(shí)間比寫代碼的時(shí)間還長(zhǎng)說(shuō)明拆得太細(xì)了。我看過(guò)有人把“給按鈕加個(gè) loading 態(tài)”都單獨(dú)建一張卡那屬于過(guò)度拆解看起來(lái)顆粒度很漂亮實(shí)際上在純消耗團(tuán)隊(duì)精力。兩小時(shí)原則的核心目的是逼你進(jìn)入“可預(yù)估”狀態(tài)能預(yù)估的東西才能排期能排期的東西才談得上質(zhì)量和進(jìn)度。2.3 寫驗(yàn)收標(biāo)準(zhǔn)的三個(gè)反常識(shí)細(xì)節(jié)Task Card 里最容易寫廢的就是驗(yàn)收標(biāo)準(zhǔn)而驗(yàn)收標(biāo)準(zhǔn)恰恰是最不能含糊的部分。我們?cè)谕菩羞^(guò)程中總結(jié)了三個(gè)經(jīng)驗(yàn)聽(tīng)起來(lái)有點(diǎn)反常識(shí)但非常有用。第一不要用“優(yōu)化”“完善”“增強(qiáng)”這類動(dòng)詞。這些詞的正確用法是零因?yàn)闆](méi)人知道“優(yōu)化完”是什么樣。驗(yàn)收標(biāo)準(zhǔn)里必須出現(xiàn)具體的字段、數(shù)值、邊界。把“優(yōu)化加載速度”改成“首屏接口返回時(shí)間在 2G 網(wǎng)絡(luò)下不超過(guò) 3 秒”這才是一條能驗(yàn)證的標(biāo)準(zhǔn)。第二驗(yàn)收標(biāo)準(zhǔn)必須寫明“不做的事”。比如需求是做篩選要明確“不做模糊搜索只做精確匹配”需求是導(dǎo)出要明確“不含匯總行”。這不是在縮需求這是在劃邊界。沒(méi)有邊界任何人都可以在評(píng)審的時(shí)候把自己的想象當(dāng)成需求本身。第三驗(yàn)收標(biāo)準(zhǔn)要寫“反過(guò)來(lái)也要能驗(yàn)證”。比如一個(gè)校驗(yàn)邏輯不僅要說(shuō)清“手機(jī)號(hào)格式錯(cuò)誤給出提示”還要寫“格式正確時(shí)能正常通過(guò)”。只測(cè)正確路徑不測(cè)錯(cuò)誤路徑是測(cè)試階段最大的盲區(qū)而這些盲區(qū)恰恰應(yīng)該在寫卡時(shí)就想到。3. Tech Mapping寫代碼前先跑一遍“地圖”3.1 技術(shù)選型不是臨場(chǎng)發(fā)揮Task Card 寫完確認(rèn)大家對(duì)齊了“做什么”接下來(lái)就是 t3code 的第二個(gè) TTransform。這個(gè)階段解決的是“怎么做”。我觀察過(guò)不少開(kāi)發(fā)者也包括我自己年輕時(shí)候的樣子拿到需求打開(kāi)編輯器遇到什么問(wèn)題開(kāi)始查什么問(wèn)題。比如寫著寫著發(fā)現(xiàn)要用防抖就開(kāi)始翻文檔找防抖函數(shù)寫著寫著發(fā)現(xiàn)要傳日期范圍才開(kāi)始定義接口參數(shù)。這種方式不是絕對(duì)不能出活但它最大的問(wèn)題是把技術(shù)決策逼到代碼行數(shù)里去導(dǎo)致決策本身沒(méi)有經(jīng)過(guò)推敲。Tech Mapping 就是專門治這個(gè)毛病的。它要求你在寫代碼之前把關(guān)鍵場(chǎng)景和技術(shù)方案列成一張映射表。一列是場(chǎng)景一列是方案一列是選擇這個(gè)方案的理由還可以加上備選方案和驗(yàn)證方式。做完這張表你心里就對(duì)整段代碼的結(jié)構(gòu)有了數(shù)。舉個(gè)例子我們要實(shí)現(xiàn)一個(gè)站內(nèi)通知功能。Mapping 表大概是這樣的場(chǎng)景用戶觸發(fā)某操作后需要收到實(shí)時(shí)通知。方案前端輪詢接口每 30 秒拉取一次未讀數(shù)量。理由通知實(shí)時(shí)性要求不高輪詢實(shí)現(xiàn)成本最低不需要引入 WebSocket 長(zhǎng)連接也不需要考慮斷線重連問(wèn)題。備選方案SSE 或 WebSocket后續(xù)如果實(shí)時(shí)性要求變高再遷移。驗(yàn)證方式用一個(gè)測(cè)試賬號(hào)觸發(fā)操作觀察 30 秒內(nèi)未讀數(shù)量刷新。這張表的價(jià)值不在于方案有多高級(jí)而在于把“選型”這個(gè)過(guò)程顯性化了。哪怕你最后用了最笨的方案只要理由站得住這段代碼在評(píng)審時(shí)的說(shuō)服力就完全不一樣。3.2 開(kāi)工前必過(guò)的五個(gè)問(wèn)題我跑了一段時(shí)間的 Tech Mapping 后發(fā)現(xiàn)不同任務(wù)的 mapping 表雖然內(nèi)容不一樣但核心問(wèn)題高度重復(fù)。最后我把它們收斂成五個(gè)必問(wèn)題數(shù)據(jù)從哪來(lái)對(duì)應(yīng)的接口是什么返回結(jié)構(gòu)長(zhǎng)什么樣需要新寫接口還是復(fù)用已有接口狀態(tài)放在哪是組件本地 state、全局 store還是服務(wù)端放錯(cuò)位置是很多 bug 的根源。異常情況怎么辦接口超時(shí)、返回空數(shù)據(jù)、字段缺失、權(quán)限不足每種異常的處理路徑是什么怎么被復(fù)用這個(gè)功能除了當(dāng)前場(chǎng)景還有沒(méi)有別的地方會(huì)用設(shè)計(jì)時(shí)是否要考慮參數(shù)化怎么測(cè)試手工點(diǎn)擊能不能覆蓋需不需要補(bǔ)單元測(cè)試核心邏輯是否有辦法自動(dòng)化驗(yàn)證這五個(gè)問(wèn)題對(duì)后端開(kāi)發(fā)同樣適用只是換一下措辭數(shù)據(jù)在哪張表、緩存怎么失效、接口要不要做冪等、要不要異步處理、監(jiān)控和日志怎么加。每個(gè)問(wèn)題都要求當(dāng)場(chǎng)給出答案給不出來(lái)的部分就是整個(gè)實(shí)現(xiàn)的真實(shí)風(fēng)險(xiǎn)點(diǎn)。用一張 mapping 表把所有風(fēng)險(xiǎn)點(diǎn)攤在桌面上比讓它們?cè)诖a里冒出來(lái)要省心得多。3.3 把接口示例寫死的聯(lián)調(diào)血淚教訓(xùn)Tech Mapping 階段最容易忽略但也最值得做的一件事是在動(dòng)手前把接口的請(qǐng)求參數(shù)和響應(yīng)示例寫死。這是我們從一次慘痛聯(lián)調(diào)里換來(lái)的教訓(xùn)。當(dāng)時(shí)前后端并行開(kāi)發(fā)后端按“返回碼 數(shù)據(jù)體”的結(jié)構(gòu)定義接口前端默認(rèn)后端會(huì)返回扁平結(jié)構(gòu)。兩邊都覺(jué)得自己理解得很透徹直到聯(lián)調(diào)那天第一行代碼跑起來(lái)發(fā)現(xiàn)字段對(duì)不上前端要的名字是lastUpdatedAt后端返回的是updateTime前端希望 error 是一個(gè)對(duì)象后端返回的是一個(gè)字符串。一個(gè)看起來(lái)極其簡(jiǎn)單的接口聯(lián)調(diào)和修改花了整整一個(gè)下午還連累了進(jìn)度。之后我在 Tech Mapping 里加了一條硬性要求只要任務(wù)涉及后端接口卡片里必須寫清“請(qǐng)求示例”和“響應(yīng)示例”兩邊照著示例開(kāi)發(fā)。不要說(shuō)什么“按接口文檔”小團(tuán)隊(duì)的接口文檔往往是過(guò)期文檔。直接在卡片里貼 JSON 示例以例為準(zhǔn)不扯文檔不猜結(jié)構(gòu)。用了這個(gè)辦法以后聯(lián)調(diào)會(huì)議里因?yàn)樽侄蚊臣艿那闆r基本消失了。4. Test Loop讓驗(yàn)證成為肌肉記憶而不是最后沖刺4.1 三層驗(yàn)證節(jié)奏怎么跑t3code 的第三個(gè) T 是 Test但這里的 Test 不只是“跑一下功能”而是指一個(gè)固定的驗(yàn)證循環(huán)。我把它拆成三層對(duì)應(yīng)著三個(gè)不同角色第一層是開(kāi)發(fā)者本人自測(cè)。寫完代碼后立刻把核心路徑跑一遍不要寫完就丟給測(cè)試或 reviewer。這個(gè)階段我要求自己至少回答一個(gè)問(wèn)題我寫的代碼在最常見(jiàn)的輸入下能不能工作很多時(shí)候不能因?yàn)槿藭?huì)想當(dāng)然。第二層是照卡驗(yàn)收。拿出 Task Card對(duì)著驗(yàn)收標(biāo)準(zhǔn)逐條打勾。這一層最容易被跳過(guò)因?yàn)榇蟛糠珠_(kāi)發(fā)覺(jué)得“代碼都寫了驗(yàn)收當(dāng)然沒(méi)問(wèn)題”。但實(shí)際上一旦你認(rèn)真過(guò)這一層會(huì)發(fā)現(xiàn)缺口比想象中多有的標(biāo)準(zhǔn)寫的是超 10000 條分文件但測(cè)試數(shù)據(jù)只有三條有的標(biāo)準(zhǔn)要求 10 秒后異步生成但實(shí)現(xiàn)里根本沒(méi)做異步。不是寫的時(shí)候故意漏是因?yàn)闆](méi)有把標(biāo)準(zhǔn)和實(shí)現(xiàn)對(duì)照。第三層是旁觀者驗(yàn)證。把卡片和代碼交給另一個(gè)人讓他用完全不懂實(shí)現(xiàn)細(xì)節(jié)的方式去操作。思路很簡(jiǎn)單自己寫的東西自己總是默認(rèn)它是對(duì)的一句提示文案寫錯(cuò)位置自己看三遍可能都發(fā)現(xiàn)不了但一個(gè)旁觀者兩分鐘就能看出來(lái)。這個(gè)旁觀者可以是同事也可以是第二天早高峰的自己。4.2 沒(méi)有專職測(cè)試的小團(tuán)隊(duì)怎么設(shè)驗(yàn)收規(guī)則我們團(tuán)隊(duì)沒(méi)有專職測(cè)試人員所以 Test Loop 的設(shè)計(jì)必須考慮“低成本可執(zhí)行”這個(gè)約束。我定的規(guī)則是一張卡片的完整驗(yàn)收時(shí)間不應(yīng)該超過(guò) 10 分鐘。如果超過(guò) 10 分鐘才驗(yàn)完那說(shuō)明卡片拆大了或者驗(yàn)收標(biāo)準(zhǔn)寫得不夠收斂。在這個(gè)約束下有幾類驗(yàn)證必須放進(jìn)去核心主路徑用戶最常用的操作路徑跑一遍要通?？諗?shù)據(jù)和邊界值查詢結(jié)果為空、參數(shù)長(zhǎng)度為 0、金額為 0、分頁(yè)超過(guò)最大頁(yè)這類最容易出 bug 的場(chǎng)景絕不能少。異常輸入格式錯(cuò)誤、非法值、越權(quán)操作要確認(rèn)系統(tǒng)給出的提示合理而不是白屏或者報(bào)錯(cuò)?？刂婆_(tái)無(wú)紅色報(bào)錯(cuò)我們明確要求驗(yàn)證時(shí)打開(kāi)瀏覽器控制臺(tái)不是看一眼頁(yè)面就完事。二次進(jìn)入退出后重新進(jìn)入頁(yè)面狀態(tài)要重置或者正確恢復(fù)。很多 bug 就藏在“第一次進(jìn)沒(méi)事第二次進(jìn)崩了”。這種驗(yàn)證姿勢(shì)肯定不能和專職 QA 團(tuán)隊(duì)相比但對(duì)小團(tuán)隊(duì)來(lái)說(shuō)已經(jīng)足夠把大部分低級(jí) bug 擋在上線之前。關(guān)鍵是形成肌肉記憶而不是靠某一天心情好就多測(cè)點(diǎn)。4.3 復(fù)盤會(huì)怎么開(kāi)才不至于變成批斗會(huì)Test Loop 跑完后如果發(fā)現(xiàn)問(wèn)題t3code 要求回到卡片去修正理解而不是只改代碼。這個(gè)環(huán)節(jié)我們是通過(guò)每周一次的小復(fù)盤來(lái)落地的。復(fù)盤最忌諱開(kāi)成批斗會(huì)。第一次我們開(kāi)會(huì)時(shí)所有人都不說(shuō)話氣氛非常尷尬。后來(lái)我自己先拿一個(gè)反例開(kāi)刀我寫過(guò)一張卡片驗(yàn)收標(biāo)準(zhǔn)和實(shí)際實(shí)現(xiàn)差了十萬(wàn)八千里原因是把測(cè)試環(huán)境和生產(chǎn)環(huán)境的配置混在一起看問(wèn)題。我講完自己的失誤大家才開(kāi)始放松。復(fù)盤會(huì)我們只用 15 分鐘挑一個(gè)最有代表性的 Task走一遍三連問(wèn)Think 階段漏掉了什么Transform 階段哪里走彎路Test 階段為什么沒(méi)有兜住不用 PPT不用投影拉一個(gè)共享文檔記錄結(jié)論就行。這個(gè)會(huì)很短但每周都開(kāi)效果比一個(gè)月開(kāi)一次三小時(shí)的總結(jié)會(huì)扎實(shí)得多。5. 跑了三周的真實(shí)變化與最容易翻車的執(zhí)行細(xì)節(jié)5.1 一張對(duì)比表看看前后差別t3code 在我們小范圍內(nèi)跑了三周中間并不是一帆風(fēng)順但整體變化非常明顯。我用一張不完全精確的對(duì)比表來(lái)呈現(xiàn)當(dāng)時(shí)的感受需求澄清時(shí)間之前要等到寫代碼中途或聯(lián)調(diào)時(shí)發(fā)現(xiàn)問(wèn)題醒過(guò)來(lái)已經(jīng)是第三天現(xiàn)在是寫卡時(shí)就爭(zhēng)論清楚第一天就解決。返工率之前一個(gè)功能平均改兩到三版才穩(wěn)現(xiàn)在大多數(shù)一版通過(guò)少數(shù)兩版。聯(lián)調(diào)效率之前因字段和狀態(tài)邏輯不一致吵架半天起步現(xiàn)在接口示例和狀態(tài)方案先對(duì)齊基本一輪過(guò)。新手上手速度之前新人要翻遍文檔和代碼才知道一個(gè)功能怎么落地現(xiàn)在看 Task Card 和 Tech Mapping 就能知道思路。上線后的低等級(jí) bug明顯減少因?yàn)?Test Loop 里強(qiáng)制覆蓋了空數(shù)據(jù)和異常輸入。我不說(shuō)具體百分?jǐn)?shù)因?yàn)槟莻€(gè)數(shù)字沒(méi)有統(tǒng)計(jì)嚴(yán)謹(jǐn)性。但方向上很確定返工和扯皮這兩件最消耗團(tuán)隊(duì)精力的事情都有肉眼可見(jiàn)的下降。5.2 三個(gè)讓 t3code 形同虛設(shè)的坑有好用的地方自然也有把它用廢的操作。我見(jiàn)過(guò)、也經(jīng)歷過(guò)幾種典型的翻車方式寫出來(lái)讓大家避一避。第一個(gè)坑是把填卡片當(dāng)成形式主義。有些人表面上填了卡實(shí)際上寫出來(lái)的內(nèi)容跟需求描述沒(méi)區(qū)別全是“優(yōu)化體驗(yàn)”“支持導(dǎo)出”這種無(wú)法驗(yàn)證的話。我處理的方式是抽查開(kāi)會(huì)時(shí)隨機(jī)抽一張卡問(wèn)寫卡的人“這條驗(yàn)收標(biāo)準(zhǔn)你怎么驗(yàn)證跑哪條用例”回答不上來(lái)就打回重寫。逼幾次之后卡片質(zhì)量就正常了。第二個(gè)坑是 Test Loop 變成了“看一眼勾一下”。代碼跑了一遍頁(yè)面出來(lái)了控制臺(tái)都沒(méi)打開(kāi)就在驗(yàn)收標(biāo)準(zhǔn)上全打勾。這不是人的態(tài)度問(wèn)題是流程沒(méi)有提供強(qiáng)制力。后來(lái)我們約定代碼提交信息里必須帶上 Task Card 編號(hào)比如feat: 導(dǎo)出日志 #1024這樣 Git 歷史和驗(yàn)收記錄可以互相對(duì)照誰(shuí)跳過(guò)了驗(yàn)證回溯時(shí)一眼就能看出來(lái)。第三個(gè)坑是卡片寫完了但沒(méi)有人維護(hù)。需求是動(dòng)態(tài)的產(chǎn)品隨時(shí)可能補(bǔ)一句“再加個(gè)匯總行”“默認(rèn)按時(shí)間倒序”但卡片一動(dòng)不動(dòng)。對(duì)付這個(gè)坑我的做法是在團(tuán)隊(duì)里設(shè)了“卡片管家”角色輪流擔(dān)任職責(zé)是每次需求發(fā)生變化后及時(shí)回到卡片里同步驗(yàn)收標(biāo)準(zhǔn)和涉及面。這個(gè)角色不花太多時(shí)間但能讓卡片和現(xiàn)實(shí)保持同步否則 t3code 會(huì)退化成一張廢紙。6. 可以直接抄走的 t3code 模板與落地建議6.1 Task Card 模板與填寫示范如果你也想試著跑一下 t3code可以從下面這張模板開(kāi)始。復(fù)制到你的需求管理工具里或者直接放維基文檔都可以。Task Card任務(wù)卡 任務(wù)編號(hào)CLOUD-271 任務(wù)標(biāo)題管理后臺(tái)操作日志導(dǎo)出 用戶訴求運(yùn)營(yíng)同學(xué)每天早晨需要查看前一日操作記錄目前只能逐頁(yè)瀏覽希望支持一鍵導(dǎo)出。 驗(yàn)收標(biāo)準(zhǔn) 1. 導(dǎo)出文件為 .xlsx文件名包含導(dǎo)出日期。 2. 導(dǎo)出范圍包含當(dāng)前篩選條件下的全部數(shù)據(jù)超過(guò) 10000 條時(shí)自動(dòng)拆分文件。 3. 接口響應(yīng)超過(guò) 10 秒時(shí)轉(zhuǎn)為異步處理完成后提示用戶下載。 4. 空數(shù)據(jù)時(shí)不生成文件提示“暫無(wú)可導(dǎo)出數(shù)據(jù)”。 涉及面 - 改動(dòng)日志查詢接口、導(dǎo)出按鈕、導(dǎo)出文件生成服務(wù)。 - 不動(dòng)權(quán)限控制邏輯、頁(yè)面其他區(qū)域。 風(fēng)險(xiǎn)點(diǎn)大數(shù)據(jù)量導(dǎo)出可能造成內(nèi)存壓力需確認(rèn)分批查詢策略。 預(yù)估時(shí)間1 人天6.2 Tech Mapping 模板與填寫示范第二張表是 Tech Mapping在寫代碼前花 20 分鐘填完。Tech Mapping技術(shù)映射 任務(wù)編號(hào)CLOUD-271 場(chǎng)景用戶點(diǎn)擊“導(dǎo)出”系統(tǒng)生成 .xlsx 文件。 方案前端發(fā)起導(dǎo)出請(qǐng)求后端同步生成若超過(guò) 10 秒則改為異步任務(wù)池處理。 理由當(dāng)前導(dǎo)出量級(jí)最大幾千條同步生成成本低異步只在超閾值時(shí)觸發(fā)。 備選方案全量異步生成 下載中心后續(xù)數(shù)據(jù)量大時(shí)可遷移。 關(guān)鍵問(wèn)題 1. 數(shù)據(jù)從哪來(lái)復(fù)用操作日志查詢接口新增 formatexport 參數(shù)。 2. 狀態(tài)放在哪導(dǎo)出按鈕 loading 狀態(tài)用組件局部 state異步任務(wù)狀態(tài)存后端。 3. 異常情況接口超時(shí)給“操作繁忙”提示無(wú)數(shù)據(jù)給“暫無(wú)可導(dǎo)出數(shù)據(jù)”提示。 4. 如何復(fù)用導(dǎo)出邏輯抽成 services/exportLog.ts后續(xù)其他模塊可復(fù)用。 5. 如何測(cè)試造 10000 條測(cè)試數(shù)據(jù)驗(yàn)證分文件邏輯造 0 條驗(yàn)證空提示。6.3 Test Loop 檢查清單和落地建議最后一張是 Test Loop 檢查清單每次提交代碼前過(guò)一遍[ ] 核心主路徑完整跑通結(jié)果符合預(yù)期。[ ] 空數(shù)據(jù)、邊界值、異常輸入各測(cè)一次。[ ] 對(duì)照 Task Card 驗(yàn)收標(biāo)準(zhǔn)逐條打勾不是看一眼就過(guò)。[ ] 瀏覽器控制臺(tái)無(wú)紅色報(bào)錯(cuò)網(wǎng)絡(luò)面板無(wú) 500 響應(yīng)。[ ] 退出后二次進(jìn)入頁(yè)面狀態(tài)正確。[ ] 提交信息里帶上 Task Card 編號(hào)方便回溯。如果你現(xiàn)在正在被返工和扯皮折磨我的建議是從一張 Task Card 開(kāi)始先不要一次性推完整套 t3code。把當(dāng)前最讓你頭疼的那個(gè)需求寫成卡片把驗(yàn)收標(biāo)準(zhǔn)寫到能打勾的程度寫完代碼后老老實(shí)實(shí)對(duì)著卡片驗(yàn)一遍。哪怕其余流程都先不做這一步就會(huì)讓你對(duì)“做完”的定義透明很多。等找到手感了再把 Think、Transform、Test 三個(gè)環(huán)節(jié)逐步補(bǔ)全。我個(gè)人跑了三周之后最大的體會(huì)是t3code 本質(zhì)上不復(fù)雜它只是把那些我一直覺(jué)得“應(yīng)該做但沒(méi)做”的事情變成了明文規(guī)則而已。 t3code：Think、Transform、Test三步編碼流程，讓需求一次做對(duì)
被“改了三輪”逼出來(lái)的 t3code我給自己定的一套編碼流程如果你也是那種團(tuán)隊(duì)里天天改需求、天天聯(lián)調(diào)吵架、天天上線后半夜看告警的開(kāi)發(fā)者我猜你對(duì)下面這個(gè)場(chǎng)景會(huì)很有共鳴產(chǎn)品經(jīng)理丟過(guò)來(lái)一句話“把列表頁(yè)加個(gè)篩選”然后就沒(méi)有然后了。你憑著直覺(jué)寫了前端、調(diào)了接口、塞了幾個(gè)參數(shù)第二天聯(lián)調(diào)的時(shí)候發(fā)現(xiàn)后端返回的字段結(jié)構(gòu)跟你預(yù)想的完全不一樣產(chǎn)品又補(bǔ)了一句“篩選條件要支持組合”。一個(gè)看起來(lái)半天能搞完的功能硬是來(lái)回改了三個(gè)版本才穩(wěn)住。三個(gè)月前我決定不再讓這種“先寫著看”的狀態(tài)繼續(xù)消耗大家。我給自己所在的開(kāi)發(fā)小組定了一套非常輕量的編碼流程代號(hào)就叫 t3code。t3code 拆開(kāi)來(lái)看就是三個(gè)以 T 開(kāi)頭的動(dòng)作Think想清楚、Transform寫明白、Test驗(yàn)證透。它的核心思路只有一句話把動(dòng)手寫代碼之前的模糊地帶全部顯性化把驗(yàn)收這件事從“上線再說(shuō)”提前到“寫碼前就說(shuō)清”。這篇文章我會(huì)把 t3code 的完整結(jié)構(gòu)、我們團(tuán)隊(duì)實(shí)際用下來(lái)的效果、踩過(guò)的坑以及可以直接抄走的模板都整理出來(lái)。如果你正在被需求反復(fù)、接口扯皮、返工率和線上 bug 折磨而且你所在的團(tuán)隊(duì)沒(méi)有專職測(cè)試、沒(méi)有完整文檔體系那這幾千字應(yīng)該能幫你少走不少?gòu)澛贰?. 被“改了三輪”逼出來(lái)的 t3code它到底解決什么問(wèn)題1.1 那個(gè)熟悉的崩潰現(xiàn)場(chǎng)我們小組負(fù)責(zé)一個(gè) B 端管理后臺(tái)功能不復(fù)雜但節(jié)奏很快通常一個(gè)迭代要排七八個(gè)需求。最常見(jiàn)的流程是需求會(huì)開(kāi)完一句話描述進(jìn)了迭代開(kāi)發(fā)直接開(kāi)寫。聽(tīng)起來(lái)很高效實(shí)際上處處是雷。舉一個(gè)真實(shí)發(fā)生的案例。有人提了個(gè)需求“導(dǎo)出列表數(shù)據(jù)”。開(kāi)發(fā)同學(xué)打開(kāi)代碼就開(kāi)始拼 Excel拼到一半發(fā)現(xiàn)要導(dǎo)出的是過(guò)濾后的數(shù)據(jù)但過(guò)濾狀態(tài)存在前端后端接口不認(rèn)于是開(kāi)始改接口。改完接口又發(fā)現(xiàn)產(chǎn)品要的不只是當(dāng)前列表頁(yè)的數(shù)據(jù)范圍而是要按時(shí)間段跨分頁(yè)導(dǎo)出于是再加參數(shù)。改到第二輪時(shí)發(fā)現(xiàn)導(dǎo)出的字段和后臺(tái)列表展示的字段不一致因?yàn)榱斜眄?yè)做過(guò)字段權(quán)限控制后端接口沒(méi)做。第三輪結(jié)束時(shí)一個(gè)本來(lái)標(biāo)注為 1 天的需求用了 3 天。最要命的是這三天里的每一次改動(dòng)都讓原本以為“已經(jīng)談好”的接口和頁(yè)面結(jié)構(gòu)再松動(dòng)一次。整個(gè)開(kāi)發(fā)過(guò)程不是在寫代碼而是在滅火。問(wèn)題真的出在“需求沒(méi)說(shuō)清”嗎不全是。需求永遠(yuǎn)不可能完全說(shuō)清。真正的問(wèn)題是我們把決策點(diǎn)拖到了寫代碼之后所有模糊地帶都要等到代碼跑起來(lái)才能暴露。1.2 t3code 的三段結(jié)構(gòu)Think、Transform、Testt3code 的模型特別簡(jiǎn)單就是三個(gè)字母T、3、code。T 代表 take3 代表三步code 就是代碼本身。這是我當(dāng)初起名時(shí)偷懶的產(chǎn)物但沒(méi)想到這套結(jié)構(gòu)意外地好記。具體來(lái)說(shuō)Think在寫代碼之前把“到底要做什么”用一張卡片寫下來(lái)。寫清楚用戶訴求、驗(yàn)收標(biāo)準(zhǔn)、涉及面、風(fēng)險(xiǎn)點(diǎn)。這一步逼著你把需求語(yǔ)言翻譯成實(shí)現(xiàn)語(yǔ)言。Transform把卡片上的內(nèi)容轉(zhuǎn)化成技術(shù)方案。數(shù)據(jù)從哪來(lái)、狀態(tài)放哪、異常怎么處理、接口怎么定義、用哪個(gè)技術(shù)方案全部落地成一張 mapping 表。這一步逼著你在動(dòng)手前后心里有數(shù)。Test寫完代碼不是終點(diǎn)。對(duì)照驗(yàn)收標(biāo)準(zhǔn)逐條打勾換一個(gè)視角重新走一遍流程讓第二個(gè)人來(lái)做 code review。這一步逼著你把“我以為做完了”變成“確實(shí)做完了”。三段不是三個(gè)獨(dú)立階段而是一個(gè)閉環(huán)。尤其是 Test 階段發(fā)現(xiàn)的東西要能回溯到 Think 階段的卡片里去修需求理解的偏差而不只是修代碼。我把這個(gè)叫做“回環(huán)式交付”這也是 t3code 和普通開(kāi)發(fā)流程最大的區(qū)別。1.3 它不替代敏捷也不替代代碼規(guī)范很多人一聽(tīng)到“流程”兩個(gè)字就皺眉以為又要開(kāi)會(huì)、寫文檔、做一堆形式主義的東西。我特別能理解這種反感因?yàn)槲乙彩潜桓鞣N重流程折磨過(guò)的人。所以這里先劃清邊界t3code 不是來(lái)替代敏捷開(kāi)發(fā)、TAPD、Jira、代碼規(guī)范這些東西的。敏捷管的是迭代節(jié)奏和協(xié)作儀式規(guī)范管的是代碼長(zhǎng)什么樣Commit 消息怎么寫函數(shù)怎么拆。t3code 管的是另一件事每一次動(dòng)手寫代碼之前的決策鏈。它很小小到一個(gè)人寫腳本也能用小到不需要任何工具一張紙一支筆就能跑。所以我在團(tuán)隊(duì)里推的時(shí)候沒(méi)有要求大家改變?cè)械捻?xiàng)目管理和代碼評(píng)審流程只是要求在原有流程里嵌入三個(gè)新的動(dòng)作寫卡、畫 mapping、跑 test loop。這也是它能堅(jiān)持下來(lái)的原因—— 加入的成本足夠低大家才愿意用。2. Task Card把需求從“大概”逼到“顆?！?.1 先寫卡片再動(dòng)手卡片長(zhǎng)什么樣t3code 的第一步是寫 Task Card也就是任務(wù)卡。這是整個(gè)流程的地基。我見(jiàn)過(guò)太多需求描述就是一句話“優(yōu)化加載速度”“列表加個(gè)導(dǎo)出”這種描述寫完代碼之后你根本無(wú)法判斷自己到底做沒(méi)做對(duì)標(biāo)準(zhǔn)太模糊了。我們的 Task Card 固定包含下面幾個(gè)字段任務(wù)編號(hào)對(duì)應(yīng)迭代里的編號(hào)方便追溯。用戶訴求誰(shuí)在什么場(chǎng)景下遇到了什么問(wèn)題希望得到什么結(jié)果。必須寫具體的人具體的場(chǎng)景。驗(yàn)收標(biāo)準(zhǔn)做到什么程度算完成。這是整張卡片最核心的部分必須是可以驗(yàn)證的、可勾選的要點(diǎn)。涉及面改動(dòng)會(huì)碰哪些模塊哪些地方明確不動(dòng)。風(fēng)險(xiǎn)點(diǎn)這個(gè)任務(wù)里你不知道的事、可能出問(wèn)題的地方。預(yù)估時(shí)間只做粗粒度評(píng)估不搞精細(xì)估點(diǎn)。舉個(gè)例子。我們做一個(gè)“給管理后臺(tái)加導(dǎo)出日志”的需求卡片是這么寫的用戶訴求運(yùn)營(yíng)同學(xué)每天早晨要看前一日的操作記錄目前只能一頁(yè)一頁(yè)翻效率低希望可以一鍵導(dǎo)出 Excel。驗(yàn)收標(biāo)準(zhǔn)導(dǎo)出文件為.xlsx格式文件名帶日期。導(dǎo)出內(nèi)容包含當(dāng)前篩選條件下的全部數(shù)據(jù)超過(guò) 10000 條時(shí)自動(dòng)分文件。導(dǎo)出時(shí)間超過(guò) 10 秒時(shí)后臺(tái)異步生成用戶生成后收到下載提示。涉及面操作日志查詢接口、前端導(dǎo)出按鈕、后臺(tái)文件生成服務(wù)。權(quán)限邏輯不動(dòng)。風(fēng)險(xiǎn)點(diǎn)導(dǎo)出的數(shù)據(jù)量如果過(guò)大服務(wù)端內(nèi)存可能吃緊需要考慮分批查詢。預(yù)估時(shí)間1 人天。寫這張卡片的過(guò)程其實(shí)就是把需求逼到可執(zhí)行的過(guò)程。你會(huì)發(fā)現(xiàn)很多原來(lái)看起來(lái)“很簡(jiǎn)單”的需求在填寫這些字段時(shí)會(huì)暴露出大量空白。比如什么叫“一鍵導(dǎo)出”導(dǎo)出當(dāng)前頁(yè)還是全部要不要帶篩選條件這些問(wèn)題的答案在卡片階段就找出來(lái)總比在代碼寫完以后被人追著問(wèn)強(qiáng)。2.2 拆分顆粒度的兩小時(shí)原則Task Card 拆多細(xì)是個(gè)非常實(shí)際的問(wèn)題。拆太粗卡片失去指導(dǎo)意義寫出來(lái)跟需求描述沒(méi)區(qū)別拆太細(xì)一天產(chǎn)生幾十張卡片管理卡片的時(shí)間比寫代碼還多。我實(shí)踐下來(lái)最好用的標(biāo)準(zhǔn)是“兩小時(shí)原則”一張卡片的主體編碼工作量應(yīng)該在兩小時(shí)左右完成。這個(gè)原則不是寫死的規(guī)定它是一個(gè)信號(hào)。如果你發(fā)現(xiàn)一張卡片要寫兩天說(shuō)明任務(wù)沒(méi)有拆透里面還藏著多個(gè)決策點(diǎn)。比如“實(shí)現(xiàn)用戶登錄”這個(gè)描述就是典型的大顆?？ㄋ鋵?shí)可以拆成“前端登錄表單與校驗(yàn)”“后端登錄接口與 token 簽發(fā)”“登錄態(tài)刷新與過(guò)期處理”“記住密碼功能”四張卡每一張都對(duì)應(yīng)一個(gè)可以獨(dú)立驗(yàn)證的成果。反過(guò)來(lái)如果你發(fā)現(xiàn)寫卡片的時(shí)間比寫代碼的時(shí)間還長(zhǎng)說(shuō)明拆得太細(xì)了。我看過(guò)有人把“給按鈕加個(gè) loading 態(tài)”都單獨(dú)建一張卡那屬于過(guò)度拆解看起來(lái)顆粒度很漂亮實(shí)際上在純消耗團(tuán)隊(duì)精力。兩小時(shí)原則的核心目的是逼你進(jìn)入“可預(yù)估”狀態(tài)能預(yù)估的東西才能排期能排期的東西才談得上質(zhì)量和進(jìn)度。2.3 寫驗(yàn)收標(biāo)準(zhǔn)的三個(gè)反常識(shí)細(xì)節(jié)Task Card 里最容易寫廢的就是驗(yàn)收標(biāo)準(zhǔn)而驗(yàn)收標(biāo)準(zhǔn)恰恰是最不能含糊的部分。我們?cè)谕菩羞^(guò)程中總結(jié)了三個(gè)經(jīng)驗(yàn)聽(tīng)起來(lái)有點(diǎn)反常識(shí)但非常有用。第一不要用“優(yōu)化”“完善”“增強(qiáng)”這類動(dòng)詞。這些詞的正確用法是零因?yàn)闆](méi)人知道“優(yōu)化完”是什么樣。驗(yàn)收標(biāo)準(zhǔn)里必須出現(xiàn)具體的字段、數(shù)值、邊界。把“優(yōu)化加載速度”改成“首屏接口返回時(shí)間在 2G 網(wǎng)絡(luò)下不超過(guò) 3 秒”這才是一條能驗(yàn)證的標(biāo)準(zhǔn)。第二驗(yàn)收標(biāo)準(zhǔn)必須寫明“不做的事”。比如需求是做篩選要明確“不做模糊搜索只做精確匹配”需求是導(dǎo)出要明確“不含匯總行”。這不是在縮需求這是在劃邊界。沒(méi)有邊界任何人都可以在評(píng)審的時(shí)候把自己的想象當(dāng)成需求本身。第三驗(yàn)收標(biāo)準(zhǔn)要寫“反過(guò)來(lái)也要能驗(yàn)證”。比如一個(gè)校驗(yàn)邏輯不僅要說(shuō)清“手機(jī)號(hào)格式錯(cuò)誤給出提示”還要寫“格式正確時(shí)能正常通過(guò)”。只測(cè)正確路徑不測(cè)錯(cuò)誤路徑是測(cè)試階段最大的盲區(qū)而這些盲區(qū)恰恰應(yīng)該在寫卡時(shí)就想到。3. Tech Mapping寫代碼前先跑一遍“地圖”3.1 技術(shù)選型不是臨場(chǎng)發(fā)揮Task Card 寫完確認(rèn)大家對(duì)齊了“做什么”接下來(lái)就是 t3code 的第二個(gè) TTransform。這個(gè)階段解決的是“怎么做”。我觀察過(guò)不少開(kāi)發(fā)者也包括我自己年輕時(shí)候的樣子拿到需求打開(kāi)編輯器遇到什么問(wèn)題開(kāi)始查什么問(wèn)題。比如寫著寫著發(fā)現(xiàn)要用防抖就開(kāi)始翻文檔找防抖函數(shù)寫著寫著發(fā)現(xiàn)要傳日期范圍才開(kāi)始定義接口參數(shù)。這種方式不是絕對(duì)不能出活但它最大的問(wèn)題是把技術(shù)決策逼到代碼行數(shù)里去導(dǎo)致決策本身沒(méi)有經(jīng)過(guò)推敲。Tech Mapping 就是專門治這個(gè)毛病的。它要求你在寫代碼之前把關(guān)鍵場(chǎng)景和技術(shù)方案列成一張映射表。一列是場(chǎng)景一列是方案一列是選擇這個(gè)方案的理由還可以加上備選方案和驗(yàn)證方式。做完這張表你心里就對(duì)整段代碼的結(jié)構(gòu)有了數(shù)。舉個(gè)例子我們要實(shí)現(xiàn)一個(gè)站內(nèi)通知功能。Mapping 表大概是這樣的場(chǎng)景用戶觸發(fā)某操作后需要收到實(shí)時(shí)通知。方案前端輪詢接口每 30 秒拉取一次未讀數(shù)量。理由通知實(shí)時(shí)性要求不高輪詢實(shí)現(xiàn)成本最低不需要引入 WebSocket 長(zhǎng)連接也不需要考慮斷線重連問(wèn)題。備選方案SSE 或 WebSocket后續(xù)如果實(shí)時(shí)性要求變高再遷移。驗(yàn)證方式用一個(gè)測(cè)試賬號(hào)觸發(fā)操作觀察 30 秒內(nèi)未讀數(shù)量刷新。這張表的價(jià)值不在于方案有多高級(jí)而在于把“選型”這個(gè)過(guò)程顯性化了。哪怕你最后用了最笨的方案只要理由站得住這段代碼在評(píng)審時(shí)的說(shuō)服力就完全不一樣。3.2 開(kāi)工前必過(guò)的五個(gè)問(wèn)題我跑了一段時(shí)間的 Tech Mapping 后發(fā)現(xiàn)不同任務(wù)的 mapping 表雖然內(nèi)容不一樣但核心問(wèn)題高度重復(fù)。最后我把它們收斂成五個(gè)必問(wèn)題數(shù)據(jù)從哪來(lái)對(duì)應(yīng)的接口是什么返回結(jié)構(gòu)長(zhǎng)什么樣需要新寫接口還是復(fù)用已有接口狀態(tài)放在哪是組件本地 state、全局 store還是服務(wù)端放錯(cuò)位置是很多 bug 的根源。異常情況怎么辦接口超時(shí)、返回空數(shù)據(jù)、字段缺失、權(quán)限不足每種異常的處理路徑是什么怎么被復(fù)用這個(gè)功能除了當(dāng)前場(chǎng)景還有沒(méi)有別的地方會(huì)用設(shè)計(jì)時(shí)是否要考慮參數(shù)化怎么測(cè)試手工點(diǎn)擊能不能覆蓋需不需要補(bǔ)單元測(cè)試核心邏輯是否有辦法自動(dòng)化驗(yàn)證這五個(gè)問(wèn)題對(duì)后端開(kāi)發(fā)同樣適用只是換一下措辭數(shù)據(jù)在哪張表、緩存怎么失效、接口要不要做冪等、要不要異步處理、監(jiān)控和日志怎么加。每個(gè)問(wèn)題都要求當(dāng)場(chǎng)給出答案給不出來(lái)的部分就是整個(gè)實(shí)現(xiàn)的真實(shí)風(fēng)險(xiǎn)點(diǎn)。用一張 mapping 表把所有風(fēng)險(xiǎn)點(diǎn)攤在桌面上比讓它們?cè)诖a里冒出來(lái)要省心得多。3.3 把接口示例寫死的聯(lián)調(diào)血淚教訓(xùn)Tech Mapping 階段最容易忽略但也最值得做的一件事是在動(dòng)手前把接口的請(qǐng)求參數(shù)和響應(yīng)示例寫死。這是我們從一次慘痛聯(lián)調(diào)里換來(lái)的教訓(xùn)。當(dāng)時(shí)前后端并行開(kāi)發(fā)后端按“返回碼 數(shù)據(jù)體”的結(jié)構(gòu)定義接口前端默認(rèn)后端會(huì)返回扁平結(jié)構(gòu)。兩邊都覺(jué)得自己理解得很透徹直到聯(lián)調(diào)那天第一行代碼跑起來(lái)發(fā)現(xiàn)字段對(duì)不上前端要的名字是lastUpdatedAt后端返回的是updateTime前端希望 error 是一個(gè)對(duì)象后端返回的是一個(gè)字符串。一個(gè)看起來(lái)極其簡(jiǎn)單的接口聯(lián)調(diào)和修改花了整整一個(gè)下午還連累了進(jìn)度。之后我在 Tech Mapping 里加了一條硬性要求只要任務(wù)涉及后端接口卡片里必須寫清“請(qǐng)求示例”和“響應(yīng)示例”兩邊照著示例開(kāi)發(fā)。不要說(shuō)什么“按接口文檔”小團(tuán)隊(duì)的接口文檔往往是過(guò)期文檔。直接在卡片里貼 JSON 示例以例為準(zhǔn)不扯文檔不猜結(jié)構(gòu)。用了這個(gè)辦法以后聯(lián)調(diào)會(huì)議里因?yàn)樽侄蚊臣艿那闆r基本消失了。4. Test Loop讓驗(yàn)證成為肌肉記憶而不是最后沖刺4.1 三層驗(yàn)證節(jié)奏怎么跑t3code 的第三個(gè) T 是 Test但這里的 Test 不只是“跑一下功能”而是指一個(gè)固定的驗(yàn)證循環(huán)。我把它拆成三層對(duì)應(yīng)著三個(gè)不同角色第一層是開(kāi)發(fā)者本人自測(cè)。寫完代碼后立刻把核心路徑跑一遍不要寫完就丟給測(cè)試或 reviewer。這個(gè)階段我要求自己至少回答一個(gè)問(wèn)題我寫的代碼在最常見(jiàn)的輸入下能不能工作很多時(shí)候不能因?yàn)槿藭?huì)想當(dāng)然。第二層是照卡驗(yàn)收。拿出 Task Card對(duì)著驗(yàn)收標(biāo)準(zhǔn)逐條打勾。這一層最容易被跳過(guò)因?yàn)榇蟛糠珠_(kāi)發(fā)覺(jué)得“代碼都寫了驗(yàn)收當(dāng)然沒(méi)問(wèn)題”。但實(shí)際上一旦你認(rèn)真過(guò)這一層會(huì)發(fā)現(xiàn)缺口比想象中多有的標(biāo)準(zhǔn)寫的是超 10000 條分文件但測(cè)試數(shù)據(jù)只有三條有的標(biāo)準(zhǔn)要求 10 秒后異步生成但實(shí)現(xiàn)里根本沒(méi)做異步。不是寫的時(shí)候故意漏是因?yàn)闆](méi)有把標(biāo)準(zhǔn)和實(shí)現(xiàn)對(duì)照。第三層是旁觀者驗(yàn)證。把卡片和代碼交給另一個(gè)人讓他用完全不懂實(shí)現(xiàn)細(xì)節(jié)的方式去操作。思路很簡(jiǎn)單自己寫的東西自己總是默認(rèn)它是對(duì)的一句提示文案寫錯(cuò)位置自己看三遍可能都發(fā)現(xiàn)不了但一個(gè)旁觀者兩分鐘就能看出來(lái)。這個(gè)旁觀者可以是同事也可以是第二天早高峰的自己。4.2 沒(méi)有專職測(cè)試的小團(tuán)隊(duì)怎么設(shè)驗(yàn)收規(guī)則我們團(tuán)隊(duì)沒(méi)有專職測(cè)試人員所以 Test Loop 的設(shè)計(jì)必須考慮“低成本可執(zhí)行”這個(gè)約束。我定的規(guī)則是一張卡片的完整驗(yàn)收時(shí)間不應(yīng)該超過(guò) 10 分鐘。如果超過(guò) 10 分鐘才驗(yàn)完那說(shuō)明卡片拆大了或者驗(yàn)收標(biāo)準(zhǔn)寫得不夠收斂。在這個(gè)約束下有幾類驗(yàn)證必須放進(jìn)去核心主路徑用戶最常用的操作路徑跑一遍要通?？諗?shù)據(jù)和邊界值查詢結(jié)果為空、參數(shù)長(zhǎng)度為 0、金額為 0、分頁(yè)超過(guò)最大頁(yè)這類最容易出 bug 的場(chǎng)景絕不能少。異常輸入格式錯(cuò)誤、非法值、越權(quán)操作要確認(rèn)系統(tǒng)給出的提示合理而不是白屏或者報(bào)錯(cuò)?？刂婆_(tái)無(wú)紅色報(bào)錯(cuò)我們明確要求驗(yàn)證時(shí)打開(kāi)瀏覽器控制臺(tái)不是看一眼頁(yè)面就完事。二次進(jìn)入退出后重新進(jìn)入頁(yè)面狀態(tài)要重置或者正確恢復(fù)。很多 bug 就藏在“第一次進(jìn)沒(méi)事第二次進(jìn)崩了”。這種驗(yàn)證姿勢(shì)肯定不能和專職 QA 團(tuán)隊(duì)相比但對(duì)小團(tuán)隊(duì)來(lái)說(shuō)已經(jīng)足夠把大部分低級(jí) bug 擋在上線之前。關(guān)鍵是形成肌肉記憶而不是靠某一天心情好就多測(cè)點(diǎn)。4.3 復(fù)盤會(huì)怎么開(kāi)才不至于變成批斗會(huì)Test Loop 跑完后如果發(fā)現(xiàn)問(wèn)題t3code 要求回到卡片去修正理解而不是只改代碼。這個(gè)環(huán)節(jié)我們是通過(guò)每周一次的小復(fù)盤來(lái)落地的。復(fù)盤最忌諱開(kāi)成批斗會(huì)。第一次我們開(kāi)會(huì)時(shí)所有人都不說(shuō)話氣氛非常尷尬。后來(lái)我自己先拿一個(gè)反例開(kāi)刀我寫過(guò)一張卡片驗(yàn)收標(biāo)準(zhǔn)和實(shí)際實(shí)現(xiàn)差了十萬(wàn)八千里原因是把測(cè)試環(huán)境和生產(chǎn)環(huán)境的配置混在一起看問(wèn)題。我講完自己的失誤大家才開(kāi)始放松。復(fù)盤會(huì)我們只用 15 分鐘挑一個(gè)最有代表性的 Task走一遍三連問(wèn)Think 階段漏掉了什么Transform 階段哪里走彎路Test 階段為什么沒(méi)有兜住不用 PPT不用投影拉一個(gè)共享文檔記錄結(jié)論就行。這個(gè)會(huì)很短但每周都開(kāi)效果比一個(gè)月開(kāi)一次三小時(shí)的總結(jié)會(huì)扎實(shí)得多。5. 跑了三周的真實(shí)變化與最容易翻車的執(zhí)行細(xì)節(jié)5.1 一張對(duì)比表看看前后差別t3code 在我們小范圍內(nèi)跑了三周中間并不是一帆風(fēng)順但整體變化非常明顯。我用一張不完全精確的對(duì)比表來(lái)呈現(xiàn)當(dāng)時(shí)的感受需求澄清時(shí)間之前要等到寫代碼中途或聯(lián)調(diào)時(shí)發(fā)現(xiàn)問(wèn)題醒過(guò)來(lái)已經(jīng)是第三天現(xiàn)在是寫卡時(shí)就爭(zhēng)論清楚第一天就解決。返工率之前一個(gè)功能平均改兩到三版才穩(wěn)現(xiàn)在大多數(shù)一版通過(guò)少數(shù)兩版。聯(lián)調(diào)效率之前因字段和狀態(tài)邏輯不一致吵架半天起步現(xiàn)在接口示例和狀態(tài)方案先對(duì)齊基本一輪過(guò)。新手上手速度之前新人要翻遍文檔和代碼才知道一個(gè)功能怎么落地現(xiàn)在看 Task Card 和 Tech Mapping 就能知道思路。上線后的低等級(jí) bug明顯減少因?yàn)?Test Loop 里強(qiáng)制覆蓋了空數(shù)據(jù)和異常輸入。我不說(shuō)具體百分?jǐn)?shù)因?yàn)槟莻€(gè)數(shù)字沒(méi)有統(tǒng)計(jì)嚴(yán)謹(jǐn)性。但方向上很確定返工和扯皮這兩件最消耗團(tuán)隊(duì)精力的事情都有肉眼可見(jiàn)的下降。5.2 三個(gè)讓 t3code 形同虛設(shè)的坑有好用的地方自然也有把它用廢的操作。我見(jiàn)過(guò)、也經(jīng)歷過(guò)幾種典型的翻車方式寫出來(lái)讓大家避一避。第一個(gè)坑是把填卡片當(dāng)成形式主義。有些人表面上填了卡實(shí)際上寫出來(lái)的內(nèi)容跟需求描述沒(méi)區(qū)別全是“優(yōu)化體驗(yàn)”“支持導(dǎo)出”這種無(wú)法驗(yàn)證的話。我處理的方式是抽查開(kāi)會(huì)時(shí)隨機(jī)抽一張卡問(wèn)寫卡的人“這條驗(yàn)收標(biāo)準(zhǔn)你怎么驗(yàn)證跑哪條用例”回答不上來(lái)就打回重寫。逼幾次之后卡片質(zhì)量就正常了。第二個(gè)坑是 Test Loop 變成了“看一眼勾一下”。代碼跑了一遍頁(yè)面出來(lái)了控制臺(tái)都沒(méi)打開(kāi)就在驗(yàn)收標(biāo)準(zhǔn)上全打勾。這不是人的態(tài)度問(wèn)題是流程沒(méi)有提供強(qiáng)制力。后來(lái)我們約定代碼提交信息里必須帶上 Task Card 編號(hào)比如feat: 導(dǎo)出日志 #1024這樣 Git 歷史和驗(yàn)收記錄可以互相對(duì)照誰(shuí)跳過(guò)了驗(yàn)證回溯時(shí)一眼就能看出來(lái)。第三個(gè)坑是卡片寫完了但沒(méi)有人維護(hù)。需求是動(dòng)態(tài)的產(chǎn)品隨時(shí)可能補(bǔ)一句“再加個(gè)匯總行”“默認(rèn)按時(shí)間倒序”但卡片一動(dòng)不動(dòng)。對(duì)付這個(gè)坑我的做法是在團(tuán)隊(duì)里設(shè)了“卡片管家”角色輪流擔(dān)任職責(zé)是每次需求發(fā)生變化后及時(shí)回到卡片里同步驗(yàn)收標(biāo)準(zhǔn)和涉及面。這個(gè)角色不花太多時(shí)間但能讓卡片和現(xiàn)實(shí)保持同步否則 t3code 會(huì)退化成一張廢紙。6. 可以直接抄走的 t3code 模板與落地建議6.1 Task Card 模板與填寫示范如果你也想試著跑一下 t3code可以從下面這張模板開(kāi)始。復(fù)制到你的需求管理工具里或者直接放維基文檔都可以。Task Card任務(wù)卡 任務(wù)編號(hào)CLOUD-271 任務(wù)標(biāo)題管理后臺(tái)操作日志導(dǎo)出 用戶訴求運(yùn)營(yíng)同學(xué)每天早晨需要查看前一日操作記錄目前只能逐頁(yè)瀏覽希望支持一鍵導(dǎo)出。 驗(yàn)收標(biāo)準(zhǔn) 1. 導(dǎo)出文件為 .xlsx文件名包含導(dǎo)出日期。 2. 導(dǎo)出范圍包含當(dāng)前篩選條件下的全部數(shù)據(jù)超過(guò) 10000 條時(shí)自動(dòng)拆分文件。 3. 接口響應(yīng)超過(guò) 10 秒時(shí)轉(zhuǎn)為異步處理完成后提示用戶下載。 4. 空數(shù)據(jù)時(shí)不生成文件提示“暫無(wú)可導(dǎo)出數(shù)據(jù)”。 涉及面 - 改動(dòng)日志查詢接口、導(dǎo)出按鈕、導(dǎo)出文件生成服務(wù)。 - 不動(dòng)權(quán)限控制邏輯、頁(yè)面其他區(qū)域。 風(fēng)險(xiǎn)點(diǎn)大數(shù)據(jù)量導(dǎo)出可能造成內(nèi)存壓力需確認(rèn)分批查詢策略。 預(yù)估時(shí)間1 人天6.2 Tech Mapping 模板與填寫示范第二張表是 Tech Mapping在寫代碼前花 20 分鐘填完。Tech Mapping技術(shù)映射 任務(wù)編號(hào)CLOUD-271 場(chǎng)景用戶點(diǎn)擊“導(dǎo)出”系統(tǒng)生成 .xlsx 文件。 方案前端發(fā)起導(dǎo)出請(qǐng)求后端同步生成若超過(guò) 10 秒則改為異步任務(wù)池處理。 理由當(dāng)前導(dǎo)出量級(jí)最大幾千條同步生成成本低異步只在超閾值時(shí)觸發(fā)。 備選方案全量異步生成 下載中心后續(xù)數(shù)據(jù)量大時(shí)可遷移。 關(guān)鍵問(wèn)題 1. 數(shù)據(jù)從哪來(lái)復(fù)用操作日志查詢接口新增 formatexport 參數(shù)。 2. 狀態(tài)放在哪導(dǎo)出按鈕 loading 狀態(tài)用組件局部 state異步任務(wù)狀態(tài)存后端。 3. 異常情況接口超時(shí)給“操作繁忙”提示無(wú)數(shù)據(jù)給“暫無(wú)可導(dǎo)出數(shù)據(jù)”提示。 4. 如何復(fù)用導(dǎo)出邏輯抽成 services/exportLog.ts后續(xù)其他模塊可復(fù)用。 5. 如何測(cè)試造 10000 條測(cè)試數(shù)據(jù)驗(yàn)證分文件邏輯造 0 條驗(yàn)證空提示。6.3 Test Loop 檢查清單和落地建議最后一張是 Test Loop 檢查清單每次提交代碼前過(guò)一遍[ ] 核心主路徑完整跑通結(jié)果符合預(yù)期。[ ] 空數(shù)據(jù)、邊界值、異常輸入各測(cè)一次。[ ] 對(duì)照 Task Card 驗(yàn)收標(biāo)準(zhǔn)逐條打勾不是看一眼就過(guò)。[ ] 瀏覽器控制臺(tái)無(wú)紅色報(bào)錯(cuò)網(wǎng)絡(luò)面板無(wú) 500 響應(yīng)。[ ] 退出后二次進(jìn)入頁(yè)面狀態(tài)正確。[ ] 提交信息里帶上 Task Card 編號(hào)方便回溯。如果你現(xiàn)在正在被返工和扯皮折磨我的建議是從一張 Task Card 開(kāi)始先不要一次性推完整套 t3code。把當(dāng)前最讓你頭疼的那個(gè)需求寫成卡片把驗(yàn)收標(biāo)準(zhǔn)寫到能打勾的程度寫完代碼后老老實(shí)實(shí)對(duì)著卡片驗(yàn)一遍。哪怕其余流程都先不做這一步就會(huì)讓你對(duì)“做完”的定義透明很多。等找到手感了再把 Think、Transform、Test 三個(gè)環(huán)節(jié)逐步補(bǔ)全。我個(gè)人跑了三周之后最大的體會(huì)是t3code 本質(zhì)上不復(fù)雜它只是把那些我一直覺(jué)得“應(yīng)該做但沒(méi)做”的事情變成了明文規(guī)則而已。