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

另外，你还要保证项目的进度，所以代码质量和项目进度之间有着天然的矛盾，怎么去平衡值得我们去思考，以下是我的一点经验

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

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

具体来谈谈code review

现在每个人的代码我都会review，但是我不可能把很多时间放在上面，所以有时候不满意的地方，我会降低要求，直接放过了。所以这中间需要一个取舍，哪些是要严格要求的，哪些是可以不管的。

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

好代码不一定是写出来的

不一定。假如你是做业务逻辑的。首先，好代码可能是聊出来的。比如需求确认这一块，多问多画流程图少动手。就可以减少后期很多麻烦事情。

如果在没有理解透需求的情况下动了手，就会做得越多，错的越多。我相信很多工程师都有

这种感觉。

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