簡單了解JavaScript中常見的反模式

前言

反模式 是指對反復出現(xiàn)的設(shè)計問題的常見的無力而低效的設(shè)計模式，俗話說就是重蹈覆轍。 這篇文章描述了 JavaScript 中常見的一些反模式，以及避免它們的辦法。

硬編碼

硬編碼（Hard-Coding）的字符串、數(shù)字、日期…… 所有能寫死的東西都會被人寫死。 這是一個婦孺皆知的反模式，同時也是最廣泛使用的反模式。 硬編碼中最為典型的大概是 平臺相關(guān)代碼（Platform-Related）， 這是指特定的機器或環(huán)境下才可以正常運行的代碼， 可能是只在你的機器上可以運行，也可能是只在 Windows 下可以運行。

例如在 npm script 中寫死腳本路徑 /Users/harttle/bin/fis3， 原因可能是安裝一次非常困難，可能是為了避免重復安裝，也可能僅僅是因為這樣好使。 不管怎樣，這會讓所有同事來找你問“為什么我這里會報錯”。 解決辦法就是把它放到依賴管理，如果有特定的版本要求可以使用 package-lock，如果實在搞不定可以視為外部依賴可以放到本地配置文件并從版本控制（比如 Git） 移除。

例如在 cli 工具中寫死特殊文件夾 /tmp, ~/.cache，或者路徑分隔符 \\ 或 /。 這類字符串一般可以通過 Node.js 內(nèi)置模塊（或其他運行時 API）來得到， 比如使用 os.homedir, os.tmpdir, path.sep 等。

重復代碼

重復代碼（Duplication）在業(yè)務(wù)代碼中尤為常見，初衷幾乎都是維護業(yè)務(wù)的穩(wěn)定性。 舉個例子：在頁面 A 中需要一個漂亮的搜索框，而頁面 B 中恰好有一個。 這時程序員小哥面臨一個艱難的選擇（如果直接拷貝還會有些許感到不安的話）：

• 把 B 拷貝一份，改成 A 想要的樣子。
• 把 B 中的搜索框重構(gòu)到 C，B 和 A 引用這份代碼。

由于時間緊迫希望早點下班，或者由于改壞 B 需要承擔責任 （PM：讓你做 A 為啥 B 壞了？回答這個問題比較復雜，這里先跳過）， 經(jīng)過一番思考后決定采取方案 2。

至此整個故事進行地很自然也很順利，這大概就是重復代碼被廣泛使用的原因。 這個故事中有幾點需要質(zhì)疑：

• B 這么容易被改壞，說明 B 的作者 并未考慮復用。這時不應(yīng)復用 B 的代碼，除非決定接手維護它。
• B 改壞的責任不止程序員小哥：B 的作者是否有 編寫測試，測試人員是否 回歸測試 B 頁面？
• 時間緊迫不必然導致反模式的出現(xiàn)，不可作為說服自己的原因。短期方案也存在優(yōu)雅實現(xiàn)。

解決辦法就是：抽取 B 的代碼重新開發(fā)形成搜索框組件 C，在 A 頁面使用它。 同時提供給日后的小伙伴使用，包括敦促 B 的作者也遷移到 C 統(tǒng)一維護。

假 AMD

模塊化本意是指把軟件的各功能分離到獨立的模塊中，每個模塊包含完整的一個細分功能。 在 JavaScript 中則是特指把腳本切分為獨立上下文的，可復用的代碼單元。

由于 JavaScript 最初作為頁面腳本，存在很多引用全局作用域的語法，以及不少基于全局變量的實踐方式。 比如 jQuery 的 $, BOM 提供的 window，省略 var 來定義變量等。 AMD 是 JavaScript 社區(qū)較早的模塊化規(guī)范。這是一個君子協(xié)定，問題就出在這里。 有無數(shù)種方式寫出假的 AMD 模塊：

• 沒有返回值。對，要的就是副作用。
• define 后直接 require。對，要的就是立即執(zhí)行。
• 產(chǎn)生副作用。修改 window 或其他共享變量，比如其他模塊的靜態(tài)屬性。
• 并發(fā)問題。依賴關(guān)系不明容易引發(fā)并發(fā)問題。

全局副作用的影響完全等同于全局變量，幾乎有全局變量的所有缺點： 執(zhí)行邏輯不容易理解；隱式的耦合關(guān)系；編寫測試困難。下面來一個具體的例子：

// file: login.js
define('login', function () {
fetch('/account/login').then(x => {
window.login = true
})
})
require(['login'])

這個 AMD 模塊與直接寫在一個 <script> 并無區(qū)別，準確地說是更不可控（requirejs 實現(xiàn)是異步的）。 也無法被其他模塊使用（比如要實現(xiàn)注銷后再次登錄），因為它沒返回任何接口。 此外這個模塊存在并發(fā)問題（Race Condition）：使用 window.login 判斷是否登錄不靠譜。

