寫在前面

這個(gè)文章本來沒打算寫，直到經(jīng)歷了幾次代碼評審會(huì)議之后，我意識到自己編碼方式還不成系統(tǒng)，仍然需要進(jìn)行系統(tǒng)化的學(xué)習(xí)，掌握前輩們總結(jié)出的最適用的規(guī)律無疑是一種好的方式。恰好很早之前就收藏了這本代碼整潔之道，便決定趁著閑暇之際閱讀總結(jié)一下，如果想系統(tǒng)學(xué)習(xí)的話建議還是讀書，本文檔只是作為自己的記錄用。

一個(gè)人的職業(yè)素養(yǎng)體現(xiàn)在解決問題的方式、步驟以及反思的程度，而不在于這個(gè)問題本身的難度。思考一個(gè)問題：一個(gè)技術(shù)人員要具備哪些素質(zhì)可以被認(rèn)為是專業(yè)人員呢？如果還不具備需要如何改變才能被視為專業(yè)人士呢？

整潔代碼

一、為什么要寫糟糕的代碼？

每個(gè)人都有自己的原因，相信很多人都會(huì)想著等有時(shí)間的話再進(jìn)行代碼優(yōu)化，但是要記住一句話：稍后等于永不。

二、混亂代碼的代價(jià)？

后續(xù)難以維護(hù)和修改，生產(chǎn)力和時(shí)間呈現(xiàn)負(fù)相關(guān)。

三、什么是整潔的代碼？

整潔的代碼只做好一件事：每個(gè)類、每個(gè)函數(shù)、每個(gè)模塊都專注于一事，完全不受四周細(xì)節(jié)的干擾和污染。

更全面的概括是：減少重復(fù)代碼、提高表達(dá)力、提早構(gòu)建簡單抽象。

更具體的實(shí)現(xiàn)：請接著往下看吧！

更好的變量命名

一、見名知意

二、抽象工廠：接口不要命名為IShapeFactory，前導(dǎo)字母對于用戶來說其實(shí)是干擾，用戶只需要知道那是個(gè)抽象工廠，建議使用CShapeFactory或許體驗(yàn)更好

三、類名要用名詞，方法要用動(dòng)詞，詞性相近的get、fetch這種詞不應(yīng)出現(xiàn)在一起，可以添加后綴getNumber、fetchData實(shí)現(xiàn)相同的效果

四、別害怕長名字：使用描述性的名稱，哪怕比較長也比短而令人費(fèi)解的名稱好

更好的函數(shù)

一、函數(shù)的結(jié)構(gòu)本質(zhì)上要短小、再短小，以不容納if/else if/else嵌套結(jié)構(gòu)為目標(biāo)

二、只做一件事：正如前面所說，函數(shù)只做好一件事就足夠了，標(biāo)志就是“看是否還能拆出一個(gè)函數(shù)，該函數(shù)不僅只是單純地重新詮釋其實(shí)現(xiàn)”

三、每個(gè)函數(shù)一個(gè)抽象層級：代碼一般是“自頂向下”的閱讀順序，每個(gè)函數(shù)后面跟著的應(yīng)該是下一抽象層級的函數(shù)

[抽象層級：getHtml函數(shù)位于較高抽象層，pagePathName = pathParser.render(pagePath)位于中間抽象層，.append(" ")則位于較低抽象層]

四、switch語句：天生就需要做N件事，但是可以將其放置在較低抽象層級，但是當(dāng)出現(xiàn)新的類型時(shí)會(huì)違反“單一權(quán)責(zé)原則、開放閉合原則”，此時(shí)最好創(chuàng)建多態(tài)對象

//原文中：對于每個(gè)case分支進(jìn)行單獨(dú)處理，添加新類型不必修改原來的代碼增加新的處理類即可
functiongetName(name){
switch(name){
case'ming':
returnnewClassMing(name);
case'hu':
returnnewClassHu(name);
case'uzi':
returnnewClassUzi(name);
default:
thrownewClassCommon(name);
}
}

//我更喜歡用另一種方法：修改只需要在對象里修改即可，且提高了函數(shù)的簡潔性
constnameCollectionUtils={
 ming：newClassMing('ming');
hu:newClassHu('hu');
uzi:newClassUzi('uzi');
}
functiongetName(name){
returnnameCollectionUtils.hasOwn(name)?nameCollectionUtils[name]:newClassCommon(name)
}

五、函數(shù)參數(shù)最多不多于兩個(gè)：包括輸入?yún)?shù)和輸出參數(shù)

六、無副作用：函數(shù)內(nèi)部不要做出未能預(yù)期的改動(dòng)，不要對外部產(chǎn)生影響

七、使用異常替代返回錯(cuò)誤碼：使用try...catch替代多層級的if嵌套，永遠(yuǎn)走在主路上，不要過多考慮邊界，這樣可以讓你一直保持思維連貫

