代碼質(zhì)量把控和項目進度之間的平衡

guyan0319 發(fā)布于2019-08-30 11:26 / 2163人閱讀

摘要：所以這中間需要一個取舍，哪些是要嚴格要求的，哪些是可以不管的。首先，好代碼可能是聊出來的。比如需求確認這一塊，多問多畫流程圖少動手。在這個過程中不斷整理和梳理原有的概念。代碼的直接修改。最后，好代碼是改出來的。

作為前端負責(zé)人，很多時候發(fā)愁的不是寫好代碼，而是怎么讓身邊水平較差的小伙伴能寫出好的代碼 另外，你還要保證項目的進度，所以代碼質(zhì)量和項目進度之間有著天然的矛盾，怎么去平衡值得我們?nèi)ニ伎迹韵率俏业囊稽c經(jīng)驗 代碼質(zhì)量由以下幾個方面來保證

代碼風(fēng)格問題，由工具和強制規(guī)范去解決，eslint + prettier + 代碼規(guī)范（ts部分需要完善）

code review，現(xiàn)在主要是由我來看，后面開放給每個人，我會整理checklist，來協(xié)助大家review

CI （結(jié)合gitlab，但是還沒有做起來）

在項目進行中不斷重構(gòu)（現(xiàn)在我就是這么干的），特別是在原有功能上新增功能，勢必會對老代碼進行修改，這是重構(gòu)的大好機會。

封裝公共的組件庫，這樣讓別人可以很方便的用你寫的庫，減少了讓別人寫爛代碼的機會

在框架架構(gòu)層面把代碼寫好，讓大家在框架內(nèi)寫代碼的時候減少寫爛代碼的機會

具體來談?wù)刢ode review

現(xiàn)在每個人的代碼我都會review，但是我不可能把很多時間放在上面，所以有時候不滿意的地方，我會降低要求，直接放過了。所以這中間需要一個取舍，哪些是要嚴格要求的，哪些是可以不管的。

對變量命名上絕對要嚴格，而且這是非常容易修改的地方，大家也都愿意改

對于代碼行數(shù)，如果超出行數(shù)導(dǎo)致代碼過于復(fù)雜，難以維護，一定要提出拆分

對同一個需求在實現(xiàn)上不同，只要對方的實現(xiàn)沒有特別大的漏洞，都可以接受

在代碼實現(xiàn)度上有更好的方案，可以采取建議的方式，而不是直接否決

也要看人，有的人能接受別人的建議，有的人聽不得半點否定的東西，要區(qū)別對待

好代碼不一定是寫出來的

不一定。假如你是做業(yè)務(wù)邏輯的。首先，好代碼可能是聊出來的。比如需求確認這一塊，多問多畫流程圖少動手。就可以減少后期很多麻煩事情。
如果在沒有理解透需求的情況下動了手，就會做得越多，錯的越多。我相信很多工程師都有
這種感覺。

其次，好代碼可能是邊讀邊寫出來的。回顧一下一天的工作，你會發(fā)現(xiàn)，不管是，你寫文章，或者是做一些其他的東西。讀代碼，大部分都是跳轉(zhuǎn)代碼，文件內(nèi)跳轉(zhuǎn)，文件外跳轉(zhuǎn)，分屏瀏覽。在這個過程中不斷整理和梳理原有的概念。最后落實到代碼上。代碼的直接修改。占到你很少的時間。最后，好代碼是改出來的。