如何優(yōu)化前端代碼

首先說一個(gè)最重要的優(yōu)化原則：代碼優(yōu)化是每天都要進(jìn)行的，而不是一兩個(gè)月做一次大優(yōu)化，那時(shí)做就已經(jīng)晚了。另外由于優(yōu)化是每天做的，所以你不需要一次的就過度優(yōu)化，保持小步快跑即可。

這個(gè)原則為什么重要？因?yàn)楹芏喑绦騿T會(huì)在寫代碼的時(shí)候說「先不優(yōu)化了，等不忙的時(shí)候再優(yōu)化」，然后……就沒有然后了。

基本上「爛代碼」就是因?yàn)椤覆幻Φ臅r(shí)候再優(yōu)化」造成的。

很多程序員抱怨公司代碼爛，卻從來不去嘗試解決問題。（就像很多程序員抱怨培訓(xùn)班教出來的人水平差，自己卻不寫新人教程一樣）

如果你不想變成上面那樣的程序員，你只堅(jiān)定一個(gè)信念：只要是經(jīng)過我的手的代碼，質(zhì)量就會(huì)比原來好一點(diǎn)。

那么你很快就能把代碼寫好了。你可能急于聽到把代碼寫好的技巧，但是我告訴你，技巧真的不重要，這個(gè)信念才是最重要的。

把一件事情堅(jiān)持的去做好很重要，就像吐槽別人的代碼沒注釋一樣，我們反過來看看自己的代碼是不是也沒有寫注釋呢？如果是那就要從現(xiàn)在開始改變這種壞習(xí)慣了。

雖然我們都一直在關(guān)心如何優(yōu)化代碼，但在前提是要保證自己不要寫爛代碼！沒錯(cuò)，把代碼寫好的第一步就是不要寫爛代碼，也就是你要知道什么樣的代碼是爛代碼。

常見的爛代碼包括沒有注釋，變量命名不規(guī)范，代碼邏輯重復(fù)卻沒有抽離，大量 if-else 嵌套或者分支判斷，文件太大沒有拆分可能上千行代碼寫在一個(gè)文件里面。

最近掘金里面有個(gè)關(guān)于碼德的吐槽大會(huì)，發(fā)現(xiàn)里面留言最多的兩個(gè)問題就是條件判斷的嵌套，單個(gè)組件或者JS文件太大達(dá)到幾千行。

雖然很多時(shí)候不能去動(dòng)別人的代碼，但是我們盡可能保證自己的代碼寫好，出現(xiàn)這樣的問題我們需要讓自己那部分代碼越來越好管理，而不是一直讓問題繼續(xù)保留。

一旦你放松對(duì)自己代碼的要求，你的代碼就會(huì)迅速變成爛代碼，而且很難恢復(fù)。

如果是接手老代碼，一個(gè)比較有可行性的辦法是，盡量把自己的代碼和老代碼隔離開。如果有引用，則想辦法把接口局限在某個(gè)領(lǐng)域內(nèi)，最好是為它準(zhǔn)備個(gè)注入機(jī)制，隨時(shí)可改。

另外補(bǔ)充一個(gè)重要的點(diǎn)——會(huì)讀你寫過的代碼的只有兩個(gè)物種：程序員和瀏覽器。

所以，優(yōu)化其實(shí)也是分兩個(gè)方向的！在瀏覽器性能和代碼可讀性之間，往往需要做出取舍。這一點(diǎn)在“優(yōu)化”的時(shí)候一定要想清楚，如果是長(zhǎng)期維護(hù)的項(xiàng)目，那可讀性肯定要優(yōu)于性能；如果是一次性的項(xiàng)目，追求一下性能的極致也是很好的。