可否舉例說明你在工作中是如何優化前端代碼的？

原則

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

這個原則為什么重要？因為很多程序員會在寫代碼的時候說「先不優化了，等不忙的時候再優化」，然后……就沒有然后了。

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

別給自己寫爛代碼找理由

如果只要每天優化一點點代碼，就能保持你的程序健康，你，能做到嗎？

據我觀察，90% 的程序員做不到。他們每天都會在心里找出如下理由來寫出爛代碼，或者對現有的爛代碼視而不見：

這個項目我只維護幾個月，沒必要把代碼寫那么好，反正有人接盤。

這個項目是從別人手里接下的，代碼真爛，要怪就怪之前的人，不是我的錯，我胡亂加一些代碼就行了，能用就行。

這是一個短期項目，沒必要把代碼寫那么好

這是一個長期項目，明年再優化代碼，現在能用就行

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

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

過手就變好

如果你不想變成上面那樣的程序員，你只堅定一個信念：只要是經過我的手的代碼，質量就會比原來好一點。

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

接下來就是技巧。

第一步：不要寫爛代碼

方方你是傻了嗎，問的是「如何優化代碼」，你的答案居然是「不要寫爛代碼」？！

沒錯，把代碼寫好的第一步就是不要寫爛代碼，也就是你要知道「什么樣的代碼是爛代碼」：

如何寫出無法維護的代碼 - 酷 殼 - CoolShell

coolshell.cn/articles/4758.html

上面這篇教程非常好，把市面上的爛代碼基本都總結出來了，大概有這么幾類：

爛變量名

爛注釋

爛設計

不寫測試（所有沒有單元測試的代碼都是爛代碼，快點學習單元測試?。?/p>

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

而且他們還不知道自己代碼多爛！

所以第一步就是明白一個真相：你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 } }

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

優化后：

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] }

1

2

3

4

5

6

7

8

優化前：

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' } }

1

2

3

4

5

6

7

8

9

10

11

12

13

優化后：

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'] }

1

2

3

4

5

6

7

8

9

10

11

第四步：用套路

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

了解所有的套路，然后遇到問題選擇正確的套路即可。

比如模塊通信一般用事件模式或者命令模式；

比如解耦一般用中間層；

比如生命周期一般都支持鉤子或切面；

比如性能優化一般都是加緩存；

比如 API 設計一定要正交；

比如復雜數據系統一般使用命令查詢職責分離；

比如拿空間換時間拿時間換空間；

……

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

第五步：堅持每天優化

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

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

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

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

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

web前端 開發者

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。