前言
不知道大家有沒有感覺， 一到三年工作經(jīng)驗的其實差距還是很大的 ，有的一年工作經(jīng)驗的能力的確比三年的更強點，難不成他們是天生編碼能力強？非也！是因為他們會花更多的時間去學習去思考。
其中個人覺得 code Review 和 學習優(yōu)秀的開源項目 會讓你的編碼能力提升的非?？?.
仔細來說說 code Review 的好處吧:
- 多人一起review 你的代碼的時候 會迸發(fā)出更多 想法 讓你知道 你又哪些方面沒有考慮到
- Review 水平比你高的 你可以在他的編碼習慣中學習到 很多思路與設(shè)計
- Review 水平比你低的 你可以看看那些錯誤是怎么發(fā)生的 從而以后去避免他
- Review 和自己差不多的 你可以換位思考 看看自己和他的 實現(xiàn)方式的區(qū)別
分享一下我們Review 的代碼
下面代碼都是 偽代碼 ，請勿較勁，并且每一家公司有自己的 規(guī)范與習慣 如果和你們的習慣不一樣 ，那就是你們對 僅供參考~
1、對于只有一個 if else 并且簡單賦值可以用三元表達式優(yōu)化
修改之前：
優(yōu)化后：
對于 不變的并且結(jié)構(gòu)很長的這種對象或數(shù)組，可以放到一個 ts 文件，通過引入的方式，這樣代碼看起來會代碼更簡潔明了
2、用map 映射 替換重復判斷的 if else
修改之前：
優(yōu)化后：
對于重復的 if else 判斷，可以用map 結(jié)構(gòu)去優(yōu)化，這種也是設(shè)計模式中的 策略模式 ，這樣就會避免代碼中大量的 if else 讓人看代碼的時候頭疼
3、將forEach+splice的方式 替換成findIndex+splice
修改之前：
優(yōu)化之后：
每次寫代碼的時候不應(yīng)該只會使用 forEach, 這個場景就 通過 findIndex 直接找到索引, 刪除那一項 這樣不會像 修改之前那樣 每次都要遍歷完數(shù)組 復雜度會大大降低
4、將判斷提前
修改之前：
修改之后
將判斷提前,就不用if里面包裹大量邏輯,并且優(yōu)化性能,當 dataNum 不存在的時候 就不會執(zhí)行下面的代碼了
5、太多重復的對象代碼 可以用解構(gòu)的方式
修之前：
修改之后：
params 參數(shù)就是 應(yīng)用于 form 沒必要一個個的賦值過去 可以 可以用 ... 的方式
6、對于大量的 重復類型可以用 Pick、Partial、Omit 等ts 的內(nèi)置類型 對 一個類型去做 類型提取
修改之前：
修改之后：
這樣的的話 盡可能就是對一個大的類型進行收斂 而不是分散的 各種重復的類型
7、避免使用 魔法數(shù)字 可使用一個常量 或者枚舉去替代
修改之前：
修改之后:
將 魔法數(shù)字 120 改成一個常量 加上注釋 這樣會 清晰很多
8、盡量少的造輪子
修改之前：
修改之后：
這里邏輯是關(guān)閉elemnet 之外的 彈框 其實沒必要自己手寫這種邏輯 而且寫不好還有可能有一些奇怪的bug 在vue3 中比較廣泛使用的自定義hooks就是 vueuse 大家可以多看看 這種庫 不僅提高開發(fā)效率 還有利于學習如何編寫自定義hooks
總結(jié)
如果你是一個剛?cè)胄?并且公司只有你一個前端 其實個人覺得 會很難養(yǎng)成一個好的編碼習慣 因為沒有可以參考的地方，這種情況公司沒有大佬 也沒有機會組織code Review 那你就可以多看看開源項目 比如 vue3 的 elemnet-plus 、vben、vue3-admin-vite等等，如果你公司有 code Review 的活動請牢牢抓緊它 因為你可以從中獲益匪淺！
作者：前端摸魚杭小哥
鏈接：
https://juejin.cn/post/7303435124527185960
