设计高端的国外网站,做网站预算表,公众平台微信公众号登陆,给个网站你们知道的应该对于基本上所有软件相关的公司来说#xff0c;都有committer机制#xff0c;即代码写好之后会提交合并请求#xff0c;待相关人员code review通过后再进行合入#xff0c;所以code review就是代码合入代码仓库的最后一道关卡#xff0c;对于代码质量的影响也是不容忽视…应该对于基本上所有软件相关的公司来说都有committer机制即代码写好之后会提交合并请求待相关人员code review通过后再进行合入所以code review就是代码合入代码仓库的最后一道关卡对于代码质量的影响也是不容忽视的那么作为在华为、阿里等大厂担任过committer的老code reviewer我在code review关注哪几方面的东西呢
代码风格
比如命名是否正确、函数抽象是否合理等这些影响代码后面的可读性。在我刚从学校毕业的第一份工作的第一个项目中那时候还保持着在学校里面的思维就是代码只要实现功能就行所以命名各种a、b、c、test之类的函数抽象也不注意这样当然不会影响功能的实现但问题是商业产品的代码是有一个漫长的维护周期的当你实现的功能不可避免的出现问题的时候麻烦就来了。当时我第一个项目交付之后半个月就遇到了一些功能上的问题需要我去改下代码这个时候我去读我半个月前写的代码已经完全读不懂了看到那些a、b、c、test的变量名完全不知道这个当时是想拿来存什么的好不容易看懂一点需要改的时候因为函数也没有很好的规划导致一个功能点需要霰弹式的修改很多地方维护起来异常困难。从那次经历以后我就知道软件工程远远不是实现功能这么简单可读性、可维护性也会是其中的重要一环。
是否有逻辑问题比如无法退出的for循环之类的
这种最好也能在code review这一环节就被检查出来方法也非常简单看到任何循环语句比如for、when、while的时候多留一个心眼看一下循环条件判断语句有没有恒为true的情况特别是那种不在循环条件里面写循环条件设置循环条件为true而是在循环体里面去设置不满足条件时再break的情况这种要特别留心看下有没有可能无法跳出循环。
是否有资源泄漏的风险
这个比较难一点需要对当前所使用的技术栈有可能造成内存泄漏的方式有所了解比如C有没有锁申请了没释放、有没有从堆上申请了内存没有释放golang有没有把切片的一部分作为一个切片返回出去比如把一个长度为1000的切片的前10个数据作为一个切片返回出去比如a[:10]。
流程完善
除了人通过肉眼code review外还可以增加各种辅助检查工具比如一些静态检查的lint或者提交以后自动跑一次编译避免合入以后引入编译问题。
speed and performance
当前代码构造的方法是否足够合理是否是性能最好的方法可以通过大O表示法来进行一个大体的判断同时也可以判断一下圈复杂度是否过高。
是否重复造轮子
这个要分成两部分来说。一是对于已经有的轮子就不要重复去造一个了另外就是如果提交的代码里面多次出现一段代码考虑把它造成一个轮子也就是抽象成一个函数而不是在多个地方把它写多次。
可靠性容错性
如果发生错误的话这个地方是否会崩溃是否能比较好的抛出有意义的异常
是否有冲日志的可能
是否会大量打无意义的日志导致日志被冲掉影响正常定位问题。
是否有错误被抑制了
这个是最微小、最容易被忽视、却又影响很明显的一点。错误被抑制是我自己定义出来的一个术语大意是说错误没有正确的被展示。具体内容可以关注我的另外一篇文章使用golang的AST编写定制化lint_golang lint-CSDN博客
最后祝大家提升代码工程质量之后能早点下班不用加班来填质量的坑~
