上午十點(diǎn)新接手的任務(wù)單里躺著一行字abd 3deathq3*1 dc*2。沒有設(shè)計(jì)文檔沒有驗(yàn)收說明上一任開發(fā)只留下一句“之前的需求就是這么寫的”。我盯著這串由前綴、數(shù)字、星號(hào)和括號(hào)組成的內(nèi)容看了很久。abd到底是指哪個(gè)場(chǎng)景還是某個(gè)系統(tǒng)的縮寫3death是允許玩家死亡三次還是要求觸發(fā)三次死亡q3*1是任務(wù)編號(hào) q3 完成一次還是第 3 季度內(nèi)的 1 個(gè)指標(biāo)dc*2又到底是通關(guān)兩次、參與兩次還是數(shù)據(jù)采集兩次這類暗號(hào)式需求在一些快速迭代的項(xiàng)目里并不罕見。它看起來像一行配置實(shí)際卻是一個(gè)團(tuán)隊(duì)把一個(gè)需要多方確認(rèn)的驗(yàn)收規(guī)則壓縮成了只有少數(shù)人能讀懂的“壓縮包”。而真正危險(xiǎn)的并不是這行字本身是壓縮包丟失了上下文之后接手的開發(fā)只能靠猜。1. 一行暗號(hào)并不是需求它只是需求的“壓縮包”先把一個(gè)觀點(diǎn)放前面拿到這種字符串時(shí)最重要的不是去猜它到底代表什么而是把猜測(cè)變成一份可以被對(duì)方確認(rèn)的清單。猜得對(duì)那只是運(yùn)氣好猜錯(cuò)了后面所有實(shí)現(xiàn)、測(cè)試、驗(yàn)收都會(huì)跟著錯(cuò)而且錯(cuò)得很隱蔽。1.1 先把符號(hào)拆開逐項(xiàng)列出可能含義我習(xí)慣先按分隔符把整串拆開。這里的顯式結(jié)構(gòu)是abd—— 一個(gè)沒有花括號(hào)、沒有下劃線的前綴詞3death—— 數(shù)字開頭后面跟英文單詞q3*1—— 短編號(hào)加乘號(hào)加次數(shù)dc*2—— 兩個(gè)字母縮寫加乘號(hào)加次數(shù)外層括號(hào)把q3*1 dc*2圈在了一起。如果這是游戲服務(wù)器配置里的日常任務(wù)、挑戰(zhàn)副本或成就條件的寫法那么名稱*次數(shù)在不少項(xiàng)目里確實(shí)表示“目標(biāo)完成 N 次”。q3可能是任務(wù) IDdc可能是某個(gè)副本的通關(guān)縮寫。括號(hào)則表示這兩個(gè)目標(biāo)是一個(gè)組合關(guān)系。但這只能作為“待確認(rèn)假設(shè)”不能作為事實(shí)。同樣一帶3death在 A 團(tuán)隊(duì)里可能是“累計(jì)死亡達(dá)到 3 次后判定失敗”在 B 團(tuán)隊(duì)里可能是“最多允許 3 次死亡超過則挑戰(zhàn)失敗”在 C 團(tuán)隊(duì)里甚至可能是“玩家死亡 3 次后觸發(fā)一個(gè)特殊增益狀態(tài)”。三種理解對(duì)程序邏輯的要求完全不同。片段常見可能含義對(duì)邏輯的影響abd副本、活動(dòng)、任務(wù)組代號(hào)決定觸發(fā)場(chǎng)景和校驗(yàn)范圍3death死亡次數(shù)限制 / 達(dá)成條件 / 狀態(tài)觸發(fā)器決定它是“紅線”還是“進(jìn)度目標(biāo)”q3*1任務(wù) q3 完成 1 次計(jì)數(shù)型目標(biāo)可能需要事件驅(qū)動(dòng)dc*2通關(guān)或參與 dc 共 2 次計(jì)數(shù)型目標(biāo)需要確認(rèn)是否要求通關(guān)成功括號(hào)組合條件區(qū)域決定目標(biāo)是并列還是嵌套關(guān)系遇到類似的字符串我會(huì)先把這張表寫出來隨需求單一起發(fā)給真正知道業(yè)務(wù)的人去確認(rèn)。這樣做的價(jià)值在于別人可以看到“我理解成了什么哪些我拿不準(zhǔn)”而不是等我做完了才說“不對(duì)3death 是限制不能超過三次”。1.2 先確認(rèn)語義再碰代碼很多人拿到這種需求會(huì)直接開始寫代碼因?yàn)樽址旧砗芟褚欢慰山馕龅呐渲谩５馕霾皇亲铍y的解析后的語義映射才是。舉個(gè)最典型的例子3death是條件還是限制如果是“允許死亡三次”的挑戰(zhàn)模式那么玩家死亡三次是不會(huì)失敗的反而可能要在三次死亡內(nèi)完成q3一次和dc兩次如果是“死亡超過三次挑戰(zhàn)失敗”那它就是一條負(fù)向的失敗規(guī)則不參與進(jìn)度累計(jì)只在事件發(fā)生時(shí)做判斷。這兩種寫法的代碼結(jié)構(gòu)、測(cè)試用例、埋點(diǎn)日志全部不一樣。沒有確認(rèn)語義之前代碼寫得越快返工成本越高。所以我在這個(gè)階段通常會(huì)做三件事把整條字符串拆成 token 列表寫上自己的猜測(cè)。每一個(gè) token 至少列出兩種可能含義特別標(biāo)出彼此矛盾的地方。把假設(shè)清單發(fā)給需求方并請(qǐng)對(duì)方做一次“逐行打勾”的確認(rèn)而不是問“這個(gè)需求是什么意思”這種開放式問題。只問開放問題對(duì)方大概率會(huì)回一句“你自己看下舊配置”。把假設(shè)列出來對(duì)方只需要回復(fù)“對(duì)、不對(duì)、改成什么”溝通效率完全不一樣。2. 拆完暗號(hào)之后把它回寫成一張驗(yàn)收規(guī)格假設(shè)我們假設(shè)性確認(rèn)了一版語義abd是某個(gè)挑戰(zhàn)場(chǎng)景的代號(hào)場(chǎng)景內(nèi)有一個(gè)挑戰(zhàn)任務(wù)允許的失敗次數(shù)和死亡相關(guān)玩家需要在挑戰(zhàn)期間完成q3一次、dc兩次。那么下一步不是建表而是把這句話回寫成可驗(yàn)收的規(guī)則表。2.1 一句話假設(shè)和一張規(guī)則表我常用一個(gè)固定句式來濃縮需求在什么場(chǎng)景下玩家做什么事做多少次中間什么情況會(huì)導(dǎo)致失敗最后怎么結(jié)算。套到演示例子里可以寫成在 abd 挑戰(zhàn)開放期間玩家需要在死亡次數(shù)不超過 3 次的前提下完成 q3 任務(wù) 1 次并且通關(guān) dc 副本 2 次全部滿足則挑戰(zhàn)成功。這只是一個(gè)演示假設(shè)不代表原串的真實(shí)含義但它已經(jīng)足夠支撐我們?cè)O(shè)計(jì)一張規(guī)格表項(xiàng)目規(guī)則觸發(fā)范圍abd對(duì)應(yīng)場(chǎng)景激活后開始記錄目標(biāo) A完成q3任務(wù)次數(shù) ≥ 1目標(biāo) B通關(guān)dc次數(shù) ≥ 2失敗條件挑戰(zhàn)期間累計(jì)死亡次數(shù) ≥ 3目標(biāo)關(guān)系A(chǔ) 與 B 同時(shí)達(dá)成才算完成順序要求默認(rèn)不做順序要求待確認(rèn)死亡是否重置進(jìn)度待確認(rèn)這張表不一定正確但它是一個(gè)“完成了思考過程”的產(chǎn)物。它把字符串里被壓掉的信息展開成了每個(gè)字段任何后續(xù)參與的人都能看懂并且指出問題。2.2 真正要對(duì)齊的是“邊界條件”規(guī)格表里最容易漏的不是正常路徑而是邊界條件。正常路徑只要照著規(guī)則寫就行邊界條件才會(huì)暴露實(shí)現(xiàn)差異。圍繞演示規(guī)則至少要追問這些問題玩家先完成了q3一次再進(jìn)挑戰(zhàn)算不算數(shù)如果死亡三次立刻失敗失敗之后已經(jīng)完成的q3和dc進(jìn)度還保留嗎dc中途退出算不算一次通關(guān)組隊(duì)時(shí)隊(duì)員完成算不算隊(duì)長(zhǎng)的進(jìn)度q3和dc如果指向同一場(chǎng)戰(zhàn)斗同一個(gè)事件到達(dá)計(jì)數(shù)層時(shí)是各自加一還是會(huì)被去重挑戰(zhàn)到期或被重置時(shí)進(jìn)度是否清零有沒有發(fā)現(xiàn)這串暗號(hào)里根本不含這些信息。這些都需要靠另外的文檔、經(jīng)驗(yàn)或在線問答去對(duì)齊。對(duì)齊之后才能真正進(jìn)入編碼階段。這也是為什么我會(huì)說一行這樣的字符串不是一個(gè)可交付的需求它只是一條引子。3. 別把規(guī)則寫死在流程里優(yōu)先做成配置就算一次只接一個(gè)任務(wù)也不要在一堆業(yè)務(wù)方法里硬編碼條件判斷。原因不是“這樣更優(yōu)雅”而是這類玩法需求通常不會(huì)只改一次。今天3death明天可能變成1death今天要求q3一次下個(gè)版本可能還要加一個(gè)q4*1。我見過大量線上改版事故本質(zhì)都不是算法多難而是把條件寫死在龐大的邏輯分支里改一個(gè)數(shù)字要?jiǎng)右淮笃a最后沒人敢動(dòng)。3.1 一個(gè)最小配置結(jié)構(gòu)如果讓我為演示規(guī)則設(shè)計(jì)一個(gè)最小配置結(jié)構(gòu)會(huì)更偏事件驅(qū)動(dòng)和條件校驗(yàn)分離的方式。下面這段 JSON 只是示例結(jié)構(gòu)不代表對(duì)原始暗號(hào)的官方解釋{ challengeId: abd_challenge_001, name: abd_3death_limit, zone: abd, deathLimit: 3, goals: [ { type: quest_complete, targetId: q3, requiredCount: 1 }, { type: dungeon_clear, targetId: dc, requiredCount: 2 } ], conditionMode: AND, progressResetOnDeath: false, progressResetOnFail: false }字段含義不復(fù)雜challengeId唯一標(biāo)識(shí)。zone只在abd場(chǎng)景內(nèi)統(tǒng)計(jì)。deathLimit死亡上限超過即失敗。goals一組完成目標(biāo)。conditionMode目標(biāo)之間是 AND 還是 OR。progressResetOnDeath死亡后是否清空已完成的進(jìn)度。progressResetOnFail失敗后是否允許重新挑戰(zhàn)并重新累計(jì)。其中兩個(gè) reset 字段非常關(guān)鍵。很多線上 bug 都出在這里策劃以為失敗后進(jìn)度重置開發(fā)卻默認(rèn)玩家退出重進(jìn)后會(huì)保留進(jìn)度兩邊各做各的。3.2 配置化不是銀彈需要配套校驗(yàn)但要注意把規(guī)則搬進(jìn)配置表不等于規(guī)則一定正確。配置化的價(jià)值有兩個(gè)前提一是語義已經(jīng)對(duì)齊二是配置有校驗(yàn)和日志。如果語義沒對(duì)齊配置只是讓錯(cuò)誤規(guī)則更容易批量發(fā)布而已。所以我建議至少做三層校驗(yàn)靜態(tài)校驗(yàn)配置格式、字段類型、目標(biāo) ID 是否存在、requiredCount 是否大于 0。運(yùn)行時(shí)校驗(yàn)事件類型是否能被目標(biāo)正確消費(fèi)未知事件是否要告警。可觀測(cè)性校驗(yàn)每次達(dá)成、重置、失敗都有日志便于事后回溯。配置化真正解決的是“不斷變化的需求能不能低成本地安全落地”而不是“需求本身有沒有理解對(duì)”。這兩件事不能混為一談。提醒一下別上來就把配置平臺(tái)做得很大。先用一個(gè) JSON 或一張表支撐本次需求等出現(xiàn)第二個(gè)同類需求時(shí)再抽象公共字段因?yàn)檫^早抽象只會(huì)讓配置變得比硬編碼代碼更難讀。4. 判定邏輯最容易出錯(cuò)的三個(gè)位置配置結(jié)構(gòu)定了流程代碼反而好寫。真正讓開發(fā)頭疼的往往集中在下面三個(gè)位置。每一個(gè)都能讓一個(gè)看似簡(jiǎn)單的挑戰(zhàn)任務(wù)變成線上事故。4.1 死亡限制是“紅線”還是“目標(biāo)”這是最容易踩的坑。如果3death是失敗線那么它不會(huì)帶來任何“目標(biāo)達(dá)成”的正面反饋它只負(fù)責(zé)在玩家死亡事件出現(xiàn)時(shí)判斷是否超過限制從而把挑戰(zhàn)狀態(tài)置為失敗。如果把失敗線和目標(biāo)混在一個(gè)進(jìn)度表里就會(huì)出現(xiàn)很滑稽的結(jié)果玩家還沒完成任務(wù)系統(tǒng)先獎(jiǎng)勵(lì)了一個(gè)“已死亡三次”的進(jìn)度。所以實(shí)現(xiàn)上應(yīng)該把兩類條件分開達(dá)成條件需要累計(jì)并判斷是否滿足。失敗條件只做狀態(tài)攔截不參與正常完成結(jié)算。很多新人不理解為什么3death不該被放進(jìn)goals數(shù)組。因?yàn)槟繕?biāo)列表在語義上是“要做到的事”死亡失敗線在語義上是“不能踩的雷”。前者沒完成是進(jìn)度不足后者觸發(fā)了是即時(shí)失敗兩者的業(yè)務(wù)含義和用戶體驗(yàn)完全不同。4.2 多個(gè)條件同時(shí)滿足時(shí)判定順序和事件時(shí)序第二個(gè)常見問題是多事件并發(fā)。比如玩家在挑戰(zhàn)結(jié)束前最后一瞬間完成了q3同時(shí)副本通關(guān)事件dc也到達(dá)兩個(gè)事件擠在同一幀里。此時(shí)計(jì)數(shù)順序不同可能影響任務(wù)是否完成。這種問題在設(shè)計(jì)時(shí)最容易低估。事件系統(tǒng)如果天然有序那么還好如果是異步亂序就會(huì)出現(xiàn)“任務(wù)完成了但獎(jiǎng)勵(lì)沒發(fā)”“明明通關(guān)了卻沒計(jì)數(shù)”之類的現(xiàn)象。我的建議是把結(jié)算邏輯設(shè)計(jì)得“冪等”。也就是說同一個(gè)事件處理兩次結(jié)果不能是計(jì)數(shù)加兩次。事件里最好帶上唯一事件 ID或者至少用“事件類型 目標(biāo) ID 當(dāng)前次數(shù)”做去重鍵。否則測(cè)試環(huán)境跑不出來一到高并發(fā)或低延遲環(huán)境就重復(fù)發(fā)獎(jiǎng)。4.3 重置策略不一致線上才出詭異 bug第三種常見問題是重置策略。挑戰(zhàn)系統(tǒng)經(jīng)常和天數(shù)、周數(shù)、角色死亡、隊(duì)伍重開等因素耦合。一個(gè)暗號(hào)式需求里沒有說明“什么時(shí)候清零”實(shí)現(xiàn)時(shí)就要特別小心。比如玩家在挑戰(zhàn)中死亡了一次系統(tǒng)判定沒有超過三次允許繼續(xù)。那么已經(jīng)完成的q3一次算不算保留如果策劃認(rèn)為“死亡即重來”那么progressResetOnDeath就是 true如果認(rèn)為“只要沒到三次進(jìn)度就還在”就是 false。這兩套邏輯在單人測(cè)試時(shí)不一定能試出來但一旦組隊(duì)、換人、角色離場(chǎng)就會(huì)出現(xiàn)一個(gè)隊(duì)員死了其他隊(duì)員還在打可任務(wù)狀態(tài)已經(jīng)被重置的情況。線上玩家會(huì)立刻感受到“不公平”。建議在需求確認(rèn)階段把重置策略集中列成一張小表逐項(xiàng)問清楚時(shí)機(jī)是否重置已完成目標(biāo)是否重置死亡次數(shù)玩家死亡待確認(rèn)通常不重置組隊(duì)解散待確認(rèn)待確認(rèn)挑戰(zhàn)失敗待確認(rèn)待確認(rèn)每日刷新待確認(rèn)待確認(rèn)掉線重連待確認(rèn)待確認(rèn)問完這一輪再寫邏輯也不遲。5. 遇到“任務(wù)沒完成/沒發(fā)獎(jiǎng)”的排查順序這類功能線上跑一段時(shí)間后最常見的反饋是玩家說“我明明完成了為什么沒有發(fā)獎(jiǎng)”或者“我死了三次但沒有判定失敗”。每次接到這類反饋別急著去翻業(yè)務(wù)邏輯先按固定順序排查。5.1 從現(xiàn)象到事件日志第一步不是看代碼而是看現(xiàn)象屬于哪一類是根本沒有進(jìn)入挑戰(zhàn)狀態(tài)是計(jì)數(shù)沒增加是目標(biāo)全部滿足了但沒有發(fā)獎(jiǎng)還是發(fā)獎(jiǎng)發(fā)了兩次現(xiàn)象不同排查入口完全不同。連現(xiàn)象都沒分類就開始改代碼往往會(huì)把一個(gè)早期日志問題誤判成判定邏輯問題。第二步是查看事件日志。確認(rèn)q3和dc對(duì)應(yīng)的事件到底有沒有被服務(wù)端收到。有時(shí)候客戶端顯示任務(wù)完成了但服務(wù)端根本沒有相關(guān)事件上報(bào)計(jì)數(shù)從源頭就是零。這種問題再怎么寫判定邏輯都沒有用。5.2 檢查配置與重置日志顯示事件收到了接著看配置實(shí)例。重點(diǎn)檢查三處goals里的requiredCount是不是被配置成了 0 或負(fù)數(shù)。當(dāng)前實(shí)例的progressResetOnDeath是不是被改過。dc的type寫的是dungeon_clear但服務(wù)端發(fā)的是dungeon_join兩邊文本不一致導(dǎo)致計(jì)數(shù)永遠(yuǎn)收不到。第三處尤其隱蔽。我見過不少次因?yàn)槭录愋兔笮懖灰恢聦?dǎo)致配置總是匹配不到目標(biāo)。5.3 邊界驗(yàn)證的三種測(cè)試路徑為了防止這種問題滾到線上我會(huì)在每個(gè)挑戰(zhàn)規(guī)則上線前跑三類用例正常路徑按規(guī)則完成全部目標(biāo)確認(rèn)狀態(tài)變?yōu)槌晒Σl(fā)放獎(jiǎng)勵(lì)。邊界路徑死亡次數(shù)剛好卡在上限、倒數(shù)第二次和第三次連在一起、刷新前最后一秒完成。異常路徑中途掉線重連、組隊(duì)中途解散、同一個(gè)事件重復(fù)上報(bào)兩次、服務(wù)器時(shí)間跳變。這三類用例不需要寫很多。每類里挑最典型的 3 到 5 條能覆蓋絕大多數(shù)回歸風(fēng)險(xiǎn)。實(shí)操經(jīng)驗(yàn)不要只在本地用單機(jī)賬號(hào)測(cè)。至少準(zhǔn)備一個(gè)組隊(duì)環(huán)境因?yàn)橛写罅恐刂妙?bug 只有在多人共享進(jìn)度時(shí)才會(huì)暴露。6. 這類需求背后真正值得長(zhǎng)期堅(jiān)持的事處理abd 3deathq3*1 dc*2這串文字的最后收獲不是把它做出來而是意識(shí)到項(xiàng)目里缺少了一層?xùn)|西把一句話需求變成可執(zhí)行驗(yàn)收規(guī)格的過程不能省。6.1 給代碼補(bǔ)充“需求規(guī)格層”我以前接手過一個(gè)項(xiàng)目規(guī)則散落在注釋里、需求單里和策劃的聊天記錄里。代碼寫得再清楚也沒法還原“當(dāng)時(shí)為什么這樣定”。后來我們做了個(gè)改變每個(gè)挑戰(zhàn) / 任務(wù)配置的字段旁邊必須寫一句業(yè)務(wù)含義并且放到代碼倉庫里隨版本管理。規(guī)則變配置和人話說明一起變。這套做法聽起來不炫但效果立竿見影。至少三個(gè)月后再有人問“3death 到底是什么意思”不需要去翻幾百條聊天記錄直接看配置注釋和驗(yàn)收單就行。落到實(shí)際工作中可以這樣做在 ticket 描述區(qū)補(bǔ)齊語義假設(shè)和確認(rèn)結(jié)論。在配置字段附近寫清單位和邊界。在上線備注里寫明這個(gè)規(guī)則影響了哪些舊行為。在測(cè)試用例名稱里帶上業(yè)務(wù)描述。6.2 測(cè)試就成了可執(zhí)行的驗(yàn)收單為什么建議用測(cè)試用例去表達(dá)需求因?yàn)樗热魏挝臋n都更嚴(yán)格。文檔寫“死亡次數(shù)不能超過三次”測(cè)試用例會(huì)寫成“死兩次正常推進(jìn)死第三次觸發(fā)失敗”。測(cè)試不只驗(yàn)證代碼也驗(yàn)證需求本身是不是自洽。寫測(cè)試的時(shí)候如果發(fā)現(xiàn)無法通過簡(jiǎn)潔的用例表達(dá)這條規(guī)則那大概率是需求本身還有漏洞。這也回應(yīng)了開頭那句話一行暗號(hào)不是需求它只是需求的壓縮包。我們要做的是在解壓時(shí)補(bǔ)齊所有缺失字段、邊界和異常策略。補(bǔ)齊的過程才是交付真正的價(jià)值。所以下次再看到類似abd 3deathq3*1 dc*2這種需求串別急著打開代碼編輯器。先花半天把 token 拆開、把語義列清楚、把邊界問題記下來去找人逐條確認(rèn)然后寫一張可驗(yàn)收的規(guī)則表再考慮配置怎么寫。你省下的那點(diǎn)溝通時(shí)間最后都會(huì)在返工、線上問題和團(tuán)隊(duì)摩擦里還回去。真正靠譜的開發(fā)不是看到暗號(hào)就能猜中的人而是能證明自己不需要靠猜的人。