“代碼素養(yǎng)” “是一種態(tài)度，真正熱愛編程的程序員一定不會(huì)缺失“代碼素養(yǎng)”。我們通常稱“寫代碼”為“程序設(shè)計(jì)”，而不是“程序編寫”，“設(shè)計(jì)”一詞體現(xiàn)出了我們的代碼是一件作品，也許不如“藝術(shù)品”那么精致，但也不是什么粗麻爛布，如果在寫代碼時(shí)天馬行空，得過且過，抱著只要能實(shí)現(xiàn)功能的思想，那這部“作品“是不具有觀賞價(jià)值的，這不僅僅體現(xiàn)出代碼編寫者的”不專業(yè)”，更是反映出對(duì)待編程這件事的態(tài)度。每個(gè)程序員不一定熱愛編程，但請(qǐng)你一定要以“認(rèn)真”的態(tài)度對(duì)待自己的專業(yè)。
 1. DRY（Don't Repeat Yourself）
    相信作為一名軟件工程師，大家都聽說過最基本的DRY原則，很多設(shè)計(jì)模式，包括面向?qū)ο蟊旧恚际窃谶@條原則上做努力。
    DRY顧名思義，是指“不要重復(fù)自己”，它實(shí)際上強(qiáng)調(diào)了一個(gè)抽象性原則，如果同樣或類似的代碼片段出現(xiàn)了兩次以上，那么應(yīng)該將它抽象成一個(gè)通用方法或文件，在需要使用的地方去依賴引入，確保在改動(dòng)的時(shí)候，只需調(diào)整一處，所有的地方都改變過來，而不是到每個(gè)地方去找到相應(yīng)的代碼來修改。
    在實(shí)際工作中，我見過兩種在這條原則上各自走向極端的代碼：
    一種是完全沒有抽象概念，重復(fù)的代碼散落在各處，更奇葩的是，有一部分的抽象，但更多的是重復(fù)，比如在common下抽取了一個(gè)data.js的數(shù)據(jù)處理文件，部分頁面中引用了該文件，而更多頁面完全拷貝了該文件中的幾個(gè)不同方法代碼。而作者的意圖則是令人啼笑皆非——只用到小部分代碼，沒必要引入那么整個(gè)文件。且不論現(xiàn)代化的前端構(gòu)建層面可以解決這個(gè)問題，即使是引入了整個(gè)大文件，這部分多余的代碼在gzip之后也不會(huì)損失多少性能，但這種到處copy的行為帶來后續(xù)的維護(hù)成本是翻倍的。
    對(duì)于這種行為還遇到另外一個(gè)理由，就是工期時(shí)間短，改不動(dòng)之前的代碼，怕造成外網(wǎng)問題，那就拷貝一份相同的邏輯來修改。比如支付邏輯，原有的邏輯為單獨(dú)的UI浮層+單個(gè)支付購買，現(xiàn)在產(chǎn)品提出“打包購買”需求，原有的代碼邏輯又比較復(fù)雜，出現(xiàn)了“改不動(dòng)”的現(xiàn)象，于是把UI層和購買邏輯的幾個(gè)文件整個(gè)拷貝過來，修改幾下，形成了新的“打包購買”模塊，后來產(chǎn)品又提出“按條購買”，按照上述”改不動(dòng)“原則，又拷貝了一份“按條購買”的模塊。這樣一來調(diào)用處的邏輯就會(huì)冗余重復(fù)，需要根據(jù)不同的購買方式引入不同UI組件和支付邏輯，另外如果新添需求，如支持“分期付款”，那么將改動(dòng)的是非常多的文件，最可悲的是，最后想要把代碼重構(gòu)為一處統(tǒng)一調(diào)用的人，將會(huì)面對(duì)三份“改不動(dòng)”的壓力，需要眾多邏輯中對(duì)比分析提取相同之處，工作量已經(jīng)不能用翻倍來衡量，而這種工作量往往無法得到產(chǎn)品的認(rèn)同和理解。
    另一種極端是過度設(shè)計(jì)，在寫每個(gè)邏輯的時(shí)候都去抽象，讓代碼的可讀性大大下降，一個(gè)簡單的for循環(huán)都要復(fù)用，甚至變量定義，這種代碼維護(hù)起來也是比較有成本的，還有將迥然不同的邏輯過度抽象，使得抽象方法變得非常復(fù)雜，經(jīng)常“牽一發(fā)而動(dòng)全身”，這種行為也是不可取的。
    這也是將該原則排在首位的原因，這種行為導(dǎo)致的重構(gòu)工作量是大的，保持良好的代碼維護(hù)性是一種素養(yǎng)，更是一種責(zé)任，如果自己在這方面逃避或偷懶，將把這塊工作量翻倍地加在將來別人或自己的身上。
  2. SRP（Single Responsibility Principle）
    SRP也是一個(gè)比較著名的設(shè)計(jì)原則——單一職責(zé)，在面向?qū)ο蟮木幊讨校J(rèn)為類應(yīng)該具有單一職責(zé)，一個(gè)類的改變動(dòng)機(jī)應(yīng)當(dāng)只有一個(gè)。
    對(duì)于前端開發(fā)來說，最需要貫徹的思想是函數(shù)應(yīng)當(dāng)保持單一職責(zé)，一個(gè)函數(shù)應(yīng)當(dāng)只做一件事，這樣一來是保證函數(shù)的可復(fù)用性，更單一的函數(shù)有更強(qiáng)的復(fù)用性，二來可以讓整體的代碼框架更加清晰，細(xì)節(jié)都封裝在一個(gè)個(gè)小函數(shù)中。另外一點(diǎn)也和單一職責(zé)有關(guān)，就是無副作用的函數(shù)，也稱純函數(shù)，我們應(yīng)當(dāng)盡量保證純函數(shù)的數(shù)量，非純函數(shù)是不可避免的，但應(yīng)當(dāng)盡量減少它。
    把SRP原則排在第二位，因?yàn)樗浅５闹匾瑳]有人愿意看一團(tuán)亂麻的邏輯，在維護(hù)代碼時(shí)，如果沒有一個(gè)清晰的邏輯結(jié)構(gòu)，所有的數(shù)據(jù)定義、數(shù)據(jù)處理、DOM操作等等一系列細(xì)節(jié)的代碼全部放在一個(gè)函數(shù)中，導(dǎo)致這個(gè)函數(shù)非常的冗長，讓人本能地產(chǎn)生心理排斥，不愿去查看內(nèi)部的邏輯。
     所有的復(fù)雜邏輯放在一個(gè)函數(shù)中，大家看到這樣的代碼一定會(huì)很頭疼。
    單一職責(zé)并不一定要通過很多函數(shù)來完成，也可以用分段達(dá)到目的，如同這樣：
      雖然這個(gè)函數(shù)也沒有維持單一職責(zé)，但通過“分段”的形式清晰的表明了內(nèi)部的流程邏輯，這樣的代碼看起來就會(huì)比所有細(xì)節(jié)揉在一個(gè)函數(shù)中好很多。
    對(duì)于單一職責(zé)來說，保持起來還是比較困難的，主要在于職責(zé)的拆分，有時(shí)過于細(xì)致的職責(zé)拆分也會(huì)給閱讀帶來比較大的困難，對(duì)于這種情況，還是拿寫作來對(duì)比，單一職責(zé)相當(dāng)于文章的一個(gè)“段落”，對(duì)于文章來說，每個(gè)段落都有它的中心思想，可以用一句話描述出來，如果你發(fā)現(xiàn)函數(shù)的中心思想很模糊，或者需要很多語言去描述它，那也許它已經(jīng)有很多個(gè)職責(zé)該拆分了。
