網(wǎng)站開發(fā)代碼的三條維護(hù)性原則

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

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

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

廣告

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