深度故障復(fù)盤是今年項目質(zhì)量改進(jìn)的一個重點(diǎn)舉措媳拴。對一個故障的深度故障復(fù)盤主要基于以下幾個方面：

1、故障的現(xiàn)象和原因

2泳梆、影響范圍

3蛉腌、研發(fā)泄露原因

4、測試泄露原因

5缴罗、故障解決說明

基于上述的分析，分析出故障的屬性分類（基本功能祭埂、性能面氓、易用性），故障引入來源（代碼重構(gòu)蛆橡、解決故障舌界、新增需求、歷史遺留）泰演，故障引入環(huán)節(jié)（需求澄清呻拌、需求研討、開發(fā)實現(xiàn)）睦焕，故障控制環(huán)節(jié)（測試方案設(shè)計藐握、測試用例開發(fā)、代碼走查垃喊、故事驗收猾普、CI自動化防護(hù)、系統(tǒng)測試）以及是否能自動化本谜，最終輸出滿足SMART原則的改進(jìn)措施初家。

通過故障引入環(huán)節(jié)的分析，可以挖掘出團(tuán)隊在需求管理環(huán)節(jié)出現(xiàn)的一些問題乌助，比如：場景分析不全溜在、性能效率分析不足、波及影響分析不足他托、兼容性分析不足等掖肋。這就是一個對團(tuán)隊需求環(huán)節(jié)的一個反饋。通過故障控制環(huán)節(jié)的分析上祈，可以挖掘出團(tuán)隊在測試用例開發(fā)培遵、代碼走查浙芙、故事驗收等質(zhì)量保證體系環(huán)節(jié)中的一些問題。從本月做的13個深度故障復(fù)盤的結(jié)果來看籽腕，就明顯的反映出團(tuán)隊代碼走查活動一些明顯的問題嗡呼。

舉例說明一下：

1、QA參與了團(tuán)隊的代碼走查皇耗，但參與過程中很多問題并未及時感知到南窗。

比如：代碼中新增加了一個常量的定義。這些常量往往意味著一些邊界郎楼，需要在驗證過程中增加一些邊界的測試万伤。而如何做邊界測試，對于團(tuán)隊也是一個權(quán)衡呜袁。我們可以在UT層去做邊界測試的自動化驗證敌买，也可以在FT層或者ST層去做自動化或手工的測試驗證。采取哪一種方式阶界，在于團(tuán)隊對于測試性價比的考慮虹钮。比如：對于一個配置項的合法性校驗，可能在UT層做膘融，相較于其他層做就能達(dá)到事半功倍的效果芙粱。所以，團(tuán)隊的測試是要有分層的自動化體系氧映，UT或者FT春畔、ST根據(jù)投入產(chǎn)出比相互補(bǔ)位，來確定團(tuán)隊的分層測試策略岛都。通過這種方式制定的團(tuán)隊分層測試策略才具備更大的落地的可能性律姨。

比如：QA需要有敏銳的感知能力，嗅到代碼的改動對一些既有的功能場景的影響疗绣。之前團(tuán)隊在新增需求開發(fā)的用例中线召，已經(jīng)做了一個改進(jìn)，要求開發(fā)新增波及功能點(diǎn)的測試用例多矮。但當(dāng)一個系統(tǒng)比較大的時候缓淹，一個功能往往很大，如果不能精確的說明到某一個場景點(diǎn)塔逃，只是對一個功能點(diǎn)做一個基本功能的回歸測試讯壶，極有可能無法覆蓋到代碼真正波及影響到的那個點(diǎn)；而如果要對整個功能做非常全的覆蓋湾盗，除了時間成本的權(quán)衡伏蚊，還有可能因為已有用例不全而導(dǎo)致波及測試的遺漏。通過故障復(fù)盤格粪，給予團(tuán)隊QA一個反饋躏吊，觸發(fā)大家去思考如何通過參與代碼走查這項活動氛改，更有效的去對代碼的波及功能做準(zhǔn)確的覆蓋驗證，提升代碼的質(zhì)量比伏，埋下種子胜卤，靜待花開。

2赁项、團(tuán)隊做了代碼走查葛躏，但很多問題沒有及時走查出來。

