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

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

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

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

廣告

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