代码质量把控和项目进度之间的平衡

做为前端负责人，不少时候发愁的不是写好代码，而是怎么让身边水平较差的小伙伴能写出好的代码

另外，你还要保证项目的进度，因此代码质量和项目进度之间有着自然的矛盾，怎么去平衡值得咱们去思考，如下是个人一点经验

代码质量由如下几个方面来保证

1. 代码风格问题，由工具和强制规范去解决，eslint + prettier + 代码规范（ts部分须要完善）
2. code review，如今主要是由我来看， 后面开放给每一个人，我会整理checklist，来协助你们review
3. CI （结合gitlab，可是尚未作起来）
4. 在项目进行中不断重构（如今我就是这么干的），特别是在原有功能上新增功能，势必会对老代码进行修改，这是重构的大好机会。
5. 封装公共的组件库，这样让别人能够很方便的用你写的库，减小了让别人写烂代码的机会
6. 在框架架构层面把代码写好，让你们在框架内写代码的时候减小写烂代码的机会

具体来谈谈code review

如今每一个人的代码我都会review，可是我不可能把不少时间放在上面，因此有时候不满意的地方，我会下降要求，直接放过了。因此这中间须要一个取舍，哪些是要严格要求的，哪些是能够无论的。

1. 对变量命名上绝对要严格，并且这是很是容易修改的地方，你们也都愿意改
2. 对于代码行数，若是超出行数致使代码过于复杂，难以维护，必定要提出拆分
3. 对同一个需求在实现上不一样，只要对方的实现没有特别大的漏洞，均可以接受
4. 在代码实现度上有更好的方案，能够采起建议的方式，而不是直接否决
5. 也要看人，有的人能接受别人的建议，有的人听不得半点否认的东西，要区别对待

好代码不必定是写出来的

不必定。假如你是作业务逻辑的。首先，好代码多是聊出来的。好比需求确认这一块，多问多画流程图少动手。就能够减小后期不少麻烦事情。
若是在没有理解透需求的状况下动了手，就会作得越多，错的越多。我相信不少工程师都有
这种感受。

其次，好代码多是边读边写出来的。回顾一下一天的工做，你会发现，不论是，你写文章，或者是作一些其余的东西。读代码，大部分都是跳转代码，文件内跳转，文件外跳转，分屏浏览。在这个过程当中不断整理和梳理原有的概念。最后落实到代码上。代码的直接修改。占到你不多的时间。最后，好代码是改出来的。