作者 | Dev by RayRay

譯者 | 王強(qiáng)

策劃 | 李俊辰

本文最初發(fā)布于 byrayray.dev 網(wǎng)站，經(jīng)原作者授權(quán)由 InfoQ 中文站翻譯并分享

在本文中，我會(huì)列舉五條提高代碼可讀性的原則。這些原則是我在各種項(xiàng)目、團(tuán)隊(duì)和組織的實(shí)踐中總結(jié)出來(lái)的經(jīng)驗(yàn)。我希望大家可以從這篇文章中學(xué)到一些東西，從而提高代碼的可讀性。

總有人不喜歡從頭到尾看完全文，而是想趕快看完重點(diǎn)，這里為此準(zhǔn)備了太長(zhǎng)不看版：

1. 重用會(huì)多次使用的內(nèi)容。

2. 避免針對(duì)可讀性和可維護(hù)性制定一個(gè)通行的解決方案。

3. 盡可能減小模塊、類或組件的大小。

4. 為你的代碼自動(dòng)化執(zhí)行一些規(guī)則和準(zhǔn)則。

5. 就算你的團(tuán)隊(duì)只有你一個(gè)人，也要像是在多人團(tuán)隊(duì)中一樣編寫便于協(xié)作的代碼。

大多數(shù)開(kāi)發(fā)人員都知道 D.R.Y. 是什么意思（避免重復(fù)代碼）。D.R.Y. 可以幫助你預(yù)防代碼重復(fù)的問(wèn)題。

為什么一個(gè)函數(shù)要寫一遍又一遍呢？你應(yīng)該只編寫一次，然后在需要它的各個(gè)位置重復(fù)使用它。而且如果你需要更改它的代碼，就只需要改動(dòng)一處位置就可以了，用不著把修改好錯(cuò)誤的版本復(fù)制粘貼到各個(gè)地方。

但請(qǐng)注意，D.R.Y. 原則會(huì)讓你引入復(fù)雜性。因?yàn)榈阶詈?，事物被重用的次?shù)會(huì)越來(lái)越多。

當(dāng)你開(kāi)始更改被多次重用的代碼時(shí)，針對(duì)這部分代碼編寫測(cè)試的重要性就會(huì)充分體現(xiàn)出來(lái)了。

可重用性、可讀性和可維護(hù)性彼此之間既是朋友也是敵人。當(dāng)你開(kāi)始在自己的代碼中踐行 D.R.Y. 原則，你就會(huì)引入復(fù)雜性。當(dāng)你引入復(fù)雜性時(shí)，可讀性水平可能就會(huì)下降了。

因此，在構(gòu)建功能時(shí)不要想著先做一個(gè)通行的解決方案。從簡(jiǎn)單入手是最好的！第一次嘗試肯定沒(méi)法做到盡善盡美。

通過(guò)多次迭代，你就可以在重用應(yīng)用程序很多部分的同時(shí)，仍然保持不錯(cuò)的可讀性和可維護(hù)性。

當(dāng)你在擁有許多開(kāi)發(fā)團(tuán)隊(duì)的組織中工作時(shí)，你的團(tuán)隊(duì)可能會(huì)分為內(nèi)部人員和外部人員（例如自由職業(yè)者或顧問(wèn)）。因此在這種情況下，人們會(huì)經(jīng)常在不同組織之間來(lái)回切換。

在這些場(chǎng)景中，可讀性和可維護(hù)性是成功的關(guān)鍵。讓那些很可能隨時(shí)離開(kāi)團(tuán)隊(duì)的人員來(lái)制定通行的解決方案，并不是一個(gè)明智的選擇。

在某些情況下，你的確需要通行方案，但這些方案必須做到很容易閱讀和維護(hù)。

在為一款應(yīng)用程序構(gòu)建一些新功能時(shí)，你可能會(huì)在構(gòu)建前作詳細(xì)的規(guī)劃。

最佳的解決方案肯定是能拆分成許多較小的模塊、類或組件的。你想知道為什么嗎？

因?yàn)樾《未a更容易測(cè)試和維護(hù)。

想象一下，人們?cè)诂F(xiàn)實(shí)中搭建高層建筑時(shí)，也是從一個(gè)個(gè)較小的單元開(kāi)始拼裝而成的，而不是一下子就把整幢大樓都造好，然后設(shè)法安裝到地基上。當(dāng)然了，例外也是有的。

大多數(shù)現(xiàn)代庫(kù)和框架都分成了一些較小的構(gòu)造塊，而不是打包成單個(gè)文件。像 Angular、React 和 Vue 這樣的 JavaScript 庫(kù)和框架都采用了組件的概念。我認(rèn)為他們的選擇并不是無(wú)意識(shí)的結(jié)果。

