重構訓練計畫:如何建構能夠教導技術債緩解的遺留程式碼工作

未找到任何項目。
部落格縮圖

團隊接手了一個計費模組,但沒人完全理解它。這個模組沒有任何測試來保護其現有行為。團隊提議用一個迭代周期來「清理」它,計劃是用新的結構重寫核心程式碼。但沒人能保證新版本仍能正確地向客戶收費。

這是一個示例性場景,並非已記錄的事件。它描述了重構培訓專案需要彌合的差距:工程師們雖然能夠看出程式碼混亂,但卻無法制定切實可行的改進方案,也無法證明改進後的程式碼行為沒有改變。

本指南面向工程賦能負責人和工程經理。內容涵蓋如何描述表現問題、診斷差距、設計準備和練習、案例分析以及評估技能是否能遷移到實際工作中。它側重於培訓設計。您專案中的程式碼、測試和規則應由您所在技術的高級工程師進行驗證。

什麼是重構培訓計畫?

重構培訓專案是對遺留程式碼進行結構化的工作,其目的是為了提升能力並改進程式碼。學員會規劃一個規模較小、界限清晰的變更,透過測試來保護現有行為,逐步改進設計,並提供證據證明變更並未破壞任何現有功能。程式碼品質會得到提升,更重要的是,工程師可以藉此機會練習在實際處理技術債時所需的判斷能力。

要聞速覽

問題簡答
任務是什麼?制定並驗證有界的遺留程式碼改進方案。
你得了多少分?風險分析,以及現有行為得以保留的證據。
大幅度重寫是好的訓練項目嗎?通常不會。它會掩蓋正在練習的技能,並使保留下來的行為難以展現。
一個關於重構模式的測試就夠了嗎?不。它確認了前提條件,但不能證明工程師是否能夠規劃和驗證變更。
誰來審核內容?一位工程經理和一位了解程式碼庫的高級工程師。
哪些問題是訓練解決不了的?缺乏測試工具、釋放壓力、所有權不明確,且沒有時間進行維護工作。
你怎麼知道它奏效了?一個全新的、從未見過的遺留代碼案例,根據既定標準進行評分,並跟進實際工作情況。

1. 描述效能問題

首先,任務是:規劃並驗證一個有界的遺留程式碼改進方案。 「有界」是關鍵。學習者選擇一個足夠小的改動方案,以便能夠完成,並且能夠明確哪些改動屬於改進範圍,哪些屬於範圍之外。

明確術語至關重要。 Martin Fowler 將重構描述為一種可控的技術,用於改進現有程式碼庫的設計,它由一系列小的、不改變現有行為的轉換組成。 「不改變現有行為」這個概念將重構與重寫區分開來,也是培訓必須重點強調的內容。技術債這個比喻由 Ward Cunningham 提出,Fowler 的論述也提醒我們,債務可以有意識地、謹慎地承擔,因此並非每個混亂的模組都是需要修復的錯誤。

Michael Feathers 的遺留程式碼著作在實務上也秉持著同樣的理念。該書的出版商介紹稱,它教會開發人員編寫測試,以確保他們不會無意中更改應用程序,並在不完全重寫的情況下控制現有軟體。

用一句話寫出性能說明,並讓工程經理檢查一下:“給定一個遺留模組和一個已定義的目標,工程師提出一個有界變更,添加測試來確定當前行為,分小步進行變更,並證明行為得以保留。”

2. 診斷學習與情境差距

在著手建立任何內容之前,請將所需任務與你目前活動中練習和評估的內容進行比較。通常,有三個問題可以區分訓練差距和其他問題:

  1. 目前的做法是否使用了實際任務? 如果訓練內容只是在投影片中講解重構模式,但沒有人真正修改過未經測試的程式碼,那就沒有人實踐過保護程式碼的行為。如果考核方式是針對程式碼異味的單一選擇題,那麼它衡量的只是記憶力。
  2. 認知需求是什麼? 在布魯姆修訂後的認知目標分類法中,判斷一項變更是否安全屬於分析和評價層級,而設計計畫和測試則屬於創造層級。我們的指南中涵蓋瞭如何將活動與這些層級相匹配。 將學習活動與布魯姆分類法相匹配.
  3. 除了技能之外,還有其他因素阻礙了你嗎? 檢查人員配備、工具和流程。如果建置耗時一小時,就不會有人經常進行測試。如果維護工作從未安排,工程師只會偷偷進行重構。將非訓練原因報告給能夠解決問題的人員。

