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

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

另外，你還要保證項目的進度，因此代碼質量和項目進度之間有着自然的矛盾，怎麼去平衡值得咱們去思考，如下是個人一點經驗

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

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

具體來談談code review

如今每一個人的代碼我都會review，可是我不可能把不少時間放在上面，因此有時候不滿意的地方，我會下降要求，直接放過了。因此這中間須要一個取捨，哪些是要嚴格要求的，哪些是能夠無論的。

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

好代碼不必定是寫出來的

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

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