什么是可維護(hù)性的代碼
今天我們不聊性能優(yōu)化,只是從后期維護(hù)代碼的角度談?wù)勅绾蝺?yōu)雅的書寫代碼
- 為什么需要些可維護(hù)性高的代碼 ?
在開發(fā)的過程中,迭代和維護(hù)是再正常不過的操作了
那么就必然要閱讀別人的代碼
你有沒有遇到過一些尷尬的事情:
1忠聚、看不懂別人的代碼诬像,不知從何下手
2、修改一個(gè)功能孵构,得讀兩天代碼,改完發(fā)現(xiàn) bug 最少的時(shí)候是修改以前
3、只是修改了一行代碼累榜,發(fā)現(xiàn)控制臺報(bào)錯(cuò)好幾十個(gè)
...
如果代碼的可維護(hù)性高了,那么可以避免很多這些問題
編寫可維護(hù)性高的代碼, 從我做起 _
- 什么是可維護(hù)性高的代碼 ?
容易理解: 不需要求助源代碼書寫人員,就能看得懂
符合常識: 代碼書寫的自然通透
容易適配: 當(dāng)數(shù)據(jù)發(fā)生變化的時(shí)候壹罚,不至于完全重寫
容易擴(kuò)展: 對于核心功能有可擴(kuò)展性(適當(dāng)利用策略模式)
容易調(diào)試: 當(dāng)出現(xiàn)問題的時(shí)候葛作,能給出明確且詳細(xì)的錯(cuò)誤提示,可以直接定位問題源
從下面幾點(diǎn)做起:
一猖凛、代碼可讀性
- 想要好維護(hù), 那么第一任務(wù)就是你寫的代碼要讓別人看得懂
- 因?yàn)槲覀兊拇a赂蠢,當(dāng)他不運(yùn)行的時(shí)候,就是一個(gè)純文本
- 想要讓別人看得懂你寫的一堆文本辨泳,那么就要從一切自定義的內(nèi)容開始做起
二虱岂、代碼縮進(jìn)
- 能區(qū)分是論文還是代碼的第一因素,也是最直觀的因素就是代碼縮進(jìn)
- 代碼沒有縮進(jìn)菠红,或者隨機(jī)縮進(jìn)第岖,那么和給你看一篇火星文論文沒有區(qū)別
for (var i = 0; i < 100; i++) {
if (true) {
function fn() {
for (var j = 0; j < 100; j++) {
}
}
for (var j = 0; j < 100; j++) {
}
}
}
<figcaption style="margin-top: 0.66667em; padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">整整齊齊的就是看不懂</figcaption>
- 我們嚴(yán)格保持了代碼縮進(jìn)以后, 雖然代碼意義不一定看得懂, 但是代碼結(jié)構(gòu)我能看得懂了
for (var i = 0; i < 100; i++) {
if (true) {
function fn() {
for (var j = 0; j < 100; j++) {
}
}
for (var j = 0; j < 100; j++) {
}
}
}
- 這個(gè)時(shí)候就可以嘗試下改一改了
三、注釋
在任何一個(gè)語言里面试溯,都是有注釋的
語言規(guī)范里定義注釋蔑滓,不是為了讓你學(xué)了玩的,就是為了讓你對代碼進(jìn)行一些標(biāo)注的
大型代碼塊遇绞,和大量變量堆積的地方烫饼,都要有清楚的注釋,用來表明這個(gè)代碼塊或者說這一堆變量是干什么用的试读,尤其是函數(shù)杠纵,盡量做到每一個(gè)函數(shù)的前面都有一個(gè)說明注釋。
/*
* fn 獲取范圍之間隨機(jī)整數(shù)的函數(shù)
* @param {Number} a 范圍開始的數(shù)字
* @param {Number} b 范圍結(jié)束的數(shù)字
* @return {Number} 范圍內(nèi)的隨機(jī)整數(shù)
*/
function fn(a, b) { ... }
- 每一個(gè)函數(shù)都應(yīng)該有參數(shù)說明钩骇,是否有返回值比藻,返回值是什么
- 因?yàn)檫@些內(nèi)容在函數(shù)定義中是不能直觀看到了,需要閱讀代碼才可以
- 當(dāng)你寫明了這些以后倘屹,閱讀性就大大提高了
- 假設(shè)银亲,你的函數(shù)塊里面涉及到很復(fù)雜的算法,最好也是在說明注釋里面標(biāo)注出來
當(dāng)你對于一些瀏覽器問題做出的修復(fù)纽匙,你使用了一些黑科技
- 那么你一定要把這些黑科技標(biāo)注出來务蝠,避免別人修改你的代碼的時(shí)候
- 覺得這些黑科技沒有用,給你刪掉了烛缔,導(dǎo)致你修改好的問題又重新出現(xiàn)了
四馏段、變量和函數(shù)命名
變量的命名和函數(shù)的命名,是最能體現(xiàn)我們自定義的地方
對于每一個(gè)變量和函數(shù)的命名践瓷,我們都盡量準(zhǔn)確的給到一個(gè)語義院喜,不管你是使用 大駝峰 還是 小駝峰,都要保證看到名字就能知道這個(gè)變量或者函數(shù)的意義
從變量來說
1晕翠、盡量使用名詞喷舀,而不是動(dòng)詞
比如:car / person / show / ...
2、常量來說,要使用大寫字母來表示
比如:TEST / BROWSER / ...
3硫麻、區(qū)分全局和私有變量爸邢,函數(shù)內(nèi)的私有變量我會以 _ 開頭
比如: _this / ...
從函數(shù)來說
1、當(dāng)函數(shù)返回布爾值的時(shí)候, 一般會以 is 開頭
比如:isEnabled() / isSelected() / ...
2拿愧、獲取類的函數(shù)一般以 get 開頭
比如:getUserList() / getUserInfo() / ...
3甲棍、設(shè)置類的一般使用 set 開頭
比如:setName() / setUserInfo() / ...
4、修改類的一般使用 update 開頭
比如:updateName() / updatePrice() / ...
4赶掖、程序處理類函數(shù)使用 handler 結(jié)尾
比如:showEditHandler() / submitHandler() / ...
5、盡可能的通過名字描述清楚函數(shù)的作用七扰,不用擔(dān)心太長奢赂,因?yàn)楹笃诖虬ぞ邥臀覀兲幚淼舻?/p>
比如: getUserInfoById() / delGoodsParamsById() / ...
五、變量類型透明化
因?yàn)?JS
是一個(gè)弱類型語言颈走,在定義變量的時(shí)候膳灶,不會限制數(shù)據(jù)類型
但是我們在給變量賦值的時(shí)候,也要盡可能的做到數(shù)據(jù)類型統(tǒng)一
當(dāng)你需要定義一些變量立由,在后期操作中進(jìn)行賦值的時(shí)候
盡可能在定義的時(shí)候轧钓,給一個(gè)初始值表示一下你變量將來要存儲的數(shù)據(jù)類型
比如:
var count = 0;
var name = '';
var boo = false;
var person = null;
var todoList = [ ];
如果你實(shí)在不想給一個(gè)初始值
也可以使用注釋的形式表明一下你定義的變量, 將來存儲的是什么類型的數(shù)據(jù)
var count /* Number /;
var name / String /;
var boo / Boolean */;
六、代碼書寫習(xí)慣
我們要保證一個(gè)良好的代碼書寫習(xí)慣
七锐膜、鏈?zhǔn)骄幊痰牧?xí)慣
我們來看一下下面這個(gè)代碼
[ ... ].map(function () {
// code ...
}).filter(function () {
// code ...
}).reduce(function () {
// code ...
})
其實(shí)沒啥問題, 而且也挺好的
更甚至當(dāng)代碼簡單一些的時(shí)候有人把它寫成一行
[ ... ].map(function () { ... }).filter(function () { ... }).reduce(function () { ... })
但是到了后期修改的時(shí)候毕箍,問題就會逐步顯示,一旦修改了第一個(gè)道盏,那么后面的都有可能會出現(xiàn)問題
而且當(dāng)代碼量過大的時(shí)候而柑,很難保證你不修改串行了
- 我們可以把上面的代碼換成下面的方式
[ ... ]
.map(function () {
// code ...
})
.filter(function () {
// code ...
})
.reduce(function () {
// code ...
})
這樣的話,看起來會舒服的多
而且可以利用編輯器的代碼折疊荷逞,一個(gè)函數(shù)一個(gè)函數(shù)的來書寫
八媒咳、書寫運(yùn)算符的習(xí)慣
很多人喜歡相對緊湊的書寫結(jié)構(gòu)
比如下面的代碼
if (year%4===0&&year%100!==0||year%400===0) { ... }
很簡單的一個(gè)判斷閏年的代碼
但是當(dāng)你的運(yùn)算符很緊湊的時(shí)候,那么看起來就會比較費(fèi)眼睛
相對來說种远,我更喜歡在運(yùn)算符兩邊都加上空格
讓結(jié)構(gòu)相對松散一些涩澡,看起來可能也容易一些
我們也不用擔(dān)心這些空格,后期處理都會幫我們處理掉的
if ( year % 4 === 0 && year % 100 !== 0 || year % 400 === 0) { ... }
還有一種寫法
if (
year % 4 === 0 &&
year % 100 !== 0 ||
year % 400 === 0
) { ... }
這個(gè)適用于條件比較長的時(shí)候使用
看起來會更加清晰一些
九坠敷、函數(shù)調(diào)用傳遞參數(shù)
- 當(dāng)調(diào)用一個(gè)函數(shù)妙同,需要傳遞一個(gè)函數(shù)作為參數(shù)的時(shí)候
- 我們通常都會直接書寫一個(gè)匿名函數(shù)或者箭頭函數(shù)在參數(shù)位置
- 或者說傳遞一個(gè)復(fù)雜數(shù)據(jù)類型作為參數(shù)的時(shí)候,都會直接講對應(yīng)的數(shù)組或者對象寫在參數(shù)位置
- 比如下面這段代碼
$.get('/xxx', {
a: 100,
b: 200
}, function (res) {
// code ...
}, 'json')
代碼沒有問題膝迎,但是一旦對象中數(shù)據(jù)過多
或者函數(shù)中代碼過多的時(shí)候
后期看起來就會很復(fù)雜
我會建議把這些內(nèi)容單獨(dú)書寫出來
var params = {
a: 100,
b: 200
}
function success(res) {
// code ...
}
$.get('/xxx', params, success, 'json')
這樣一來, 不管是修改, 還是增加一些內(nèi)容, 都會比較方便了
十渐溶、功能性函數(shù)的單獨(dú)封裝
把我們自定義的一些功能性函數(shù)進(jìn)行單獨(dú)的封裝,放在一個(gè)單獨(dú)的 JS 文件中進(jìn)行引入或者導(dǎo)入使用弄抬,其實(shí)就是模塊化的概念
十一茎辐、松散耦合
對于比較難以閱讀的代碼來說,強(qiáng)耦合的代碼是最難閱讀的,JS
代碼本身層面上的耦合我們就不說了拖陆,大家都應(yīng)該了解面向?qū)ο缶幊毯湍K化編程
十二弛槐、HTML 和 JavaScript 的耦合
在前端開發(fā)中,我們經(jīng)常會見到有些人寫代碼會把一些簡單的事件直接寫到 html
結(jié)構(gòu)上
<button onclick="doSomething()" ></button>
從代碼層面上來說完全沒有問題
但是實(shí)際上依啰,這個(gè)是 HTML 和 JavaScript 的強(qiáng)耦合現(xiàn)象
第一: 每次對于代碼進(jìn)行的修改乎串,都要從 HTML 和 JavaScript 兩個(gè)位置去進(jìn)行修改
第二: 代碼引入位置不可變,一定要保證在用戶點(diǎn)擊之前就已經(jīng)有函數(shù)存在了速警,不然一定會報(bào)錯(cuò)的
比較好的方法就是進(jìn)行 HTML
和 JavaScript
的分離
在
.js
文件中獲取 DOM 元素
通過事件綁定的形式來完成操作
var btn = document.querySelector('button')
btn.addEventListener('click', doSomething)
還有一種情況更常見, 就是在 JS
代碼中為了渲染頁面而進(jìn)行字符串拼接
container.innerHTML = `
<div>
...
<p> ... </p>
<span> ... </span>
</div>
`
這個(gè)代碼也是完全沒有問題的叹誉,而且大部分同學(xué)都會這樣書寫代碼,因?yàn)槭r(shí)省力
但是這樣的情況闷旧,一旦渲染到頁面上长豁,出現(xiàn)樣式問題需要調(diào)整的時(shí)候
我們在 HTML 結(jié)構(gòu)中很難找到內(nèi)容來修改,必須要到 JavaScript 代碼里面去修改
如果我們的字符串拼接是在循環(huán)里面完成的話忙灼,那么有可能你添加一個(gè)或者刪除一個(gè)標(biāo)簽的時(shí)候匠襟,導(dǎo)致整個(gè)頁面崩潰
比較好的做法
使用一些第三方小腳本或者模板引擎來進(jìn)行渲染:
比如:art-template / e.js / ...
真的需要這樣渲染的時(shí)候,那么在原始html
結(jié)構(gòu)中以注釋的形式留下一部分渲染內(nèi)容
<div class="container">
<!-- 商品詳情信息渲染結(jié)構(gòu)
<div>
...
<p> ... </p>
<span> ... </span>
</div>
-->
</div>
- 當(dāng) HTML 和 JavaScript 解耦以后
- 可以大量節(jié)省我們的排錯(cuò)時(shí)間, 和錯(cuò)誤的準(zhǔn)確定位
十三该园、CSS 和 JavaScript 的耦合
在前端的開發(fā)中酸舍,使用 JS
來操作一些元素的樣式,是在常見不過的事情了
比如我們經(jīng)常會寫
ele.style.color = 'red' ;
ele.style.display = 'none' ;
這樣書寫代碼其實(shí)沒有大問題
對于渲染也不會造成很大的困擾
但是里初,一旦我們需要修改樣式的時(shí)候啃勉,那么就比較麻煩了
因?yàn)橛械臉邮娇赡苄枰?.css
文件內(nèi)修改,有的樣式需要在.js
文件內(nèi)修改
- 比較好的做法是, 把我們需要修改的樣式寫成一個(gè)單獨(dú)類名下
- 放在
.css
文件內(nèi) - 我們在代碼里面通過操作元素的類名來進(jìn)行修改
ele.classList.add('active')
ele.classList.remove('active')
這樣做保證了樣式和行為的分離双妨,我們在調(diào)整頁面樣式的時(shí)候璧亮,不需要 JS,直接在 CSS 中修改就可以
十四斥难、事件處理 和 應(yīng)用邏輯 的耦合
在開發(fā)過程中, 我們經(jīng)常要處理一些事件枝嘶,并且在事件里面要進(jìn)行一些邏輯的運(yùn)算
比如:我們在點(diǎn)擊登錄的時(shí)候,要對用戶填寫的內(nèi)容進(jìn)行一個(gè)正則的驗(yàn)證哑诊,然后提交到服務(wù)器
ele.addEventListener('submit', function () {
let username = xxx.value
let password = xxx.value
// 正則驗(yàn)證
if ( ... ) { ... }
if ( ... ) { ... }
// 提交到服務(wù)器
var xhr = new XMLHttpRequest()
xhr.open( ... )
xhr.send( ... )
xhr.onload = function () { ... }
})
這是一段合法的代碼
但是函數(shù)里面包含了太多的內(nèi)容
有事件處理
有邏輯處理
有請求發(fā)送
這樣就相當(dāng)于在一個(gè)函數(shù)里面做了太多的事情
這個(gè)代碼的邏輯運(yùn)算還是比較少的群扶,但是一旦邏輯運(yùn)算多了以后,那么后期閱讀的時(shí)候就很麻煩了
我們可以把里面的邏輯運(yùn)算和請求發(fā)送都單獨(dú)提取出來镀裤,變成下面這個(gè)形式:
function validateValue(val) {
// 正則驗(yàn)證
if ( ... ) { ... }
if ( ... ) { ... }
// 將驗(yàn)證結(jié)果返回
return true // or false
}
function sendAjax() {
// 發(fā)送請求的業(yè)務(wù)邏輯
}
ele.addEventListener('submit', function () {
let username = xxx.value
let password = xxx.value
// 正則驗(yàn)證
if (!validateValue( xxx )) return
// 提交到服務(wù)器
sendAjax()
})
這樣一來竞阐,只要我們給函數(shù)寫好注釋,那么后期的時(shí)候暑劝,哪里出現(xiàn)問題骆莹,我們可以快速準(zhǔn)確的定位問題所在位置
十五、尊重對象所有權(quán)
- JavaScript 的動(dòng)態(tài)天性決定了沒有什么是不能修改的
- 從代碼層面出發(fā)担猛,我們可以修改任何內(nèi)容幕垦,包括向 Object 的 prototype 上擴(kuò)展一些方法,丢氢,向 Array 的 prototype 上擴(kuò)展一些方法
- 但是在真實(shí)的企業(yè)級開發(fā)過程中,我們要絕對的尊重每一個(gè)對象的所有權(quán)
不要修改任何不屬于你的代碼先改,如果某一個(gè)對象不是由你負(fù)責(zé)創(chuàng)建或者維護(hù)疚察,那么你也不要修改他的構(gòu)造函數(shù)
在好久好久以前:
我接觸過一個(gè)叫做
prototype
的第三方庫
它里面向 document 對象上擴(kuò)展了一個(gè)叫做getElementsByClassName
的方法
是不是看起來很無聊,但是在沒有getElementsByClassName
的年代仇奶,確實(shí)很好用
并且貌嫡,擴(kuò)展的這個(gè)getElementsByClassName
方法的返回值是一個(gè)Array
并不是我們后來使用的NodeList
而且還在實(shí)例身上擴(kuò)展了一個(gè)叫做each()
的方法,專門用來遍歷
我們用起來的時(shí)候就會很方便
document.getElementsByClassName('item').each()
這個(gè)很好该溯,而且對代碼開發(fā)進(jìn)行了簡化
但是岛抄,一旦瀏覽器廠商開始支持這個(gè)方法了,那么你的方法就會出現(xiàn)問題了
后來狈茉,在所有瀏覽器廠商都支持了getElementsByClassName
以后
當(dāng)在使用這個(gè)方法的時(shí)候夫椭,因?yàn)楹驮闹孛?br> 會出現(xiàn)代碼的大面積報(bào)錯(cuò)
這個(gè)就是尊重代碼所有權(quán)
因?yàn)槟悴恢罏g覽器廠商什么時(shí)候會 告知 或 不告知 的更新一些內(nèi)容,或者修改一些 API
所以论皆,不要修改任何不屬于你的內(nèi)容
十六、盡量不聲明全局變量
和尊重對象所有權(quán)有密切關(guān)系的就是盡可能少的聲明全局變量
拋開變量污染的層面不說猾漫,我們的每一個(gè)全局變量其實(shí)都是在向 window 上添加成員
var name = 'Jack'
function getInfo() { ... }
這都是全局變量点晴,用起來也沒什么問題
但是也確實(shí)是在 window 上掛載了兩個(gè)名字
我們在開發(fā)自己的代碼的時(shí)候, 盡可能的在全局制作一個(gè)命名空間,然后把我們所有需要的內(nèi)容全部放在里面
var myApp = {
name: 'jack',
getInfo () { ... }
}
這樣一來, 我們只是向 window 上掛載了一個(gè) myApp
剩下的所有東西都在我自己的命名空間里面
一旦出現(xiàn)問題悯周,你能準(zhǔn)確的知道是你自己定義的變量或者方法出現(xiàn)了問題粒督,還是原生的變量或者方法出現(xiàn)了問題
這個(gè)也是前端從沒有模塊化到模塊化開發(fā)的演變過程的原始階段:
- 獨(dú)立命名空間
- IIFE
- AMD / CMD
- CommonJS
- ES6 模塊化
十七、習(xí)慣使用常量
我們在開發(fā)的過程中禽翼,經(jīng)常要使用一些變量來操作某些內(nèi)容
- 任何出現(xiàn)一次以上的內(nèi)容屠橄,都應(yīng)該提取出來變成一個(gè)常量的定義
- 任何一個(gè)需要顯示給用戶看到的文本內(nèi)容,都應(yīng)該提取出來變成一個(gè)常量
- 任何一個(gè)變量闰挡,在定義的時(shí)候都要考慮锐墙,將來會不會發(fā)生變化,如果不發(fā)生變化长酗,那么就直接定義成常量
- 包括我們在操作一些類名的時(shí)候溪北,應(yīng)該把這些類名提取出來做成常量,然后統(tǒng)一操作
這樣一來夺脾,我們可以避免因?yàn)椴恍⌒男薷淖兞慷鴮?dǎo)致出現(xiàn)的問題之拨,也可以在代碼的各個(gè)部分保證代碼數(shù)據(jù)的統(tǒng)一,避免一個(gè)東西這里修改了咧叭,那里沒有修改的問題