八、錯(cuò)誤處理單獨(dú)抽出：這一條我認(rèn)為可以視情況而定，畢竟抽出僅僅是為了美觀

九、別重復(fù)：多個(gè)函數(shù)使用的相同邏輯的代碼一定要抽出，可以參考面向?qū)ο蟮幕?，前端開發(fā)中的面向組件編程、面向模塊編程也是這種思想

注釋&格式

每個(gè)人有每個(gè)人的習(xí)慣，采取一些通用準(zhǔn)則即可，畢竟如何太過離譜在公司是會(huì)挨打的~

錯(cuò)誤處理

也沒有什么固定的章程，最好采取try...catch優(yōu)先的原則

邊界

總結(jié)而言，使用自己可以控制的代碼

單元測試

現(xiàn)在的互聯(lián)網(wǎng)企業(yè)絕大多數(shù)都是敏捷式開發(fā)，很少有能遵守測試驅(qū)動(dòng)原則的公司，而且為了保證進(jìn)度很少會(huì)有技術(shù)團(tuán)隊(duì)會(huì)去要求單元測試，所以這一條仁者見仁吧，個(gè)人認(rèn)為這一項(xiàng)的實(shí)際實(shí)現(xiàn)只能是一個(gè)比較美好的愿景。

類

一、類的組織：按照下面的順序，不要暴露出內(nèi)部屬性，利用方法達(dá)到同樣的目的

classDemoOrganization{
staticsname='sname'
privatepname='pname'
private_pname='_pname'
protectedtname='tname'

publicgetPublicName(){
returnthis.pname
}
private_getPrivateName(){
returnthis._pname
}
}

二、單一權(quán)責(zé)原則（SPR）：類或模塊應(yīng)有且只有一條加以修改的理由，實(shí)現(xiàn)了這個(gè)原則的類更易得到復(fù)用

三、保持內(nèi)聚性：類中定義的變量應(yīng)被盡可能多的方法使用到，如果不能滿足的話就把使用到變量的函數(shù)拆分成小類

四、開放封閉原則（OCP）：類應(yīng)當(dāng)對擴(kuò)展開放，對修改封閉，通過子類化手段可以實(shí)現(xiàn)新功能的添加的同時(shí)不觸及其他類

五、依賴倒置原則（DIP）：類應(yīng)當(dāng)依賴于抽象而不是依賴于具體細(xì)節(jié)

六、解耦：不同方法和模塊間不要互相產(chǎn)生影響，即“分而治之”、“化整為零”

系統(tǒng)

一、構(gòu)造和使用分開：構(gòu)造的細(xì)節(jié)應(yīng)隔離與應(yīng)用程序代碼之外，使用者只能獲取構(gòu)造者想讓使用者獲得的東西

二、設(shè)計(jì)時(shí)要能滿足從簡單到復(fù)雜的更新迭代

迭進(jìn)

總結(jié)上述，只要遵守以下原則，就可以得到一個(gè)具有良好設(shè)計(jì)的可迭進(jìn)的程序：

運(yùn)行所有測試

不可重復(fù)

表達(dá)了程序員的意圖

盡可能減少類和方法的數(shù)量

以上規(guī)則按重要程度排列

并發(fā)編程

首先要了解“線程”這個(gè)概念：CPU調(diào)度的最小單位，區(qū)別于“進(jìn)程”是資源分配的最小單位。區(qū)別見下方表格：

如果說對象是過程的抽象，那么線程是調(diào)度的抽象

前端使用的js語言是瀏覽器腳本語言，最主要的用途是和用戶互動(dòng)和操作DOM，這決定了js只能是單線程否則會(huì)產(chǎn)生復(fù)雜的同步問題，但是js仍然可以模擬并發(fā)執(zhí)行，具體實(shí)現(xiàn)自行查詢相關(guān)資料

當(dāng)前還沒學(xué)習(xí)到并發(fā)編程的語言，以后碰到再補(bǔ)充學(xué)習(xí)

重構(gòu)

這個(gè)模塊我認(rèn)為是最重要的模塊，甚至比怎么去編寫新的程序更重要，因?yàn)橐粋€(gè)公司的沉積項(xiàng)目的數(shù)量是巨大的，很可能會(huì)對其中幾個(gè)甚至更多進(jìn)行重構(gòu)（還是因?yàn)橹按a寫的太爛無法維護(hù)），所以重構(gòu)中需要注意的點(diǎn)也要有一個(gè)清晰的認(rèn)知。

只需要遵守一條原則：簽入的代碼比簽出的更整潔。

寫在最后

以上是我從前端角度總結(jié)的從這本書中得到的一些收獲，但是每個(gè)人都會(huì)有每個(gè)人自己的理解，所以還是推薦自己去讀一遍這本書，不需要多精細(xì)只要熟悉一下這些概念提出來的場景，相信會(huì)有更大的收獲。

審核編輯：劉清