?譯者 | 布加迪

審校 | 孫淑娟

代碼重構(gòu)簡介

代碼重構(gòu)指在不更改代碼功能的情況下，重構(gòu)之前編寫的代碼。重構(gòu)并不意味著添加新功能或重寫代碼來修復(fù)任何類型的錯(cuò)誤。

進(jìn)行重構(gòu)有幾個(gè)好處，包括：

• 提升性能
• 提高代碼覆蓋率
• 提高代碼可讀性
• 更深入地理解代碼庫
• 更易于擴(kuò)展、維護(hù)和升級
• 查找錯(cuò)誤或漏洞

通常每次針對一小塊代碼進(jìn)行重構(gòu)，而不是直接處理龐大的代碼庫。

別忘記在重構(gòu)之前應(yīng)該有寫得很好的測試用例。測試用例有助于確保剛修改的代碼并不破壞現(xiàn)有功能。時(shí)不時(shí)測試應(yīng)用程序的整體代碼覆蓋率也是一個(gè)好的做法?？赡軟]有100%的代碼覆蓋率，但工程師應(yīng)該始終旨在接近100%的代碼覆蓋率。

下圖顯示了重構(gòu)過程通常是如何進(jìn)行的。

我想分享自己的故事，講述我和我的團(tuán)隊(duì)過去如何處理重構(gòu)。五年來，我從事過諸多項(xiàng)目。有一個(gè)項(xiàng)目有非常舊的代碼庫，維護(hù)和擴(kuò)展起來有難度。我們遇到了連添加一個(gè)小功能都很難的情況。這里存在很多的代碼冗余。我們與項(xiàng)目CTO和產(chǎn)品負(fù)責(zé)人討論了這個(gè)問題，一致同意在添加任何新功能之前先執(zhí)行重構(gòu)。由于沒有編寫測試用例，因此無法直接跳過去修改代碼。

初創(chuàng)公司什么時(shí)候應(yīng)考慮重構(gòu)？

當(dāng)我們的團(tuán)隊(duì)決定是否應(yīng)該重構(gòu)時(shí)，我們考慮在以下開發(fā)者工作流程步驟進(jìn)行重構(gòu)：

• 在代碼審查期間

代碼審查又叫同行代碼審查，是代碼審查人員在接受合并請求（PR）之前檢查代碼庫的過程。這是確保代碼無錯(cuò)誤、高效、遵循最佳編碼約定的好方法。

將每個(gè)團(tuán)隊(duì)成員添加為代碼審查員幫助我們及早發(fā)現(xiàn)了錯(cuò)誤，并在整個(gè)公司保持一致的編碼風(fēng)格，因?yàn)楹喜⒄埱笾挥性诘玫剿写a審查員的批準(zhǔn)后才會合并。

• 添加任何更新或新功能后

考慮重構(gòu)的方法之一是在添加新功能或?qū)?yīng)用程序進(jìn)行任何更改之前。這么做將有助于改進(jìn)應(yīng)用程序的代碼庫，而且將來的工程師使用起來會更有效率。此外，工程師應(yīng)定期檢查項(xiàng)目是否具有良好的代碼覆蓋率。

由于應(yīng)用程序使用Ruby on Rails編寫，我們使用了Rubocop（https://rubocop.org/?ref=hackernoon.com），這是一種Ruby代碼樣式檢查器（linter）和格式化工具。Rubocop不僅報(bào)告了代碼庫中的問題，還自動修復(fù)了一些問題。

• 推出產(chǎn)品后

大多數(shù)初創(chuàng)公司通常旨在快速推出產(chǎn)品。這個(gè)過程中可能有一些代碼不符合高質(zhì)量代碼標(biāo)準(zhǔn)。因此，一旦產(chǎn)品面市，重構(gòu)代碼庫也是使代碼更高效、更穩(wěn)健的好方法。這么做不會影響業(yè)務(wù)，因?yàn)楫a(chǎn)品已經(jīng)在市場上推出了。

由于產(chǎn)品已經(jīng)投放市場，我們的團(tuán)隊(duì)使用這種方法進(jìn)行重構(gòu)。我們致力于重構(gòu)應(yīng)用程序代碼庫的大部分代碼，以提高代碼可讀性并降低復(fù)雜性。

初創(chuàng)公司在進(jìn)行重構(gòu)時(shí)可能會遇到哪些問題？

初創(chuàng)公司在進(jìn)行重構(gòu)時(shí)面臨許多挑戰(zhàn)。我們在這么做的過程中就遇到了很多問題：

• 耗費(fèi)時(shí)間

