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

未找到任何項目。
Blog 縮略圖

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

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

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

什麼是重構培訓計畫?

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

要聞速覽

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

1. 描述效能問題

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

準確使用術語很有幫助。 Martin 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 私人有限公司