免费观看又色又爽又黄的小说免费_美女福利视频国产片_亚洲欧美精品_美国一级大黄大色毛片

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

2021-05-11    分類: 網(wǎng)站建設(shè)

“代碼素養(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è)簡(jiǎn)單的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)樗浅5闹匾瑳]有人愿意看一團(tuán)亂麻的邏輯,在維護(hù)代碼時(shí),如果沒有一個(gè)清晰的邏輯結(jié)構(gòu),所有的數(shù)據(jù)定義、數(shù)據(jù)處理、DOM操作等等一系列細(xì)節(jié)的代碼全部放在一個(gè)函數(shù)中,導(dǎo)致這個(gè)函數(shù)非常的冗長(zhǎng),讓人本能地產(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)用的地方。
保持暴露接口的簡(jiǎn)介易用性也是API設(shè)計(jì)的通用規(guī)則,在實(shí)際中發(fā)現(xiàn)了這樣的一個(gè)UI組件:
代碼片段
      這個(gè)UI組件暴露了非常多的方法,有業(yè)務(wù)邏輯,有視圖邏輯,還有工具方法,這時(shí)會(huì)給維護(hù)者帶來比較大的困擾,本能的以為這些暴露出去的方法都在被使用,所以想重構(gòu)其中某些方法都有些不好下手,而實(shí)際上,外部調(diào)用的方法僅僅是show而已。
    一個(gè)好的封裝,無論內(nèi)部多么復(fù)雜,它暴露出來的一定是最簡(jiǎn)潔實(shí)用的接口,而內(nèi)部邏輯是獨(dú)立維護(hù)的,如上述代碼,作為一個(gè)UI組件來說,提供最基本的show/hide方法即可,有必要時(shí)可加入update方法自更新,而無需暴露眾多細(xì)節(jié),造成調(diào)用者和維護(hù)者的困擾。

網(wǎng)站欄目:網(wǎng)站開發(fā)代碼的三條維護(hù)性原則
網(wǎng)址分享:http://m.newbst.com/news0/113200.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供軟件開發(fā)電子商務(wù)網(wǎng)站建設(shè)服務(wù)器托管網(wǎng)站內(nèi)鏈品牌網(wǎng)站制作

廣告

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

搜索引擎優(yōu)化