您好,登錄后才能下訂單哦!
這篇文章主要介紹“web開發中怎么維護代碼”,在日常操作中,相信很多人在web開發中怎么維護代碼問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”web開發中怎么維護代碼”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
今天我們不聊性能優化,只是從后期維護代碼的角度談談如何優雅的書寫代碼
為什么需要些可維護性高的代碼 ?
在開發的過程中,迭代和維護是再正常不過的操作了
那么就必然要閱讀別人的代碼
你有沒有遇到過一些尷尬的事情:
1、看不懂別人的代碼,不知從何下手
2、修改一個功能,得讀兩天代碼,改完發現 bug 最少的時候是修改以前
3、只是修改了一行代碼,發現控制臺報錯好幾十個
...
如果代碼的可維護性高了,那么可以避免很多這些問題
編寫可維護性高的代碼, 從我做起 ^_^
什么是可維護性高的代碼 ?
容易理解: 不需要求助源代碼書寫人員,就能看得懂
符合常識: 代碼書寫的自然通透
容易適配: 當數據發生變化的時候,不至于完全重寫
容易擴展: 對于核心功能有可擴展性(適當利用策略模式)
容易調試: 當出現問題的時候,能給出明確且詳細的錯誤提示,可以直接定位問題源
想要好維護, 那么第一任務就是你寫的代碼要讓別人看得懂
因為我們的代碼,當他不運行的時候,就是一個純文本
想要讓別人看得懂你寫的一堆文本,那么就要從一切自定義的內容開始做起
能區分是論文還是代碼的第一因素,也是最直觀的因素就是代碼縮進
代碼沒有縮進,或者隨機縮進,那么和給你看一篇火星文論文沒有區別
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++) {
}
}
}
整整齊齊的就是看不懂
我們嚴格保持了代碼縮進以后, 雖然代碼意義不一定看得懂, 但是代碼結構我能看得懂了
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++) {
}
}
}
這個時候就可以嘗試下改一改了
在任何一個語言里面,都是有注釋的
語言規范里定義注釋,不是為了讓你學了玩的,就是為了讓你對代碼進行一些標注的
大型代碼塊,和大量變量堆積的地方,都要有清楚的注釋,用來表明這個代碼塊或者說這一堆變量是干什么用的,尤其是函數,盡量做到每一個函數的前面都有一個說明注釋。
/*
* fn 獲取范圍之間隨機整數的函數
* @param {Number} a 范圍開始的數字
* @param {Number} b 范圍結束的數字
* @return {Number} 范圍內的隨機整數
*/
function fn(a, b) { ... }
每一個函數都應該有參數說明,是否有返回值,返回值是什么
因為這些內容在函數定義中是不能直觀看到了,需要閱讀代碼才可以
當你寫明了這些以后,閱讀性就大大提高了
假設,你的函數塊里面涉及到很復雜的算法,最好也是在說明注釋里面標注出來
當你對于一些瀏覽器問題做出的修復,你使用了一些黑科技
那么你一定要把這些黑科技標注出來,避免別人修改你的代碼的時候
覺得這些黑科技沒有用,給你刪掉了,導致你修改好的問題又重新出現了
變量的命名和函數的命名,是最能體現我們自定義的地方
對于每一個變量和函數的命名,我們都盡量準確的給到一個語義,不管你是使用 大駝峰 還是 小駝峰,都要保證看到名字就能知道這個變量或者函數的意義
從變量來說
1、盡量使用名詞,而不是動詞
比如:car / person / show / ...
2、常量來說,要使用大寫字母來表示
比如:TEST / BROWSER / ...
3、區分全局和私有變量,函數內的私有變量我會以 _ 開頭
比如: _this / ...
從函數來說
1、當函數返回布爾值的時候, 一般會以 is 開頭
比如:isEnabled() / isSelected() / ...
2、獲取類的函數一般以 get 開頭
比如:getUserList() / getUserInfo() / ...
3、設置類的一般使用 set 開頭
比如:setName() / setUserInfo() / ...
4、修改類的一般使用 update 開頭
比如:updateName() / updatePrice() / ...
4、程序處理類函數使用 handler 結尾
比如:showEditHandler() / submitHandler() / ...
5、盡可能的通過名字描述清楚函數的作用,不用擔心太長,因為后期打包工具會幫我們處理掉的
比如: getUserInfoById() / delGoodsParamsById() / ...
因為 JS 是一個弱類型語言,在定義變量的時候,不會限制數據類型
但是我們在給變量賦值的時候,也要盡可能的做到數據類型統一
當你需要定義一些變量,在后期操作中進行賦值的時候
盡可能在定義的時候,給一個初始值表示一下你變量將來要存儲的數據類型
比如:
var count = 0;
var name = '';
var boo = false;
var person = null;
var todoList = [ ];
如果你實在不想給一個初始值
也可以使用注釋的形式表明一下你定義的變量, 將來存儲的是什么類型的數據
var count /* Number */;
var name /* String */;
var boo /* Boolean */;
我們要保證一個良好的代碼書寫習慣
我們來看一下下面這個代碼
[ ... ].map(function () {
// code ...
}).filter(function () {
// code ...
}).reduce(function () {
// code ...
})
其實沒啥問題, 而且也挺好的
更甚至當代碼簡單一些的時候有人把它寫成一行
[ ... ].map(function () { ... }).filter(function () { ... }).reduce(function () { ... })
但是到了后期修改的時候,問題就會逐步顯示,一旦修改了第一個,那么后面的都有可能會出現問題
而且當代碼量過大的時候,很難保證你不修改串行了
我們可以把上面的代碼換成下面的方式
[ ... ]
.map(function () {
// code ...
})
.filter(function () {
// code ...
})
.reduce(function () {
// code ...
})
這樣的話,看起來會舒服的多
而且可以利用編輯器的代碼折疊,一個函數一個函數的來書寫
很多人喜歡相對緊湊的書寫結構
比如下面的代碼
if (year%4===0&&year%100!==0||year%400===0) { ... }
很簡單的一個判斷閏年的代碼
但是當你的運算符很緊湊的時候,那么看起來就會比較費眼睛
相對來說,我更喜歡在運算符兩邊都加上空格
讓結構相對松散一些,看起來可能也容易一些
我們也不用擔心這些空格,后期處理都會幫我們處理掉的
if ( year % 4 === 0 && year % 100 !== 0 || year % 400 === 0) { ... }
還有一種寫法
if (
year % 4 === 0 &&
year % 100 !== 0 ||
year % 400 === 0
) { ... }
這個適用于條件比較長的時候使用看起來會更加清晰一些
當調用一個函數,需要傳遞一個函數作為參數的時候
我們通常都會直接書寫一個匿名函數或者箭頭函數在參數位置
或者說傳遞一個復雜數據類型作為參數的時候,都會直接講對應的數組或者對象寫在參數位置
比如下面這段代碼
$.get('/xxx', {
a: 100,
b: 200
}, function (res) {
// code ...
}, 'json')
代碼沒有問題,但是一旦對象中數據過多或者函數中代碼過多的時候后期看起來就會很復雜
我會建議把這些內容單獨書寫出來
var params = {
a: 100,
b: 200
}
function success(res) {
// code ...
}
$.get('/xxx', params, success, 'json')
這樣一來, 不管是修改, 還是增加一些內容, 都會比較方便了
把我們自定義的一些功能性函數進行單獨的封裝,放在一個單獨的 JS 文件中進行引入或者導入使用,其實就是模塊化的概念
對于比較難以閱讀的代碼來說,強耦合的代碼是最難閱讀的,JS 代碼本身層面上的耦合我們就不說了,大家都應該了解面向對象編程和模塊化編程
在前端開發中,我們經常會見到有些人寫代碼會把一些簡單的事件直接寫到 html 結構上
<button >
到此,關于“web開發中怎么維護代碼”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。