3. 設計有目的的準備與練習

一旦你了解訓練可以彌補哪些差距,就給每個階段一個明確的任務。

準備工作。透過簡短的診斷來檢查前提條件:了解您的測試框架如何運作、什麼是特性分析測試,以及您的團隊如何進行審查和合併。自主學習適合此階段。回顧檢查僅用於確認前提條件。

練習。使用結構清晰、系統化的重構項目。先從一個小型、安全的範例開始,然後逐步過渡到你程式碼庫中真實但範圍有限的部分。 Gilded Rose kata 是一個眾所周知的入門練習。它的 README 檔案由 Emily Bache 維護,建議在修改程式碼之前編寫測試,並將練習內容定義為循序漸進、頻繁運行測試並逐步改進設計的練習。每個專案的合理順序是:定義目標和邊界,編寫測試來捕獲程式碼的當前功能,每次只修改一個位置,每完成一步後執行測試,並記錄您的心得體會。

回饋.回饋應與決策相關,而非與總分相關。 「你提取了折扣邏輯,但你的測試只涵蓋了正常流程,所以你不可能注意到舍入方式的變化」比「5分滿分,得3分」更有用。

即時指導還是非同步複習?即時指導在選擇模糊不清時最有價值,例如是否應該停止並補上缺失的測試,還是繼續學習。當學習者將自己的計畫和測驗與專家標註的版本進行比較時,非同步複習就足夠了。許多團隊會同時採用這兩種方法:先進行自主學習,然後再針對疑難案例進行輔導。

4. 透過一個實際例子進行分析

舉例說明。工程經理在使用前應驗證案例和答案標準。

案例:一個遺留函數負責計算訂單總額,包括折扣、稅金和運費規則。該函數沒有經過任何測試。團隊提議重構整個計費模組,使其更加「簡潔」。

任務:學習者解釋他們將要做什麼,列出他們將收集的證據,並說明他們還需要哪些資訊或支援。

這是第一次嘗試。「我會把模組拆分成三個服務,然後把邏輯遷移過去,再在測試環境中檢查資料。」這位學員選擇了較大的改動,並且選擇在後期進行手動檢查。這樣就無法判斷新舊版本在處理極端情況時是否一致。

反饋和重試。審閱者會詢問,對於空購物車、導致總金額為負數的折扣以及四捨五入的情況,目前該函數是如何處理的。重試要求學習者將範圍縮小到一種行為,並說明如何證明該行為沒有改變。

更進一步的嘗試。「我建議暫時保持模組結構不變。我會先針對一組輸入(包括一些特殊情況)測試訂單總額函數當前的返回值。然後,我會將折扣計算提取到一個單獨的函數中,完成這一步驟後再運行測試,然後就此結束。我會注意到運費規則存在一些我不理解的行為,在修改之前需要諮詢同事。」

解釋每份回覆的合理性或不足之處。評判每份回覆應依據既定標準,而非審閱者的個人偏好。第一份回覆或許指明了一個合理的長期方向,但作為計畫而言並不完善,因為它缺乏行為持續性的證據。而更完善的回覆則規模較小、易於核查,並且坦誠地承認了不確定性。

5. 評估能力並制定轉移計劃

能力證明是學習者在處理一個之前從未接觸過的全新遺留程式碼案例時的表現。對風險分析和行為保持情況的證據進行評分。一個簡單的評分標準是每個標準採用 0 到 2 分的等級:

標準可觀察的證據
任務執行規劃並驗證有界遺留程式碼改進,並記錄該操作及其背後的證據。
推理解釋了限制條件、替代方案和不確定性,並檢查了風險以及行為得以保留的證據。
邊界使用經批准的程序,並在資訊或權限不足時尋求協助。