3. LKP(Least Knowledge Principle)
    LKP原則是最小知識(shí)原則，又稱“迪米特”法則，也就是說，一個(gè)對(duì)象應(yīng)該對(duì)另一個(gè)對(duì)象有最少的了解，你內(nèi)部如何復(fù)雜都沒關(guān)系，我只關(guān)心調(diào)用的地方。
保持暴露接口的簡介易用性也是API設(shè)計(jì)的通用規(guī)則，在實(shí)際中發(fā)現(xiàn)了這樣的一個(gè)UI組件：
      這個(gè)UI組件暴露了非常多的方法，有業(yè)務(wù)邏輯，有視圖邏輯，還有工具方法，這時(shí)會(huì)給維護(hù)者帶來比較大的困擾，本能的以為這些暴露出去的方法都在被使用，所以想重構(gòu)其中某些方法都有些不好下手，而實(shí)際上，外部調(diào)用的方法僅僅是show而已。

分享文章：網(wǎng)站開發(fā)代碼的三條維護(hù)性原則
標(biāo)題URL：http://m.kartarina.com/news/113200.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、品牌網(wǎng)站制作、網(wǎng)站設(shè)計(jì)公司、做網(wǎng)站、關(guān)鍵詞優(yōu)化、云服務(wù)器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)