作为前端负责人，很多时候，你担心的不是如何写出好的代码，而是如何让身边技术不好的朋友写出来好的代码。另外，你还要保证项目的进度，所以代码质量和项目进度之间存在着天然的矛盾。如何平衡，值得思考。以下是我的经验。代码质量由以下几个方面保证。解决，eslint+prettier+codespecification（ts部分有待完善）codereview，现在主要是我自己看，后面会开放给大家，我整理一下checklist，帮助大家reviewCI（结合了gitlab，但还没做）））在项目过程中不断重构（我现在就是这样做的），尤其是在原有功能上增加新功能，难免会修改旧代码，这是一个很好的机会用于重构。封装公共组件库，让别人可以方便的使用你写的库，减少让别人写出烂代码的机会在框架层面把代码写好，让大家在框架里写代码的时候减少烂代码让我详细谈谈代码审查。现在我会review大家的代码，但是我不能花很多时间在上面，所以有时候我会降低要求，不满意就放手。所以这中间需要权衡一下，哪些必须严格要求，哪些可以忽略。变量的命名一定要严格，这是一个非常容易修改的地方。每个人都愿意更改代码行数。如果行数超过行数，代码过于复杂难以维护，则必须拆分来实现相同的需求。只要对方的实现没有特别大的漏洞，在代码实现上可以接受更好的方案，可以采纳一个建议，而不是直接拒绝。取决于个人。有些人可以接受别人的建议，有些人不能听信丝毫消极的东西，并区别对待。好的代码不一定是写出来的。如果你在做业务逻辑。首先，好的代码可能是聊出来的。比如你要确认这个，多问问题，多画流程图，少动手。后期可以省去很多麻烦。不了解需求就开始做，越做越错。相信很多工程师都有这种感觉。第二，好的代码可以边读边写。回顾你一天的工作，你会发现不管是写文章，还是做一些其他的事情。阅读代码多为跳码、文件内跳转、文件外跳转、分屏浏览。在这个过程中，不断地梳理和梳理原有的概念。最后实现代码。直接修改代码。占用你很少的时间。最后改好的代码。
