1. 程式人生 > >我在工作中是如何優化程式碼的

我在工作中是如何優化程式碼的

原問答:可否舉例說明你在工作中是如何優化前端程式碼的?

原則

首先說一個最重要的優化原則:程式碼優化是每天都要進行的,而不是一兩個月做一次大優化,那時做就已經晚了。另外由於優化是每天做的,所以你不需要一次的就過度優化,保持小步快跑即可。

這個原則為什麼重要?因為很多程式設計師會在寫程式碼的時候說「先不優化了,等不忙的時候再優化」,然後……就沒有然後了。

基本上「爛程式碼」就是因為「不忙的時候再優化」造成的。

別給自己寫爛程式碼找理由

如果只要每天優化一點點程式碼,就能保持你的程式健康,你,能做到嗎?

據我觀察,90% 的程式設計師做不到。他們每天都會在心裡找出如下理由來寫出爛程式碼,或者對現有的爛程式碼視而不見:

  1. 這個專案我只維護幾個月,沒必要把程式碼寫那麼好,反正有人接盤。
  2. 這個專案是從別人手裡接下的,程式碼真爛,要怪就怪之前的人,不是我的錯,我胡亂加一些程式碼就行了,能用就行。
  3. 這是一個短期專案,沒必要把程式碼寫那麼好
  4. 這是一個長期專案,明年再優化程式碼,現在能用就行

所以你看,不管我告訴他們多少優化程式碼的技巧,他們根本就不會去用的,這才是問題所在。

很多程式設計師抱怨公司程式碼爛,卻從來不去嘗試解決問題。(就像很多程式設計師抱怨培訓班教出來的人水平差,自己卻不寫新人教程一樣)

過手就變好

如果你不想變成上面那樣的程式設計師,你只堅定一個信念:只要是經過我的手的程式碼,質量就會比原來好一點。

那麼你很快就能把程式碼寫好了。你可能急於聽到把程式碼寫好的技巧,但是我告訴你,技巧真的不重要,這個信念才是最重要的。

接下來就是技巧。

第一步:不要寫爛程式碼

方方你是傻了嗎,問的是「如何優化程式碼」,你的答案居然是「不要寫爛程式碼」?!

沒錯,把程式碼寫好的第一步就是不要寫爛程式碼,也就是你要知道「什麼樣的程式碼是爛程式碼」:

如何寫出無法維護的程式碼

上面這篇教程非常好,把市面上的爛程式碼基本都總結出來了,大概有這麼幾類:

  1. 爛變數名
  2. 爛註釋
  3. 爛設計
  4. 不寫測試(所有沒有單元測試的程式碼都是爛程式碼,快點學習單元測試!)

基本上所有新人天天都在寫爛變數名、爛註釋和爛設計,而且還不寫單元測試。

而且他們還不知道自己程式碼多爛!

所以第一步就是明白一個真相:你80%的程式碼都是爛程式碼。

你只需要把這些程式碼改得不那麼爛,就是優秀的程式碼了……

再說一次:第一步至關重要,搞清楚什麼樣的程式碼是爛程式碼。

第二步:避免重複

也就是 Don't Repeat Yourself 原則。如果你發現有兩行程式碼重複出現了好幾次,你就應該把這兩行程式碼封裝成一個函式,放在一個恰當的地方,然後呼叫這個函式。

第三步:表驅動程式設計

如果你的程式碼有很多 if ... else ... 結構,你不知道怎麼優化,你就應該使用表驅動程式設計。

優化前:

howManyDays(year, month){
    if(month === 1 ||
        month === 3 ||
        month === 5 ||
        month === 7 ||
        month === 8 ||
        month === 10 ||
        month === 12
    ){
        return 31
    }else if(month === 2){
        return isLeapYear(year) ? 29 : 28
    }else{
        return 30
    }
}
複製程式碼

優化後:

howManyDays(year, month){
    const table = {
        1: 31, 3: 31, 5: 31, 7: 31, 8: 31, 10: 31, 12:31,
        4: 30, 6:30, 9: 30, 11: 30,
        2: isLeapYear(year) ? 29 : 28
    }
    return table[month]
}
複製程式碼

優化前:

function calculateGrade(score){
    if(score>=90){
        return 'A'
    }else if(score >= 80){
        return 'B'
    }else if(score >= 70){
        return 'C'
    }else if(score >= 60){
        return 'D'
    }else {
        return 'E'
    }
}
複製程式碼

優化後:

function calculateGrade(score){
    const table = {
        100: 'A', 
        90: 'A',
        80: 'B',
        70: 'C',
        60: 'D',
        others: 'E'
    }
    return table[Math.floor(score/10)*10] || table['others']
}    
複製程式碼

第四步:用套路

設計模式就是一些程式設計套路,Unix 程式設計原則也是一些程式設計套路。

瞭解所有的套路,然後遇到問題選擇正確的套路即可。

比如模組通訊一般用事件模式或者命令模式;

比如解耦一般用中間層;

比如生命週期一般都支援鉤子或切面;

比如效能優化一般都是加快取;

比如 API 設計一定要正交;

比如複雜資料系統一般使用命令查詢職責分離;

比如拿空間換時間拿時間換空間;

……

這一塊還挺複雜的,夠你糾結很久了,而且沒有通解。唯一的通解就是 tradeoff。

第五步:堅持每天優化

我在課上說過,「每天優化」才叫重構,「每年優化」那叫重寫。

優化的重點是「越來越好」,重點不是「一次寫好」。

一旦你放鬆對自己程式碼的要求,你的程式碼就會迅速變成爛程式碼,而且很難恢復。

每當需求變化的時候,你都要重新審視你的整個系統,哪裡有問題你就改那裡,不允許「先臨時改一下以後再優化」,你的程式碼就可以保持健康和活力。

可惜,大部分人做不到。就算我自己也會在需求太多的時候放鬆對程式碼的要求。

以上內容在我的《JS深入淺出》課程中有所涉及,課程講義可以免費看