有時(shí)，重構(gòu)花費(fèi)的時(shí)間比預(yù)期的長。初創(chuàng)公司經(jīng)常需要添加新功能，更專注于盡早將產(chǎn)品投放市場。初創(chuàng)公司需要聘請專門的開發(fā)人員，或推遲開發(fā)新功能，執(zhí)行代碼重構(gòu)。

我們在沒有任何測試用例的情況下處理遺留代碼庫，因此我們花費(fèi)的時(shí)間比預(yù)期的長。

• 引入錯(cuò)誤的風(fēng)險(xiǎn)

在進(jìn)行代碼重構(gòu)時(shí)，始終有可能引入錯(cuò)誤。工程師在正確重構(gòu)代碼之前，需要了解代碼邏輯。

這個(gè)過程幫助我們跟蹤試運(yùn)行環(huán)境和生產(chǎn)環(huán)境中的錯(cuò)誤。

• 復(fù)雜性

重構(gòu)以前編寫的代碼是一項(xiàng)復(fù)雜的任務(wù)。涉及多個(gè)開發(fā)人員或自由職業(yè)者時(shí)，就變得更為復(fù)雜。首先，您需要了解代碼庫，檢查是否編寫了適當(dāng)?shù)臏y試用例。如果缺少任何測試用例，需要添加。了解編寫的代碼、編寫測試用例，并確保剛修改的代碼不會破壞任何功能，這使得重構(gòu)過程很復(fù)雜。

成功重構(gòu)的流程

經(jīng)過幾次討論后，我們的團(tuán)隊(duì)決定在處理重構(gòu)時(shí)遵循以下步驟：

• 添加測試用例。
• 使用Stepsize，直接從編輯器將技術(shù)問題添加到我們的項(xiàng)目管理工具。
• 將代碼部署到試運(yùn)行環(huán)境，等它通過所有測試用例。
• 讓客戶審查試運(yùn)行環(huán)境中的變更，確保沒有受到影響。
• 定期監(jiān)控Bugsnag這個(gè)錯(cuò)誤監(jiān)控軟件，查看Stepsize問題。
• 將代碼更新部署到主分支，等它通過所有測試用例。最后，合并主分支，并部署到生產(chǎn)環(huán)境。
• 從上往下重復(fù)該過程。

如何縮短重構(gòu)所花的時(shí)間？

我們遵循以下幾個(gè)策略來避免或縮短重構(gòu)所花的時(shí)間：

• 每隔一個(gè)sprint就有重構(gòu)周

縮短重構(gòu)時(shí)間的方法之一是，每隔一個(gè)迭代開發(fā)周期（sprint）安排重構(gòu)周。這么做將有助于在代碼庫的問題導(dǎo)致嚴(yán)重問題之前發(fā)現(xiàn)這些問題，保證將來不會有任何技術(shù)債務(wù)。

使用這種方法，我們的團(tuán)隊(duì)減少了大部分重構(gòu)時(shí)間。我們開始編寫缺失的測試用例，這幫助我們提高了整個(gè)代碼覆蓋率。

總體而言，每隔一個(gè)sprint安排重構(gòu)周是為了縮短花費(fèi)在批量重構(gòu)上的時(shí)間，防止技術(shù)債務(wù)出現(xiàn)。

• 在編輯器中跟蹤代碼庫問題

開發(fā)人員將大部分時(shí)間花在代碼編輯器上。因此，標(biāo)記這些問題的最佳地方是在編輯器中。

Stepsize VSCode和JetBrains擴(kuò)展件有助于全面了解開發(fā)人員可以解決的代碼庫問題，避免造成大量重構(gòu)和技術(shù)債務(wù)，并為開發(fā)人員節(jié)省大量時(shí)間。

您可以將技術(shù)問題與您的代碼關(guān)聯(lián)起來，并在Jira、Asana、Azure DevOps和Linear等不同的項(xiàng)目管理工具中查看。

• 定期討論技術(shù)債務(wù)

在每次編碼sprint之后，定期討論技術(shù)債務(wù)始終很棒。團(tuán)隊(duì)可以討論什么是正確的，什么是錯(cuò)誤的。這樣一來，工程師可以獲得必要的反饋。

在編碼sprint后，我們開始簡短地討論技術(shù)債務(wù)。在過去花費(fèi)大量時(shí)間進(jìn)行重構(gòu)、了解造成的嚴(yán)重后果之后，產(chǎn)品負(fù)責(zé)人也參與到技術(shù)債務(wù)討論。這使產(chǎn)品負(fù)責(zé)人意識到取得的成果，以及在項(xiàng)目受到巨大影響之前需要處理的問題。

原文標(biāo)題：??Reducing Time Spent on Refactoring 3 Tips from a Dev???，作者：Alex Omeyer?