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