解決辦法就是把它抽象為模塊，由外部來控制它的執(zhí)行并獲得登錄結(jié)果。 在一個模塊化良好的項目中，所有狀態(tài)最終由 APP 入口產(chǎn)生， 模塊間共享的狀態(tài)都被抽取到最近的公共上級。

define(function () {
return fetch('/account/login')
.then(() => true)
.catch(e => {
console.error(e)
return false
}
})

注釋膨脹

注釋的初衷是讓讀者更好的理解代碼意圖，但實踐中可能恰好相反。直接舉一個生活中的例子：

// 判斷手機百度版本大于 15
if (navigator.userAgent.match(/Chrome:(\d+))[1] < 15) {
// ...
}

哈哈當你讀到這一段時，相信上述注釋已經(jīng)成功地消耗了你的時間。 如果你第一次看到這樣的注釋可能會不可思議，但真實的項目中多數(shù)注釋都是這個狀態(tài)。 因為維護代碼不一定總是記得維護注釋，況且維護代碼的通常不止一人。 C 語言課程的后遺癥不止變量命名，“常寫注釋”也是一個很壞的教導。

解決辦法就是用清晰的邏輯來代替注釋，上述例子重新編寫后的代碼如下：

if (isHttpsSupported()) {
// 通過函數(shù)抽取 + 命名，避免了添加注釋
}
function isHttpsSupported() {
return navigator.userAgent.match(/Chrome:(\d+))[1] < 15
}

函數(shù)體膨脹

“通?！闭J為函數(shù)體膨脹和全局變量都是算法課的后遺癥。 但復雜的業(yè)務(wù)和算法的場景確實不同，前者有更多的概念和操作需要解釋和整理。 整理業(yè)務(wù)邏輯最有效的手段莫過于變量命名和方法抽?。ó斎?，還要有相應(yīng)的閉包或?qū)ο螅?/p>

但在真實的業(yè)務(wù)維護中，保持理性并不容易。 當你幾十次進入同一個文件添加業(yè)務(wù)邏輯后，你的函數(shù)一定會像懶婆娘的裹腳布一樣又臭又長：

function submitForm() {
var username = $('form input#username').val()
if (username === 'harttle') {
username = 'God'
} else {
username = 'Mortal'
if ($('form input#words').val().indexOf('harttle')) {
username = 'prophet'
}
}
$('form input#username').val(username)
$('form').submit()
}

這只是用來示例，十幾行還遠遠沒有達到“又臭又長”的地步。 但已經(jīng)可以看到各種目的的修改讓 submitForm() 的職責遠不止提交一個表單。 一個可能的重構(gòu)方案是這樣的：

function submitForm() {
normalize()
$('form').submit()
}
function normalize() {
var username = parseUsername(
$('form input#username').val(),
$('form input#words').val()
)
$('form input#username').val(username)
}
function parseUsername(username, words)
if (username === 'harttle') {
return 'God'
}
return words.indexOf('harttle') ? 'prophet' : 'Mortal'
}

在重構(gòu)后的版本中，我們把原始輸入解析、數(shù)據(jù)歸一化等操作分離到了不同的函數(shù)， 這些抽離不僅讓 submitForm() 更容易理解，也讓進一步擴展業(yè)務(wù)更為方便。 比如在 normalize() 方法中對 input#password 字段也進行檢查， 比如新增一個 parseWords() 方法對 input#words 字段進行解析等等。

總結(jié)

常見的反模式還有許多，比如 == 和 != 的使用；擴展原生對象；還有 Promise 相關(guān)的 等等。

== 要提一下。這是語言的設(shè)計缺陷通常使用 Lint 工具來避免使用。與其他 Lint 錯誤不同的是一旦開始大面積使用后續(xù)改正十分困難（因為與 === 確實不等價）。因此強烈建議項目初始化時就添加 Lint。

這些反模式的流行背后都存在很有說服力的原因， 但反模式對可維護性和軟件的長期發(fā)展有著更為嚴重的影響。 按照 技術(shù)債務(wù) 的說法， 每次選擇捷徑都會產(chǎn)生隱含的代價，而這些代價在將來的某一時刻總要償還。 那些推遲的重構(gòu)不僅會影響下一次變更，而且會像經(jīng)濟債務(wù)一樣持續(xù)地疊加利息。

雖然不存在一種具體的考核方法來計算債務(wù)大小， 但可以肯定的是如果你能熟練使用 Harttle 博客中總結(jié)的各種反模式， 一定能達到每次代碼提交債務(wù)大于收益的境界。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持億速云。