言

最近，我一直在使用多個步驟（具有“上一步” 和“下一步”按鈕）的HTML表單，其中表單的各個部分具有相同的“其他” 復選框。我使用“ onchange ”的JavaScript事件檢查何時CheckBox被選中，然后顯示“其他”標簽和輸入字段。我遇到的問題是，因為有多個“其他”復選框，它們都有不同的“ id ”，這是一個問題，因為我要在同一個函數中處理具不同的id。

重構前的代碼

以下是代碼重構之前的原始函數，顯示如何獲取元素，并檢查“其他” Checkbox是否被檢查，然后更改CSS樣式。

重構前的代碼

在這里，if 語句只是檢查Checkbox是否被選中，然后我將為其他標簽設置CSS顯示值，并輸入“ inline
”來顯示它們，或者“ none”使其隱藏。

代碼重構

由于在整個表格中共有七（7）個“其他”的Checkbox ，所以有七個相似的功能，基本上做同樣的事情是沒有意義的。所以我決定對代碼重構并做一個主要的功能，并傳遞一個數組中的元素的id值。

簡化的代碼如下：

重構后的代碼

在這種情況下，Values參數是Array傳遞給該函數的。這里，如果我們要對“員工”賦值，可以調用函數“changeEmploy”進行賦值，“changeEmploy”函數如下：

賦值函數

同樣地，如果我們要對“個人”進行賦值，同樣可以重用“handleCheckbox”，代碼如下：

賦值函數

代碼是不是變得更簡潔了呢？

制定了一個計劃，選擇了一個工作，編寫測試，現在你已經準備好清理一些代碼。是時候了！你會被誘惑打開一個文件，并開始改變變量名稱或清理一個已經讓你瘋狂的文件夾的內容。然而，在開始深入代碼庫之前，您應該熟悉一些概念以確保重構的順利進行。

在本系列的最后部分，我將介紹一些在重寫過程中可能遇到的常見錯誤。我還會介紹一些加速一些更乏味的任務的技巧。我不會涵蓋與重構相關的特定機制，定義或流程。

識別自動化的機會

有一個很好的機會，你會有一些項目任務會很乏味。我遇到的最大的罪犯之一是移動文件。例如，我重構的應用程序在各自的文件夾中有Redux操作、還原器和選擇器。我的一個項目任務是通過模塊(例如appActions)對Redux文件進行分組。js,appReducer.js和appSelectors.js)。我可以運行一個git mv command to move /actions/app.js to /redux/app/appActions.js，然后做同樣的for /reducers/app.js 和 /selectors/app.js，但這只需要應用程序模塊。在這個項目中有11個模塊，所以我必須為Redux元素輸入33個git mv命令。您可能需要運行git mv 150多次才能在正確的文件夾位置獲得響應容器和組件!

你會發現這種情況很快就會變得站不住腳。我沒有寫出所有這些命令，而是編寫了一個腳本來使用JavaScript和Node.js為我完成：

const fs=require('fs');

const path=require('path');

const chalk=require('chalk');

const sh=require('shelljs');

const _=require('lodash');

const sourcePath=path.resolve(process.cwd(), 'src');

// This is the new /src/redux folder that gets created:

const reduxPath=path.resolve(sourcePath, 'redux');

// I used "entities" instead of "modules", but they represent the same thing:

const entities=[

'app',

'projects',

'schedules',

'users',

];

const createReduxFolders=()=> {

if (!fs.existsSync(reduxPath)) fs.mkdirSync(reduxPath);

// Code to create entities folders in /src/redux...

};

// Executes a `git mv` command (I omitted some additional code that validates

// if the file already exists for brevity).

const gitMoveFile=(sourcePath, targetPath)=> {

console.log(chalk.cyan(`Moving ${sourcePath} to ${targetPath}`));

const command=`git mv ${sourcePath} ${targetPath}`;

sh.exec(command);

console.log(chalk.green('Move successful.'));

};

const moveReduxFiles=()=> {

entities.forEach(entity=> {

['actions', 'reducers', 'selectors'].forEach(reduxType=> {

// Get the file associated with the specified entity for the specified reduxType,

// so the first file might be /src/actions/app.js:

const sourceFile=path.resolve(sourcePath, reduxType, `${entity}.js`);

if (fs.existsSync(sourceFile)) {

// Capitalize the reduxType to append to the file name (e.g. appActions.js):

const fileSuffix=_.capitalize(reduxType);

// Build the path to the target file, so this would be /src/redux/app/appActions.js:

const targetPath=`${reduxPath}/${entity}`;

const targetFile=`${targetPath}/${entity}${fileSuffix}.js`;

// Execute a `git mv` command for the file:

gitMoveFile(sourceFile, targetFile);

}

});

});

};

moveReduxFiles();

您可以在運行腳本后進入文件并更新相對路徑，也可以編寫腳本以使用字符串操作更新路徑。自動化可以變得很花哨，但知道什么時候可以劃清界限：花20個小時編寫一個腳本來節省一個小時的手動工作是沒有意義的。大多數代碼庫都是獨特的，并且具有特定的結構，這意味著您可能無法重用這些腳本。

經常提交

對文件或文件集進行重大更改可能會破壞您的應用程序并導致測試失敗。這是可以預料的。如果您做了一系列更改并且一切正常，請提交更改。如果您只做了一些小更新并且一切仍然有效，請提交更改。提交便宜。以下是我重構的應用的一些指標：

• 提交1747次。

• 378個關閉請求。

• 橫跨169個 Jest快照文件的42,017行文本。

• 在181個測試文件中總共有13,555行文本。

