原問答:能否舉例說明你在工做中是如何優化前端代碼的?html
首先說一個最重要的優化原則:代碼優化是天天都要進行的,而不是一兩個月作一次大優化,那時作就已經晚了。另外因爲優化是天天作的,因此你不須要一次的就過分優化,保持小步快跑便可。前端
這個原則爲何重要?由於不少程序員會在寫代碼的時候說「先不優化了,等不忙的時候再優化」,而後……就沒有而後了。程序員
基本上「爛代碼」就是由於「不忙的時候再優化」形成的。shell
若是隻要天天優化一點點代碼,就能保持你的程序健康,你,能作到嗎?編程
據我觀察,90% 的程序員作不到。他們天天都會在內心找出以下理由來寫出爛代碼,或者對現有的爛代碼視而不見:設計模式
因此你看,無論我告訴他們多少優化代碼的技巧,他們根本就不會去用的,這纔是問題所在。緩存
不少程序員抱怨公司代碼爛,卻歷來不去嘗試解決問題。(就像不少程序員抱怨培訓班教出來的人水平差,本身卻不寫新人教程同樣)性能優化
若是你不想變成上面那樣的程序員,你只堅決一個信念:只要是通過個人手的代碼,質量就會比原來好一點。函數
那麼你很快就能把代碼寫好了。你可能急於聽到把代碼寫好的技巧,可是我告訴你,技巧真的不重要,這個信念纔是最重要的。性能
接下來就是技巧。
方方你是傻了嗎,問的是「如何優化代碼」,你的答案竟然是「不要寫爛代碼」?!
沒錯,把代碼寫好的第一步就是不要寫爛代碼,也就是你要知道「什麼樣的代碼是爛代碼」:
上面這篇教程很是好,把市面上的爛代碼基本都總結出來了,大概有這麼幾類:
基本上全部新人每天都在寫爛變量名、爛註釋和爛設計,並且還不寫單元測試。
並且他們還不知道本身代碼多爛!
因此第一步就是明白一個真相:你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。
我在課上說過,「天天優化」才叫重構,「每一年優化」那叫重寫。
優化的重點是「愈來愈好」,重點不是「一次寫好」。
一旦你放鬆對本身代碼的要求,你的代碼就會迅速變成爛代碼,並且很難恢復。
每當需求變化的時候,你都要從新審視你的整個系統,哪裏有問題你就改那裏,不容許「先臨時改一下之後再優化」,你的代碼就能夠保持健康和活力。
惋惜,大部分人作不到。就算我本身也會在需求太多的時候放鬆對代碼的要求。