編寫乾淨的代碼並不是一件容易的事。它需要用不同的技巧和很多的實踐。寫出一手整潔的代碼也是開發者們不斷追求的目標。
編寫乾淨代碼的好處
- 項目更容易啓動和延續
- 適合新團隊人員加入項目組
- 更加容易理解
編寫乾淨代碼的要點
- 代碼更加易讀
- 爲變量，函數和方法使用更有意義的命名
- 讓每個函數或方法只執行一個任務
- 使用註釋進行說明（重要）
- 保持一致性
- 定期檢查您的代碼
編寫乾淨代碼的好處
讓我們先來看看編寫乾淨代碼的一些好處。其中一個主要好處是，乾淨的代碼可以幫助我們最大限度地縮短閱讀和嘗試理解代碼所需的時間。凌亂的代碼會減慢任何開發人員的速度讓他的工作很難開展。代碼越混亂，開發人員需要了解的時間就越多。而且，如果代碼太亂，開發人員可能會思考要不要重構。
1.項目更容易啓動和延續
讓我在一個簡單的例子中證明這一點。假設我們在很長一段時間後回到了我們之前做的一個項目。現在，讓我們想象一下，那時候，我們並沒有編寫最乾淨的代碼，而是相反。在第一次看之後，我們看到代碼有多糟糕和混亂。而且，我們也已經看到從我們中斷的地方開始是多麼困難。
因此，我們現在必須花費更多的時間在項目上，因爲我們需要了解我們之前編寫的代碼。這絕對沒有必要。我們可以從一開始就編寫乾淨的代碼來完全避免它。現在，我們必須付錢。而且，我們的舊代碼如此混亂或糟糕，以至於我們可能決定從頭開始。聽到這些消息後，我們的客戶可能不會高興。
另一方面，清潔代碼通常沒有這個問題。想象一下前面的例子，條件相反。現在，我們之前的代碼乾淨而優雅。理解它需要多長時間？也許我們需要閱讀代碼幾分鐘才能理解一切是如何工作的。最後，我們編寫它已經有一段時間了。但是，這次投資將明顯小於第一種情況。我們的客戶甚至都不會注意到它。
這是代碼編寫的第一個好處，與我們將要討論的技巧一致。而且，這不僅適用於我們自己的項目，也適用於其他開發人員的工作。清潔代碼使我們能夠更快地開始。我們或其他任何人都不需要花費數小時來研究它。相反，我們可以直接進入工作。
2.更適合新的團隊人員入職
編寫乾淨代碼的另一個好處與第一個密切相關。它允許更容易和更快地採用。我的意思是這個。讓我們想象一下，我們需要聘請另一位開發人員。她需要多長時間才能理解代碼並學習如何使用代碼？這取決於。如果我們的代碼很亂並且寫得不好，她將需要更多時間來完成它。另一方面，如果我們的代碼乾淨，易讀，易於理解且簡單，她將能夠更快地開始。
有些人可能會爭辯說，這不是一個問題，因爲我們在那裏，我們可以幫助她。而且，這是事實。但是，我們的幫助應該只需要很短的時間，一兩天或三個。但是，它不應該是一週或兩三個。最後，我們決定聘請另一位開發人員來加快我們的工作，而不是讓它慢下來。我們的目標是通過幫助她學習使用我們的代碼來消磨更多時間。
當我們努力並編寫乾淨的代碼時，其他人更容易遵循它並使用它。當然，我們仍然需要留出一些時間來幫助每個新開發人員瞭解和理解我們的代碼。但是，我們談論的是幾天，而不是幾周。此外，乾淨的代碼將幫助我們爲團隊帶來更多的開發人員，並幫助他們立即理解我們的代碼。簡而言之，代碼越清晰，解釋就越容易，誤解就越少。
3.更容易理解
我們需要記住一件事。瞭解和學習如何使用代碼是一回事。但是，這只是一個開始。我們還需要確保開發人員能夠並願意遵循我們的編碼實踐。同樣，使用乾淨的代碼更容易實現，而不是凌亂。這很重要，因爲我們不僅要編寫乾淨的代碼，而且要保持這種方式，無論有多少人使用它。我們需要長遠思考。
最後一件事與此有關。如果我們的某個開發人員決定不遵循當前的編碼實踐，該怎麼辦？這個問題通常可以解決。假設我們有一羣人在同一個代碼庫上工作，一個人開始偏離標準風格。然後，這三件事之一將會發生。首先，該小組的其他成員將推動一位開發人員遵循標準。她會接受它，因爲她不想離開。
第二種選擇是開發人員實際上會說服團隊的其他成員採用並遵循她的編碼實踐。如果開發人員提出的編碼實踐更清晰並且帶來更好的結果，這可能是一件好事。編寫和保持我們的代碼清潔並不意味着我們應該忽略任何改進它的機會。恰恰相反。我認爲，我們應該始終質疑我們目前的做法，並尋找這些改進的機會。
因此，如果一個開發人員偏離我們的做法，並且她的做法更好，那麼如果我們做出改變而不是她，可能會更好。我認爲在我們檢查和嘗試之前，我們絕不應該忽視某人的做法。總是有改進的餘地，我們應該繼續尋找它。最後，還有第三種選擇。開發商將決定既不採用我們的做法也不說服我們採用她的做法。相反，她可能會定離開團隊。
編寫乾淨代碼的提示
1.使代碼對人們可讀
確實，我們編寫的代碼將由機器解釋。但是，這並不意味着我們應該忽視其可讀性和可理解性。總是有可能另一個人會接觸我們的代碼，或者必須使用它。即使我們讓其他人無法訪問我們的代碼，我們也可能希望將來再回到它。出於這個原因，以一種易於理解的方式編寫代碼符合我們自己的利益。怎麼樣？
最簡單的方法是使用空格。我們可以在發貨之前縮小我們的代碼。但是，沒有必要編寫看起來像縮小的代碼。相反，我們可以使用縮進，換行符和空行來使代碼結構更具可讀性。當我們決定接受這種做法時，我們的代碼的可讀性和可理解性可以顯着提高。然後，單獨查看我們的代碼就足以理解它了。我們來看看兩個簡單的例子。
// 不好的習慣
const userData=[{userId: 1, userName: 'Anthony Johnson', memberSince: '08-01-2017', fluentIn: [ 'English', 'Greek', 'Russian']},{userId: 2, userName: 'Alice Stevens', memberSince: '02-11-2016', fluentIn: [ 'English', 'French', 'German']},{userId: 3, userName: 'Bradley Stark', memberSince: '29-08-2013', fluentIn: [ 'Czech', 'English', 'Polish']},{userId: 4, userName: 'Hirohiro Matumoto', memberSince: '08-05-2015', fluentIn: [ 'Chinese', 'English', 'German', 'Japanese']}];
// 好的做法
const userData = [
{
userId: 1,
userName: 'Anthony Johnson',
memberSince: '08-01-2017',
fluentIn: [
'English',
'Greek',
'Russian'
]
}, {
userId: 2,
userName: 'Alice Stevens',
memberSince: '02-11-2016',
fluentIn: [
'English',
'French',
'German'
]
}, {
userId: 3,
userName: 'Bradley Stark',
memberSince: '29-08-2013',
fluentIn: [
'Czech',
'English',
'Polish'
]
}, {
userId: 4,
userName: 'Hirohiro Matumoto',
memberSince: '08-05-2015',
fluentIn: [
'Chinese',
'English',
'German',
'Japanese'
]
}
];
複製代碼
2.爲變量，函數和方法使用有意義的名稱
有意義的是什麼意思？有意義的名稱是足夠描述的名稱，其他人，而不僅僅是我們，將能夠理解變量，函數或方法的目的。換句話說，名稱本身應該建議變量，函數或方法用於什麼，或者它包含什麼。
// Bad
const fnm = ‘Tom’;
const lnm = ‘Hanks’
const x = 31;
const l = lstnm.length;
const boo = false;
const curr = true;
const sfn = ‘Remember the name’;
const dbl = [‘1984’, ‘1987’, ‘1989’, ‘1991’].map((i) => {
return i * 2;
});
// Better
const firstName = ‘Tom’;
const lastName = ‘Hanks’
const age = 31;
const lastNameLength = lastName.length;
const isComplete = false;
const isCurrentlyActive = true;
const songFileName = ‘Remember the name’;
const yearsDoubled = [‘1984’, ‘1987’, ‘1989’, ‘1991’].map((year) => {
return year * 2;
});
複製代碼
但是，我們應該記住一些事情。使用描述性名稱並不意味着我們可以隨意使用盡可能多的字符。一個好的經驗法則是將名稱限制爲三個或四個單詞。如果我們需要使用超過四個單詞，也許我們會嘗試一次做太多事情，我們應該簡化我們的代碼。所以，讓我們只使用必要的字符。
3.讓一個函數或方法只執行一個任務
當我開始編碼時，我曾經寫過幾乎看起來像瑞士軍刀的功能和方法。他們可以處理並做幾乎任何事情。其中一個後果是，通常很難找到一個好名字。其次，除了我之外幾乎沒有人知道這個或那個功能是做什麼以及如何使用它。好吧，有時甚至我遇到了問題。所以，我不得不寫指令。第三，這些功能有時候是不可預測的。我製造了一團糟。
然後，有人提出了這個很好的建議。讓每個函數或方法只執行一個任務。這個簡單的建議改變了一切，並幫助我編寫乾淨的代碼，至少比之前更乾淨。從那一刻起，其他人終於能夠理解我的代碼。或者，他們並不需要他們之前需要的那麼多時間。我的功能和方法也變得可以預測。在相同輸入的情況下，它們總是產生相同的輸出。而且，命名也變得更容易了。
如果您很難找到功能和方法的描述性名稱，或者您需要編寫冗長的指令以便其他人可以使用它們，請考慮實施此實踐。讓每個函數或方法只執行一個任務。如果您的功能和方法看起來和像瑞士軍刀一樣工作，也可以實施這種做法。相信我，這種多功能性不是一個優勢。這是一個相當不利的因素，任何時候都可能開始適得其反。
4.使用註釋進行說明
有個段子是這麼說的開發人員最討厭的一件事就是自己寫註釋和別人不寫註釋
無論我們如何努力爲我們的變量，函數和方法提出有意義的名稱並不重要。我們的代碼本身仍然沒有儘可能乾淨和易於理解。仍有一些行需要進一步解釋。問題可能不是他們難以理解或使用。相反，爲什麼我們實現這個或那個功能或方法或爲什麼我們以特定的方式創建它可能沒有意義。意思是，歷史還不清楚。
有時我們可能不得不使用相當非常規的方法來解決問題，因爲沒有別的方法可行，或者我們沒有足夠的時間來提出更好的解決方案。這可能很難用代碼來解釋。通過我們的代碼使用註釋可以幫助我們解決這個問題。評論可以幫助我們向其他人解釋爲什麼我們寫了我們寫的東西，以及爲什麼我們以特定的方式編寫它。結果，其他人不必猜測。
更重要的是，當我們解釋原因時，其他人可能會找到更好的方法來解決問題並改進代碼。這是可能的，因爲他們知道問題是什麼以及期望的結果是什麼。在不知道這些信息的情況下，其他人更難以創建更好的解決方案。或者，他們甚至可能不會嘗試，因爲他們認爲不需要它。他們可以認爲這是我們的意圖。
因此，每當我們發現自己處於決定使用某種黑客攻擊，快速修復或非常規方法的情況時，讓我們使用註釋來解釋我們爲什麼做了我們所做的事情。最好使用一行或兩行作爲解釋註釋，而不是強迫人們猜測。
話雖如此，我們應該只在必要時使用註釋，而不是解釋錯誤的代碼。編寫無窮無盡的註釋行不會幫助我們將編寫糟糕的代碼轉換爲乾淨的代碼。如果代碼不好，我們應該通過改進代碼來解決問題，而不是通過添加關於如何使用它的指令來解決問題。清除代碼優先於使用快捷方式。
5.保持一致
當我們找到我們喜歡的特定編碼實踐或風格時，我們應該堅持並隨處使用它。在不同的項目中使用不同的編碼實踐或風格並不是一個好主意。它幾乎和不使用任何編碼實踐或風格一樣有用和有用。回到我們的舊代碼將不會像它可能那樣平滑和自然。我們仍然需要一些時間來理解我們在該項目中使用的編碼實踐，然後才能使用它。
最好的辦法是選擇一套編碼實踐，然後在所有項目中堅持這些實踐。然後，返回我們的舊代碼將更容易，並繼續我們中斷或改進它。實驗怎麼樣？嘗試新的編碼實踐是一件好事。它可以幫助我們找到更好的方法來完成我們的工作。但是，最好在不同的實驗項目或練習上試驗不同的實踐，而不是我們的主要項目。
此外，當我們決定做一些實驗時，我們應該多次嘗試這種做法，並嘗試多個例子。我們應該花時間徹底做這個實驗。只有當我們確信我們喜歡這種做法並且我們對此感到滿意時，我們才應該實施它。而且，當我們決定這樣做時，最好在我們的所有項目中全球實施我們的新實踐。是的，這需要時間，但這會迫使我們適當地考慮變化。
6.定期檢查您的代碼
這是我編寫乾淨代碼的最後一個提示。簡單地編寫乾淨的代碼並不是一切。我們的工作不是用最後的分號完成的。下一步是保持我們的代碼清潔。清潔代碼需要維護。當我們寫東西時，我們應該定期檢查，清理它並嘗試改進它。否則，如果我們不審查和更新我們的舊代碼，它很快就會過時。就像我們的設備一樣。如果我們想讓它們保持最佳狀態，我們需要定期更新它們。
對於我們每天使用的代碼，情況尤其如此。代碼隨着時間的推移變得越來越複雜和混亂，而不是更簡單和更清潔。我們有責任防止這種情況發生並保持我們的代碼清潔。實現這一目標的唯一方法是定期檢查我們的代碼。換句話說，我們需要維護它。對於我們不再關心或沒有未來的項目，這可能不是必需的。對於其他人來說，維護是我們工作的一部分。
關於編寫乾淨代碼的想法
我們在本文的最後。我們今天討論的這六種做法可能不是影響最大或影響最大的那些。但是，它們是經驗豐富的開發人員最常提到的那些。這就是我選擇它們的原因。我希望這些實踐或技巧足以幫助您開始編寫乾淨的代碼。現在，和所有事情一樣，最重要的是開始。所以，選擇至少一種做法並嘗試一下。
非常感謝您的寶貴時間。有一個美好的一天！