一周技术学习笔记(第84期)-代码评审的六大方向

代码评审的六大方向

1、代码逻辑

主要看逻辑是否合理，有无多余的逻辑在代码里面，以防给别人和自己买坑，或者将来出现不定时的线上问题，有没有嵌套的过深的逻辑等等。

2、代码调用

调用是否恰当，有没有重复的调用等等。

3、代码规范

这个每个公司都会有，也可以参照行业上的标准规范，我个人认为主要是看代码的可读性是否良好，对在面临需求交付时间压力下能做到良好就很不容易了，另外再看看可维护性是否良好，等等。

4、依赖管理

依赖关系之间是否严格，强弱依赖是否明确，等等。

5、数据库使用

看看数据库表的字段是否合理，数据库连接池大小是否合理，过大还是不足，等等。

6、中间件使用

比如，Redis中有没有热key，大key，MQ中的数据是否可以purge，有没有过度堆积的情况，RPC框架调用超时是否设置，设置是否合理，等等。

举几个例子。

1、调用方法存在snapshot包，这个大体能归到依赖管理方向里面吧，这里的风险是修改后调用方无感知，可以更新为release包，做到强制监测。

2、RedisLock分布式锁使用场景不明确，这个可以归到中间件使用方向里，隐患就是死锁、跨机房调用的时候失效，可以让大家注意不要滥用，需要明确场景，可以使用乐观锁或者事务代替。

3、表结构字段存在json，这个归到数据库使用方向里，这个带来的麻烦就是内容无法明确，可维护性差，而且还无法建立索引，建议对表结构优化。

4、存在用数字代表业务含义的代码，这样的情况可以归到代码逻辑里面去，也可以归到代码规范里面去，一旦出现这样的代码，可读性、可维护性、可扩展性就会变差，可以用一个枚举来尝试解决。

最后一个问题，如果代码评审过程中也发现了需要修改的内容，比如不符合规范，代码可读性上差，但是又不妨碍本次上线运行，这个时候应该如何办呢。最好是整体全方位来看，如果修改确实影响上线时间，那么可以用一个代码缺陷改进跟踪表，将其记录下来，里面写上待改进项、改进人、改进时间。然后从团队管理上定时抽检这个跟踪表。

参考资料：

https://time.geekbang.org/column/article/381569

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。