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

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

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

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

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

具体来谈谈code review

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

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

好代码不一定是写出来的

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

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

这种感觉。

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

    原文作者:韦磊
    原文地址: https://segmentfault.com/a/1190000019779589
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