評分標準:0 分錶示缺失或缺乏支持,1 分錶示部分缺失但有相關遺漏,2 分錶示完整且符合既定標準。請單獨定義關鍵錯誤,例如在沒有測試能夠發現的情況下更改行為,以避免總分掩蓋此類錯誤。本評分標準僅為建議,並非已驗證的準備就緒標準:請與工程經理共同調整並進行試點。我們的《設計包含有效回饋的互動式練習指南》展示如何撰寫與決策相關的回饋。

精心規劃工作交接。練習結束後,給每位工程師一個實際的小項目,讓他們與評審員一起解決,或對最近一次導致問題出現的變更進行簡短的回顧。在充分接觸實際工作後,而不是在研討會結束後立即檢查工作交接。

互動式教學有助於

互動式格式有助於確保每個人在小組討論前都能做出承諾。在即時會議中,主持人可以展示一段簡短的舊程式碼片段,要求每位工程師提交他們會做的第一個改動以及如何證明其安全性,然後在討論開始前公佈結果。同樣的提示也可以用於自主學習,以便進行準備。 AhaSlides 支援互動式學習,並可在即時學習和自主學習之間靈活切換。它是一個演示和學習工具,而不是用於運行或分析程式碼的地方,因此請在您自己的環境中進行重構。請將您計劃使用的任何特定創作、回饋或報告功能與您自己的工作流程進行核對。有關選擇格式的指導,請參閱我們關於何時使用自適應、互動式和即時學習的文章。

衡量發生了哪些變化

預先決定哪些指標能夠證明工程師勝任這項任務。將風險分析的品質和未見過的案例中行為保持的證據與基準進行比較。明確納入哪些人員、分母和時間節點。如果結果有所改善,在將功勞歸於培訓之前,檢查同一時期內還有哪些其他變化,例如新的測試工具、更快的建造速度或所有權變更。

可能存在的限制

  • 該進行維護保養工作了。 如果債務償還工作從未被安排,那麼受過訓練的工程師仍然沒有地方運用他們的技能。
  • 測試工具。 如果沒有可用的測試框架或快速建置方案,小步推進和頻繁檢查就難以持續。
  • 案件承保範圍。 一個歷史案例展現了幾種風險類型。評分並不能反映工程師的整體判斷。
  • 判斷何時不應該重構。 有些程式碼最好不要改動,而是替換或棄用,而這個決定不僅僅取決於技術。
  • 轉讓。 在模擬演練的表現與在生產模組交付壓力下的表現並不相同。

儘早將這些問題告知贊助商,並制定單獨的解決方案。培訓可以提升工程師的計畫和驗證能力,但並不能創造時間或工具。

常見問題

什麼是重構培訓計畫?

這是對遺留程式碼進行結構化實踐的一種方式,工程師們計劃進行小的更改,透過測試保護現有行為,逐步更改設計,並證明沒有任何問題發生。

完全重寫程式碼是了解技術債的好方法嗎?

通常情況下不會。重寫程式碼規模龐大,難以驗證,而且會掩蓋你想要培養的技能。而透過測試來捕捉當前行為,進行有限度的更改,則能使邏輯清晰可見。

如何評估工程師能否安全地進行重構?

提供一個新的遺留程式碼案例,並根據既定標準對風險分析和行為保留情況進行評分。重構模式測驗僅用於確認前提條件。

您需要用於培訓的範例程式碼庫嗎?

你需要一個安全的練習場所。許多團隊會先從公開的練習題(kata)入手,然後再過渡到自己程式碼中限定的練習區域。你的工程經理應該確認這段程式碼是否合適。

從哪兒開始

選擇程式碼庫中一種常見的、小規模的遺留變更。撰寫效能說明,請工程經理驗證變更及其對應的測試案例(確保行為保持不變),並制定一個包含三個標準的評分細則(0 到 2 分制)以及一份關鍵錯誤清單。在正式推廣之前,先在一小群人中進行試點。

若要了解如何在自己的團隊中即時進行重構決策練習,並在之後以自定進度重複使用,請探索 AhaSlides。

訂閱即可獲得提升觀眾參與度的技巧、見解和策略。
謝謝! 您的提交已收到!
糟糕! 提交表格時出了點問題。

查看其他帖子

AhaSlides 已被福布斯美國 500 大企業所採用。立即體驗互動的力量。

開始免費試用
© 2026 AhaSlides 私人有限公司