很多技術(shù)教程把“集成、驗證”講成了兩個獨立的章節(jié)把“面試題”又講成另一套東西。但實際上做項目和準(zhǔn)備面試完全是一件事的兩面項目里怎么把模塊捏合在一起、怎么證明它靠譜面試官問的就是你在這中間的每個決策和踩坑。這篇我直接把第07講“集成、驗證與面試題精講”拆開揉碎結(jié)合我這些年帶項目、做評審、面別人的經(jīng)驗把集成階段的順序、驗證手段的取舍、面試回答的套路一次說清楚。適合正在做畢設(shè)、剛?cè)肼毿枰毩⒇?fù)責(zé)模塊、以及準(zhǔn)備技術(shù)面試的開發(fā)者參考內(nèi)容不繞彎子全是能直接用的方法。1. 集成的核心挑戰(zhàn)與設(shè)計思路1.1 集成不是把代碼拼在一起那么簡單很多人對集成的理解是“大家把代碼往主干一合能跑起來就算完事”。我在實際項目里見過太多次這種想法的翻車現(xiàn)場每個人本地都跑得好好的一合到一起就各種報錯接口對不上、字段名不一致、數(shù)據(jù)格式不對、環(huán)境配置互相覆蓋。花在排這些破事上的時間往往比寫代碼本身還多。真正的集成核心要解決的是“模塊之間的契約問題”。所謂契約不是你說你傳個參數(shù)我收個參數(shù)這么簡單而是包括接口的協(xié)議類型、數(shù)據(jù)字段的類型和含義、異常情況下的返回結(jié)構(gòu)、超時時間的約定、冪等性的保障甚至包括日志格式和追蹤標(biāo)識怎么傳遞。這些東西只要有一項沒約定清楚集成的時候就會爆發(fā)問題。我之前帶某個模擬項目X的時候A同學(xué)負(fù)責(zé)用戶服務(wù)B同學(xué)負(fù)責(zé)訂單服務(wù)兩個人都是自己定義返回結(jié)構(gòu)。A同學(xué)用{code, message, data}B同學(xué)用{status, msg, result}。聯(lián)調(diào)的時候兩邊都認(rèn)為是對方的問題實際上誰都沒錯錯在剛開始集成方案設(shè)計的時候沒有把統(tǒng)一返回結(jié)構(gòu)作為第一條約定寫進(jìn)文檔里。后來我們把所有服務(wù)的接口契約單獨抽出來評審類似的問題基本在聯(lián)調(diào)前就消滅了。1.2 集成方案選型三種常見模式不同規(guī)模的項目集成的節(jié)奏完全不同。我梳理一下常見的三種模式你可以對照自己的項目情況選。第一種單體應(yīng)用內(nèi)部的模塊集成。這種其實最簡單模塊之間直接方法調(diào)用不需要考慮網(wǎng)絡(luò)開銷和序列化問題。但它的陷阱在于模塊之間容易產(chǎn)生隱式依賴比如一個模塊直接改了另一個模塊的全局變量或者共享了一個靜態(tài)類。這種集成方式的重點在于“邊界意識”即使在一個進(jìn)程里也要把模塊之間的交互顯式化通過接口或者抽象類來解耦。第二種微服務(wù)架構(gòu)下的分布式集成。這種模式是目前大多數(shù)互聯(lián)網(wǎng)項目的標(biāo)配也是面試?yán)飭柕米疃嗟?。服?wù)之間通過HTTP或者消息隊列通信需要考慮網(wǎng)絡(luò)延遲、部分失敗、冪等、分布式事務(wù)等一堆問題。我剛帶項目的時候團(tuán)隊里的新人最容易犯的錯誤是“同步調(diào)用一切”所有服務(wù)之間都是同步HTTP調(diào)用結(jié)果一個服務(wù)響應(yīng)慢了整個鏈路全部阻塞。后來我們引入消息隊列做異步解耦把不需要實時返回的操作全部改成異步整個系統(tǒng)的吞吐量上去了鏈路的穩(wěn)定性也好了很多。第三種第三方系統(tǒng)的外部集成。比如對接支付渠道、短信服務(wù)、地圖服務(wù)等。這種集成的關(guān)鍵在于適配層和防依賴腐化。你不能把第三方SDK直接在業(yè)務(wù)代碼里滿天飛一旦對方升級接口或者出了問題你的業(yè)務(wù)代碼就得跟著遭殃。正確做法是包一層自己的適配器把第三方的東西隔離在邊界之外。1.3 模塊之間的約定接口設(shè)計先行很多項目失敗的原因不是因為代碼寫得差而是因為接口設(shè)計得隨意。接口設(shè)計這件事必須放在編碼之前做而且要經(jīng)過評審不是誰寫了就算數(shù)。接口設(shè)計的基礎(chǔ)原則就那么幾條但每條都是血淚教訓(xùn)換來的。第一字段命名風(fēng)格統(tǒng)一要么全部小寫下劃線要么全部駝峰最怕混用。第二類型定義必須嚴(yán)謹(jǐn)比如金額必須用整數(shù)存分不能用浮點數(shù)存元心態(tài)崩沒崩過只有踩了坑的人知道。第三可選字段和必選字段要標(biāo)注清楚不能讓別人猜。第四錯誤碼要有全局編號規(guī)則不能每個模塊自己從1開始編號聯(lián)調(diào)的時候會出現(xiàn)兩個服務(wù)返回同一個code但表達(dá)的意思完全不同的奇葩場景。我建議你在項目啟動初期就建一個接口契約文檔用表格維護(hù)接口路徑、請求方法、入?yún)⒆侄?、類型、是否必填、出參結(jié)構(gòu)、錯誤碼枚舉、超時閾值。這個文檔看起來費時間但它就是集成階段的地圖。沒有地圖的集成就是瞎撞有了地圖聯(lián)調(diào)只是照著走一遍而已。2. 集成實操全流程2.1 環(huán)境準(zhǔn)備與分支策略集成開始之前先把環(huán)境問題解決好否則后面每個環(huán)節(jié)都會堵車。最常見的問題就是環(huán)境不統(tǒng)一有人用本地連測試庫有人用測試環(huán)境連開發(fā)庫還有人直接在本地跑所有的依賴服務(wù)。這種混亂狀態(tài)下出的問題排查起來非常痛苦因為很多時候問題根本不在代碼邏輯上而是環(huán)境配置差異導(dǎo)致的行為不一致。我個人的習(xí)慣是用一個docker-compose把所有依賴的基礎(chǔ)設(shè)施在本地跑起來數(shù)據(jù)庫、緩存、消息隊列統(tǒng)一版本每個人拉下來就能跑通一套完整環(huán)境。然后線上環(huán)境再單獨部署一套保持和本地的依賴版本一致。這樣至少能保證“在我本地是好的”這句話盡量少出現(xiàn)。分支策略沒什么花哨的推薦采用dev → test → release的環(huán)境配套策略。開發(fā)分支dev開啟日常集成的自動化驗證允許代碼頻繁合并測試分支test部署到測試環(huán)境供前后端人員、測試人員使用release分支只接受驗證通過的版本合并。這樣每個分支的角色清晰誰往哪個分支合并都有明確的依據(jù)不會出現(xiàn)順手把開發(fā)中的半成品放到測試環(huán)境去坑隊友的情況。2.2 接口聯(lián)調(diào)的節(jié)奏與方法聯(lián)調(diào)不是一個端點坐下來對接口就完事它是有節(jié)奏的。從我?guī)Ф鄠€項目的經(jīng)驗來看聯(lián)調(diào)應(yīng)該分三輪走。第一輪是“契約聯(lián)調(diào)”也可以叫“靜態(tài)聯(lián)調(diào)”。這一輪不涉及真實邏輯只驗證接口的請求和返回結(jié)構(gòu)符合契約。最簡單的方式是讓后端把接口文檔生成出來前端用Mock數(shù)據(jù)先跑一遍確認(rèn)字段名、嵌套結(jié)構(gòu)、類型都正確。這個階段如果能配合一個接口文檔平臺自動生成Mock效率會高很多。很多前端抱怨后端改字段根本原因是這輪沒做好等真實接口出來了才發(fā)現(xiàn)字段對不上那當(dāng)然要返工。第二輪是“功能聯(lián)調(diào)”也就是跑真實場景。前端調(diào)真實接口后端也開真實邏輯把完整的業(yè)務(wù)鏈路走通。這個階段的核心是“主鏈路優(yōu)先”先把核心流程跑通異常分支和邊界條件放在后面慢慢處理。我見過太多團(tuán)隊聯(lián)調(diào)時一個非核心的報錯卡了兩天核心流程反而沒測最后上線日期到了核心鏈路還有一堆問題。第三輪是“異常聯(lián)調(diào)”專門驗證異常場景。超時、限流、服務(wù)不可用、重復(fù)請求這些都要在這一輪覆蓋到。有人會問這些不是測試該做的嗎我必須強調(diào)一下測試確實會做但作為開發(fā)者在聯(lián)調(diào)階段自己先過一輪異常場景不僅能發(fā)現(xiàn)自己代碼里的防御邏輯缺漏也能順手驗證降級方案是否真的生效而不是等到測試環(huán)境才靠運氣發(fā)現(xiàn)。2.3 數(shù)據(jù)層集成的坑數(shù)據(jù)層集成是整個集成過程中最容易被低估的部分實際上它排坑耗時占比和難度遠(yuǎn)高于接口聯(lián)調(diào)。第一個坑數(shù)據(jù)庫表結(jié)構(gòu)變更沒有同步機制。兩個服務(wù)分別維護(hù)自己負(fù)責(zé)的表A服務(wù)改了某張表的名字B服務(wù)還在用舊名查詢一上線就一片雪上加霜。解決辦法是在集成方案里明確數(shù)據(jù)字典的變更通知流程任何表結(jié)構(gòu)變更必須同步到所有依賴方且要有兼容過渡期。第二個坑分布式事務(wù)。我見過很多剛接觸微服務(wù)的人一聽到分布式事務(wù)就頭大然后要么選擇“不做分布式事務(wù)”要么引入一堆分布式事務(wù)框架把系統(tǒng)搞得很重。實際上大多數(shù)業(yè)務(wù)場景根本不需要強一致阿里巴巴的經(jīng)典分類思路就是把“剛性事務(wù)”降級為“柔性事務(wù)”使用本地消息表或者事務(wù)消息去保證最終一致性。比如一個下單操作同時要扣庫存和生成訂單正確做法是先提交一個本地消息由異步任務(wù)去扣庫存扣成功的才把訂單狀態(tài)置為已支付。這個思路比引入強一致框架簡潔得多也和大部分項目的實際需求匹配。第三個坑數(shù)據(jù)遷移和數(shù)據(jù)補償。歷史數(shù)據(jù)遷移到新表結(jié)構(gòu)之后業(yè)務(wù)代碼是否還兼容數(shù)據(jù)清洗跑完了要不要做比對補償任務(wù)掛在哪個調(diào)度平臺上失敗了重試幾次這些事不弄清楚就盲上集成生產(chǎn)環(huán)境的數(shù)據(jù)就會給你顏色看。3. 驗證的價值與設(shè)計3.1 從單元測試到端到端測試的驗證體系驗證這件事不能只靠最后手工點一遍那不是驗證那是碰運氣。我這里的驗證體系從低到高分為四層單元測試、接口測試、集成測試、端到端測試。單元測試驗證一個函數(shù)、一個方法在給定輸入下產(chǎn)出正確輸出重點是覆蓋復(fù)雜邏輯分支而不是為了湊覆蓋率把每個getter、setter都測一遍。接口測試驗證一個服務(wù)對外暴露的接口行為符合契約請求參數(shù)的有效性、返回碼的語義、異常分支的狀態(tài)流轉(zhuǎn)都在這里驗證。集成測試驗證多個服務(wù)協(xié)同是否正常通常是在測試環(huán)境拉起多服務(wù)走真實的數(shù)據(jù)流和調(diào)用鏈。端到端測試站在用戶視角模擬完整業(yè)務(wù)流程比如一個用戶從注冊到下單到支付到查詢訂單的全鏈路。這四層不是都要寫很多代碼而是按項目情況取舍。如果你是一個單體小項目單元測試加端到端測試就覆蓋得差不多了如果你是一個中大型分布式項目接口測試和集成測試的價值會更明顯。關(guān)鍵不是層數(shù)多而是“每一層驗證的對象明確、反饋迅速”出了問題能快速定位是哪一層的鍋。3.2 自動化測試的取舍與經(jīng)濟(jì)性我必須潑一盆冷水自動化測試不是越多越好。很多團(tuán)隊把覆蓋率當(dāng)成KPI強行把覆蓋率從40%拉到80%結(jié)果代碼里全是低價值的斷言真正核心的鏈路反而沒人測。這種自動化是虛假繁榮。我自己的取舍標(biāo)準(zhǔn)有三個。第一核心邏輯必須測。涉及金額計算、狀態(tài)流轉(zhuǎn)、權(quán)限判斷、數(shù)據(jù)唯一性約束的邏輯不測就是在賭。第二復(fù)雜分支必須測。一個方法里有五個if嵌套你不給每個分支寫測試后面的維護(hù)者改一個條件就要提心吊膽。第三重構(gòu)頻繁的模塊必須測。這是為未來的自己省時間重構(gòu)完跑一遍測試比手動點功能點效率高得多。有一個層面很少被提到就是“回滾保護(hù)”。自動化測試在工作實踐中最大的價值不是你寫完代碼后跑一遍通過了而是你或者別人某一天改代碼的時候測試能把改壞的功能揪出來。這個“回歸保護(hù)”的價值往往比驗證當(dāng)次功能是否正確更大。3.3 性能、異常與安全性驗證集成階段最容易忽略的就是性能驗證。很多系統(tǒng)在少量數(shù)據(jù)、低并發(fā)測試下看起來一切正常一上線就扛不住流量接口一個接一個超時。性能驗證不一定要用復(fù)雜的壓測工具最基本的一個壓測工具用起來模擬比預(yù)估峰值高的并發(fā)數(shù)跑一跑關(guān)鍵接口觀察響應(yīng)時間的變化趨勢和錯誤率能暴露出很多設(shè)計上的瓶頸比如數(shù)據(jù)庫連接池不夠、某個接口存在嚴(yán)重的N1查詢、緩存沒生效等。異常驗證也要專門設(shè)計。熔斷、降級、重試、超時這四件套不能只在代碼評審里講“我加了重試”得上線驗證重試多少次、退避策略是什么、會不會打爆下游。最經(jīng)典的例子就是重試風(fēng)暴A服務(wù)超時后立刻重試3次B服務(wù)也超時也重試3次C服務(wù)直接被打掛。這種問題只有真正壓過一次或者演練一次才心里有數(shù)。安全驗證這塊接口層面的鑒權(quán)、越權(quán)、SQL注入、敏感數(shù)據(jù)脫敏測試用例里必須覆蓋。我見過一個項目在集成測試階段發(fā)現(xiàn)訂單詳情的接口只要把訂單ID從1改成2就能查到別人的訂單原因就是僅校驗登錄態(tài)、未校驗數(shù)據(jù)歸屬。這類問題在功能測試?yán)锿ǔy不出來必須專門設(shè)計越權(quán)用例。4. 面試題精講從知識到實戰(zhàn)4.1 面試官真正想考察的三種能力面試題尤其是集成和驗證相關(guān)的問題表面上考的是知識點實際上考察的是三種底層能力。第一種整體設(shè)計能力。面試官給你一個場景問你“怎么做集成方案”不是要你背誦微服務(wù)理論而是你能不能cover住全局哪些是核心流程、哪些可以異步化、接口怎么劃分、異常怎么兜底。這個能力來自于你真正帶過模塊、處理過集成沖突的經(jīng)驗而不是看了幾篇技術(shù)博客就能吹出來的。第二種權(quán)衡與決策能力。面試?yán)锝?jīng)常問“你項目里為什么用消息隊列不用直接調(diào)用”“為什么用最終一致性而不用強一致”本質(zhì)上就是看你有沒有做過思考、有沒有在幾種方案之間比較過優(yōu)缺。回答時最忌諱只講好處不講代價任何技術(shù)選型都有代價能講清楚代價才說明你真的想過。第三種問題排查能力。面試官問“你線上遇到的最難排查的問題是什么”不是真想聽一個高分故事而是看你的排查思路是否系統(tǒng)有沒有先懷疑環(huán)境、再懷疑配置、再看日志、再加監(jiān)控最后定位到代碼而不是瞎猜。4.2 高頻核心問題拆解我整理了幾個集成與驗證方向的高頻面試題每個都附上回答思路供你參考。問題一服務(wù)A調(diào)用服務(wù)B超時你會怎么排查很多人的第一反應(yīng)是“看B的日志”這個沒錯但不夠系統(tǒng)。我的回答會分層次先確認(rèn)超時是發(fā)生在連接階段還是讀取階段連接階段大概率是網(wǎng)絡(luò)或者服務(wù)不可用讀取階段大概率是B處理慢或者線程池被打滿再看A的重試配置會不會放大問題A的超時時間設(shè)置是否合理然后看B的監(jiān)控面板接口耗時分布、線程池活躍度、數(shù)據(jù)庫慢查詢最后根據(jù)現(xiàn)象判斷是代碼性能問題、資源不足還是依賴下游慢導(dǎo)致的雪崩。回答把排查路徑梳理完成比直接給出一個“正確答案”更能打動面試官。問題二你們項目的集成測試是怎么做的這個問題要結(jié)合自己的項目具體說不能空談理論。你可以從環(huán)境搭建、數(shù)據(jù)準(zhǔn)備、自動化手段、人工補充這四個角度展開。重點突出你曾經(jīng)在集成階段發(fā)現(xiàn)過一個有代表性的問題然后是怎么定位、怎么解決的。這類帶真實細(xì)節(jié)的回答比背誦測試金字塔定義有用一百倍。問題三服務(wù)注冊發(fā)現(xiàn)、配置中心在集成中扮演什么角色這個問題考的是你對“基礎(chǔ)設(shè)施”的理解。我的思路是這些組件解決的是“動態(tài)變化”的問題——服務(wù)實例上下線、配置變更、路由流量調(diào)整。集成過程中服務(wù)地址會經(jīng)常變不可能靠手工改配置維護(hù)配置中心讓不同環(huán)境的配置隔離清晰避免把測試環(huán)境的配置帶到線上注冊發(fā)現(xiàn)讓系統(tǒng)對實例變化敏感故障時能摘流量?；卮饡r能結(jié)合具體場景講一個故障案例會更有說服力。4.3 場景設(shè)計題的回答框架面試中的場景設(shè)計題比如“讓你設(shè)計一個訂單超時關(guān)閉系統(tǒng)”本質(zhì)上就是讓你現(xiàn)場做集成方案。我摸索出一個通用的四步回答框架屢試不爽。第一步確認(rèn)約束問清楚關(guān)鍵場景。比如單量多大、超時時間多久、是否需要實時性、失敗后如何處理。這一步很重要很多人上來就畫架構(gòu)圖結(jié)果跟面試官期望的方向完全不一樣。第二步識別核心鏈路畫主線。從用戶下單開始到超時檢測到狀態(tài)變更到后續(xù)補償把主干看清楚。第三步拆解選型逐個說明“為什么”。延遲消息隊列、定時任務(wù)輪詢、時間輪各有什么優(yōu)劣為什么在你的場景里選這個。每說一個選型主動說出它的代價。第四步談異常降級展示邊界思考。消息積壓怎么辦、服務(wù)重啟任務(wù)丟失怎么辦、重復(fù)關(guān)閉訂單怎么冪等。能主動把這些講出來就是加分項。這個框架的精髓在于“把問題拆小”。一個很宏大的設(shè)計題拆成約束確認(rèn)、主鏈路、選型、異常四個部分之后每個部分的復(fù)雜度都會降一個級別回答起來從容得多。4.4 手寫代碼題與HR面的關(guān)鍵提醒手寫代碼題主要集中在接口實現(xiàn)、線程安全、數(shù)據(jù)一致性這類細(xì)節(jié)上。我見過不少面試者架構(gòu)講得頭頭是道一寫到單例模式或者多線程就磕磕絆絆。核心原因在于“讀代碼”和“寫代碼”是兩種不同的能力平時自己上手敲得少。建議你在準(zhǔn)備面試前把數(shù)據(jù)結(jié)構(gòu)、并發(fā)編程、緩存一致性這些基礎(chǔ)代碼題手寫練一遍不是看一眼就過是真正在編輯器里敲出來然后運行驗證。到了HR面很多人以為要收起技術(shù)感其實也不對。HR面更關(guān)注的是你的溝通表達(dá)、做事方式、價值觀。比如“你最近遇到的一個困難是什么”你沒有真實經(jīng)歷過的話編出來的故事一聽就假面試官稍微追問細(xì)枝末節(jié)就露餡。誠實講一件小事說清楚背景、思路、行動和結(jié)果比編造一個跌宕起伏的劇本可靠得多。還有一個要點是HR面不要只講技術(shù)還要體現(xiàn)你如何推動協(xié)作、如何向上同步風(fēng)險、如何在團(tuán)隊里處理分歧這些軟素質(zhì)在后面的團(tuán)隊協(xié)作中往往比技術(shù)本身更關(guān)鍵。5. 常見問題與排查技巧實錄5.1 集成過程中的典型問題速查表這一節(jié)我把這些年集成階段遇到過的、具有代表性的問題按“現(xiàn)象—原因—解法”的維度整理成速查表你可以直接拿去做排查手冊。現(xiàn)象典型原因解決思路接口聯(lián)調(diào)時字段總是對不上接口契約文檔與實際代碼不同步用接口平臺維護(hù)契約代碼變更觸發(fā)文檔自動更新強制評審測試環(huán)境一會好一會壞多人共用環(huán)境導(dǎo)致互相影響引入環(huán)境隔離或租戶隔離重要流程在獨立環(huán)境驗證服務(wù)啟動報端口占用本地起多個服務(wù)實例沖突用docker-compose統(tǒng)一規(guī)劃端口映射避免隨機端口調(diào)用下游偶爾超時線程池配置過小或下游GC停頓壓測確認(rèn)線程池水位優(yōu)化GC參數(shù)并配置合理的超時重試數(shù)據(jù)庫死鎖偶現(xiàn)多個事務(wù)加鎖順序不一致統(tǒng)一加鎖順序優(yōu)化事務(wù)范圍必要時引入分布式鎖數(shù)據(jù)重復(fù)插入接口未實現(xiàn)冪等增加冪等表或唯一索引同一請求用唯一業(yè)務(wù)鍵去重接口返回成功但業(yè)務(wù)未執(zhí)行異步消息丟失或消費失敗增加消息本地表、消費記錄表和補償任務(wù)日志串聯(lián)不上缺少統(tǒng)一的traceId傳遞在網(wǎng)關(guān)生成traceId通過攔截器透傳到所有下游調(diào)用5.2 排查問題的三段式方法排查問題最忌“猜測驅(qū)動”也就是“我猜是這里有問題改一下試試不行再改”。這種碰運氣式的排查碰到簡單問題還行碰到復(fù)雜問題會一直原地打轉(zhuǎn)最后改出一堆新bug。我自己的排查動作基本固定為三段。第一段收集證據(jù)。先把日志、監(jiān)控、鏈路追蹤、報錯堆棧全部拉出來確認(rèn)問題的現(xiàn)象到底是什么。很多時候開發(fā)者在口頭描述“它掛了”時掛的模式千差萬別是超時、是報錯、是數(shù)據(jù)錯、還是性能慢必須用數(shù)據(jù)把現(xiàn)象釘死。第二段縮小范圍。用二分法把可能出問題的環(huán)節(jié)縮小到某一個確定的層級。比如前端報一個接口500先確認(rèn)是網(wǎng)關(guān)攔截了還是服務(wù)拋異常再確認(rèn)是Controller層的問題還是Service層的問題再確認(rèn)是代碼邏輯還是數(shù)據(jù)庫層面。每縮小一步都要有一個證據(jù)支撐。第三段驗證根因。找到嫌疑點后不要急著改代碼。先在測試環(huán)境復(fù)現(xiàn)一次確認(rèn)根因成立再動手修。修完之后再把修復(fù)前后的現(xiàn)象對比一次防止改出回歸問題。這套流程看起來很樸素但效率極高能保證你所有的改動都是基于事實而不是想象。5.3 我在實際集成中養(yǎng)成的幾個習(xí)慣最后一個部分分享幾個我一直在用的習(xí)慣它們不是某個具體的工具或技巧而是做事的方法。第一個習(xí)慣永遠(yuǎn)在開始前留出15%的緩沖時間。集成和驗證階段的不可預(yù)測性遠(yuǎn)超編碼階段你以為一天能搞定的聯(lián)調(diào)實操中因為環(huán)境問題耗掉三天也不罕見。所以做項目排期時集成階段的時間一定要留足緩沖不然后面要么趕工刪功能要么熬夜填坑。第二個習(xí)慣集成階段每天跑一遍全量自動化測試。不要等到提交前才跑那時候發(fā)現(xiàn)問題往往已經(jīng)晚了。每天跑一次能盡早發(fā)現(xiàn)環(huán)境變動或者新改動對已有功能的破壞。第三個習(xí)慣任何一次線上問題的修復(fù)都必須輸出復(fù)盤記錄。不用寫長篇大論就寫清楚現(xiàn)象、根因、修復(fù)方案、預(yù)防措施。這樣每一篇都是一份寶貴的排查資料下次遇到類似問題直接查自己的復(fù)盤記錄基本上能省掉一半的排查時間。6. 從項目到面試的認(rèn)知升級回到第07講的主題“集成、驗證與面試題精講”你會發(fā)現(xiàn)集成考驗的是你對模塊邊界的理解能力驗證考驗的是你對確定性的執(zhí)著程度面試題考驗的是你有沒有把前兩者內(nèi)化成自己的經(jīng)驗。我在實際帶項目時最欣慰的時刻不是功能上線而是團(tuán)隊里有人開始主動問我“我們這兩個模塊的接口契約是不是該先評審一下”或者“這個異常的測試用例要不要補上”。當(dāng)一個人開始主動關(guān)注集成邊界、主動驗證異常分支時他就已經(jīng)不是在“完成任務(wù)”而是在“把一件事做成”。對于正在準(zhǔn)備面試的人我的建議是不要背題要把每一個高頻問題拿到自己的項目里去對照一遍問自己我的項目里這個場景是怎么做的如果重新來一次我會做哪些不同選擇這樣準(zhǔn)備出來的回答每一句都來自真實經(jīng)驗面試官一聽就感覺得到。最后再分享一個小技巧面試?yán)锊还苡龅绞裁磫栴}先停頓三秒再回答。這三秒不是用來緊張的是用來整理結(jié)構(gòu)的先說結(jié)論、再講理由、最后補充例外情況。這個習(xí)慣會讓你所有的回答都顯得有條理、有深度。