比如：代碼重構(gòu)前悠菜，代碼中有一個空指針的保護(hù)舰攒，修改后的代碼去掉了這個空指針的保護(hù)。團(tuán)隊走查時并未發(fā)現(xiàn)悔醋，導(dǎo)致泄露了一個空指針故障給外部摩窃，給產(chǎn)品各個環(huán)節(jié)都帶來了不少工作量，這個案例反饋出兩個問題：

（1）篙顺、團(tuán)隊在做代碼走查的時候偶芍，重點(diǎn)的關(guān)注點(diǎn)是在修改后的代碼，容易忽略修改前的代碼德玫，這個信號提醒團(tuán)隊，走查代碼時椎麦，需要兩邊同時做關(guān)注宰僧。代碼走查，很多團(tuán)隊都實踐過观挎，有的團(tuán)隊從中受益良多琴儿，有的團(tuán)隊卻認(rèn)為似乎也沒有什么效果。就是因為實踐過程中細(xì)節(jié)和手法上的差異嘁捷，是實踐活動是否有效的關(guān)鍵造成。因此，我們在做的過程中雄嚣，如果能夠通過故障復(fù)盤得到一些反饋晒屎，就能不斷去思考和持續(xù)改進(jìn)。

（2）缓升、團(tuán)隊在做代碼重構(gòu)的時候鼓鲁，往往并不是嚴(yán)格意義上的重構(gòu)，因為重構(gòu)前后改變了代碼的邏輯港谊，從而導(dǎo)致一系列的問題骇吭，這也是大家不愿意做重構(gòu)的原因。我們常常說歧寺，在重構(gòu)前燥狰，必須要先對代碼編寫單元測試棘脐，在有測試保證的情況下，再去做重構(gòu)龙致。奈何代碼的復(fù)雜度已經(jīng)很高蛀缝，直接去編寫單元測試是一件非常困難的事情。但重構(gòu)又有風(fēng)險會引入新的問題净当，所以我們盡可能去避免做重構(gòu)内斯，在原來已經(jīng)非常復(fù)雜的代碼的基礎(chǔ)上繼續(xù)修修補(bǔ)補(bǔ)，最終在我們的工程里面產(chǎn)生了越來越多的遺留爛代碼像啼。想要打破這樣一個惡性循環(huán)俘闯，需要我們的開發(fā)人員，具備clean code的意識忽冻，提升對代碼好壞的品鑒能力真朗，并逐步掌握一些重構(gòu)的技能和技巧（包括工具，好的工具會讓大家的工作效率得到極大的提升）僧诚，并掌握更多的編寫單元測試的技巧去隔離和解依賴遮婶，技能上去了，才能減少犯錯的可能性湖笨，大家看到了好處旗扑，得到了正面反饋，才能更有信心更進(jìn)一步的去做慈省。故障復(fù)盤的活動臀防，就像一個榔頭棒，敲打敲打才能深化大家的認(rèn)識边败，才有可能讓大家將這些代碼實踐活動進(jìn)行落地袱衷。否則，只是制定一系列的編碼規(guī)范笑窜，而沒有讓項目成員主動有意識去進(jìn)行實踐致燥，是無法真正做到實踐落地的。

綜上所述排截，我們在制定一系列的改進(jìn)措施的時候嫌蚤，往往只見樹木不見森林，產(chǎn)品級的敏捷實踐活動匾寝，涉及到從產(chǎn)品-項目-團(tuán)隊的各項管理和技術(shù)實踐活動搬葬，究竟哪一些實踐活動解決項目的痛點(diǎn)是有效的，往往需要系統(tǒng)的來對項目的痛點(diǎn)進(jìn)行分析艳悔，找到翹起地球的那個杠桿解急凰。深度故障復(fù)盤就像一個支點(diǎn)，如果這個支點(diǎn)利用得好，我們就能夠從這個支點(diǎn)出發(fā)抡锈，深挖根因疾忍，并以此為出發(fā)點(diǎn)去制定有效的改進(jìn)措施。同時床三，每個月的故障復(fù)盤情況一罩，又是對前一個月的各項改進(jìn)措施是否有效的一個極有價值的反饋，基于這樣一個反饋環(huán)去做小步撇簿、持續(xù)改進(jìn)聂渊，我們才能切實的解決產(chǎn)品的質(zhì)量問題。