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

作爲前端負責人，很多時候發愁的不是寫好代碼，而是怎麼讓身邊水平較差的小夥伴能寫出好的代碼

另外，你還要保證項目的進度，所以代碼質量和項目進度之間有着天然的矛盾，怎麼去平衡值得我們去思考，以下是我的一點經驗

代碼質量由以下幾個方面來保證

1. 代碼風格問題，由工具和強制規範去解決，eslint + prettier + 代碼規範（ts部分需要完善）
2. code review，現在主要是由我來看， 後面開放給每個人，我會整理checklist，來協助大家review
3. CI （結合gitlab，但是還沒有做起來）
4. 在項目進行中不斷重構（現在我就是這麼幹的），特別是在原有功能上新增功能，勢必會對老代碼進行修改，這是重構的大好機會。
5. 封裝公共的組件庫，這樣讓別人可以很方便的用你寫的庫，減少了讓別人寫爛代碼的機會
6. 在框架架構層面把代碼寫好，讓大家在框架內寫代碼的時候減少寫爛代碼的機會

具體來談談code review

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

1. 對變量命名上絕對要嚴格，而且這是非常容易修改的地方，大家也都願意改
2. 對於代碼行數，如果超出行數導致代碼過於複雜，難以維護，一定要提出拆分
3. 對同一個需求在實現上不同，只要對方的實現沒有特別大的漏洞，都可以接受
4. 在代碼實現度上有更好的方案，可以採取建議的方式，而不是直接否決
5. 也要看人，有的人能接受別人的建議，有的人聽不得半點否定的東西，要區別對待

好代碼不一定是寫出來的

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

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