想要編寫出可讀和可維護(hù)的代碼，一方面要關(guān)注的是代碼的架構(gòu)，另一方面則要關(guān)注代碼的樣式。

我想很多讀者都經(jīng)常會(huì)見(jiàn)到關(guān)于制表符或空格縮進(jìn)的討論。不過(guò)這里我不會(huì)討論這個(gè)話題。無(wú)論你在團(tuán)隊(duì)中使用的是哪種方案，請(qǐng)確保所有團(tuán)隊(duì)成員都遵守它就行了。

最好的解決方案是，盡可能讓這些代碼樣式規(guī)則和準(zhǔn)則自動(dòng)化。許多 IDE 都集成了這種功能，或者可以通過(guò)插件安裝。

最簡(jiǎn)單的一種，也是支持多種語(yǔ)言和代碼編輯器的方案是 editorconfig。只要添加一個(gè).editorconfig，就可以應(yīng)用這些規(guī)則。

https://editorconfig.org/

你可以在這些文件中為你的項(xiàng)目調(diào)整許多設(shè)置。你也可以指定全局設(shè)置方案，或者為特定的語(yǔ)言指定設(shè)置。例如：

• 縮進(jìn)樣式：制表符或空格

• 引號(hào)類型：?jiǎn)我?hào)或雙引號(hào)

• 最大長(zhǎng)度

• 字符集

• 還有更多……

# Editor configuration, see https://editorconfig.org
root = true
[*]
charset = utf-8
indent_style = space
indent_size = 2
insert_final_newline = true
trim_trailing_whitespace = true
[*.ts]
quote_type = single
[*.md]
max_line_length = off
trim_trailing_whitespace = false

網(wǎng)絡(luò)上還有許多適用于某些特定語(yǔ)言的工具。對(duì)于 JavaScript 來(lái)說(shuō)，我喜歡使用 Prettier，但你可能希望換一些不一樣的工具。

https://medium.com/better-programming/eslint-vs-prettier-57882d0fec1d

不管怎樣，只要參與項(xiàng)目的所有人都遵循相同的規(guī)則和準(zhǔn)則，那么具體使用哪一種方案并不重要。

最后一點(diǎn)也是非常重要的，那就是永遠(yuǎn)都像在團(tuán)隊(duì)中一樣編寫便于協(xié)作的代碼！

我可以想象，從未在團(tuán)隊(duì)中編寫過(guò)代碼的開(kāi)發(fā)人員是很難理解這一條原則的。關(guān)注公眾號(hào) 逆鋒起筆，回復(fù) pdf，下載你需要的各種學(xué)習(xí)資料。

可是如果你在一個(gè)人編寫項(xiàng)目，就會(huì)很容易寫出來(lái)很多只有你自己才能理解的代碼（例如編寫模糊不清的變量名、使用 2-3 個(gè)字符的變量名等等）。

應(yīng)該試著像在團(tuán)隊(duì)中一樣編寫能方便他人理解的代碼。想象一下，這就是說(shuō)你的代碼應(yīng)該足夠清晰明了，讓其他人可以輕松理解。

你可以問(wèn)一問(wèn)朋友，或者在開(kāi)發(fā)者社區(qū)中通過(guò) Twitter 找什么人過(guò)來(lái)幫你檢查代碼的可讀性，這是很簡(jiǎn)單的測(cè)試方法。我可以保證，你會(huì)得到自己意想不到的反饋。

不要擔(dān)心負(fù)面反饋！你只要關(guān)注那些可以讓你的代碼對(duì)其他人更具可讀性的反饋意見(jiàn)就行了。

你應(yīng)該知道，可讀代碼與讀起來(lái)略吃力的代碼之間并沒(méi)有很清晰的界限，不同人會(huì)在這個(gè)問(wèn)題上有不同的看法。如果有人告訴你你的代碼很難讀，那也不要難過(guò)！你應(yīng)該感謝對(duì)方的反饋意見(jiàn)。

感謝大家的閱讀！希望你從本文中起碼能學(xué)到一點(diǎn)東西。

如果你對(duì)提高代碼可讀性的方法有任何補(bǔ)充，請(qǐng)隨時(shí)在評(píng)論中分享你的想法。

https://byrayray.dev/posts/2020-11-17-five-rules-to-improve-code-readability

如果覺(jué)得不錯(cuò)，素質(zhì)三連、或者點(diǎn)個(gè)「贊」、「在看」都是對(duì)筆者莫大的支持，謝謝各位大佬啦~
     

     

      點(diǎn)個(gè)『在看』支持下