• 跨2個夾具文件（responses.js 和state.js）共24,261行文本。

• 跨198個 JavaScript文件共16,685行文字。

• 橫跨111個 Sass文件的3,823行文本。

這是659個文件中的76,080行代碼，并且存儲庫大小僅為10MB。做所有你想要的提交 - git可以處理它。如果你想清理你的歷史，你可以隨時擠壓它們。我敦促你盡可能頻繁地執行; 當重構一個大型應用程序時，你很快就會意識到追蹤小問題有多難。

想象一下，對10個文件進行更改，驗證您的應用程序仍然有效，并且對代碼感到滿意。您決定不提交您的更改，并且在重構另一半小時后，您會破壞某些內容。您可以花三個小時追蹤錯誤，或者放棄所有更改并從頭開始。由于您沒有對這10個文件進行更改，因此您失去了完美的代碼！

我并不是說要確定是否需要重置這些文件是不可能的，但是當您知道可以跳回最后一次提交并從那里開始時，為什么會浪費時間和精力。嘗試將提交的更改限制在一次只提交幾個文件，并經常提交，以便可靠地保存“保存點”。

避免誘惑

避免清理超出手頭任務范圍的代碼。這是重構最困難的方面之一。假設您正在開發一項名為Standardize Redux Selector Names的任務，這些任務涉及更新選擇器的名稱，以確保所有這些名稱都加上了前綴 select。作為風險較低，范圍界定明確的比較簡單的任務，應該順利進行; 您只需更新選擇器名稱（以及引用這些選擇器的任何文件）以適應更改（并且不要忘記測試?。?。

假設你遇到一個正在使用的選擇器 Object.assign()，而你未來的任務之一是更新代碼以利用一些新的ESNext功能，如擴展語法。您可能會試圖更新該代碼，但不要！

你必須不偏離當前的任務。即使是最微不足道的改變也會讓你走上錯誤的道路。即使滑坡的概念是一個合乎邏輯的謬誤，經常會出現一個較不雙曲的情況。你開始改變 Object.assign() 語句，在你知道它之前，已經過了四個小時，你只更新了兩個選擇器名稱！

隨著我重構任務的進展，我變得不那么容易受這種行為的影響。我// REFACTOR: Fix this later 在代碼中添加了一條 評論，并檢查了我的項目以確保我有一項任務來覆蓋更改，然后我繼續前進。

對拉取請求有一定的方法性

拉請求是重構項目的一個很好的工具，原因有很多，它們是：

• 提供與項目任務相對應的更改記錄。

• 定義一個回滾點，如果引入新的錯誤。

• 讓同行審閱你的代碼并尋找潛在的錯誤。

• 提供解釋您為什么進行某些更改的機會。

如果您花費大量時間清理代碼庫的一部分，則可能很難退后一步并評估更改的質量。拉取請求會讓您的同事有機會查看您的更改并確定它們是否可以增加價值并改進現有的代碼。

當您提交pull請求時，請在摘要中盡可能描述。將一個模板放在一起并將其包含在您的存儲庫中。如果你使用的是GitHub，這個模板將自動被拉入新的PR。嘗試包括標題，高級描述，重要筆記的章節以及變更列表。變更清單不一定要廣泛而羅嗦，但應包括審評人員應重點關注的重要變化。

您需要了解的一個指標是與請求相關的更改數量。嘗試限制更改的數量為+/- 500行代碼。添加Jest快照文件可以輕松地將數千行添加到拉取請求中，因此請務必在摘要中包含關于此的注釋。如果你不能最小化改變的數量，努力減少復雜性。如果您只是重新排序導入語句，只要這些更改不是太復雜，就可以接受超過2000行的代碼。嘗試在單個PR中隔離這種變化，并確保您在摘要中描述變更的性質。它有助于在摘要的開頭添加一個大膽的注釋，例如“沒有進行邏輯更改”，因此審閱者具有適當的上下文。

通過在拉取請求中編寫描述性摘要并確保更改的范圍與項目任務相對應，您將使審閱者變得更加輕松。我承認，我并不總是能夠遵循我自己的建議（我仍然欠我的一些同事一頓午餐或10美元），但我確信我很快回復了詢問并解決了問題。

結束

這就是重構系列！我希望我所提出的集體智慧將為您重構項目的成功做出貢獻。重構不像重新編排代碼庫中的文件或重命名函數那么簡單，但是如果您制定了一個穩定的計劃，遵守該計劃并定期更新，那么您將有一個良好的開端。擁有一個強大的測試基礎架構將使您有信心在不破壞任何功能的情況下進行更改。

在執行方面，盡可能地自動化，經常實施，避免誘惑。拉請求是一個很好的文檔和審查工具，所以確保他們的詳細和范圍有限。如果你想知道，這里是我的重構項目的結果：

• 完成40項任務。

• 12項待處理任務。

• 1記錄了Jira bug（直接與重構相關）。

• 在181個測試套件中編寫了1,473個測試（其中737個是快照測試）。

• 108450線并將44241線除去。

• 38個拉取請求。

• 聲明覆蓋率為99.84％。

• 分支機構覆蓋率95.07％。

添加和刪除的行并沒有多大意義，因為其中大部分代表了文件移動，快照和測試夾具文件。高測試覆蓋率也應該帶著一絲鹽：我忽略了一些圖表組件，因為很難測試HTML Canvas元素。我在重構過程中添加了幾個功能并修復了各種錯誤，并且在測試覆蓋率較高的情況下，在可能包含在發布之前，發現了幾個潛在問題。總的來說，我認為重寫肯定是值得的。