代码可读性太差、看不懂、不敢动、改不动→→→重构

这些词在我们的日常开发中非常的常见，代码因为个人能力，经验，性格，态度，也可能更多的是因为策划的需求变更等等各种原因最终造成各种代码混乱，甚至连我们自己代码都看不懂的情况屡见不鲜。

为什么要做代码审查：

1.提前发现问题，很多代码可能在上线后都没跑到过，甚至可能是一些非常明显的错误。也有的可能是一些高风险的代码写法，我们应该要提前发现去做优化。更好的避免BUG发生，以及代码可以更多的人能维护。

2.提高个人编码质量，每个人都很不喜欢看到槽糕的代码，是不是也不希望别人看到自己的代码很槽糕。如果看到写的非常好的代码，我们是不是可以学习一下？

3.更好的团队协作，更认真的写提交日志，以及我们审查后更好的做总结和分享等

4.总的来说还是好处多多，养成好的编码习惯，阅读以及共同协作习惯

怎么做代码审查：

1自我审查

写代码时是按照自己构造的思路进行的，看代码时是作为一个观察者去对待。不同的视角会有不同的改变。经常碰到有人说看到自己写的代码，觉得太烂了，也许是因为自己现在进步，也许是现在写的还是一样烂，只是自己没去看而已。

2.核心模块

参考功能制作开发流程中讲述到的几个核心点

框架设计：先了解核心的类，主要的接口看大设计是否合理，条件允许的情况下可以与作者交流。

表格设计：可以快速进行审查，表格是否按照统一规范以及是否设计合理。

数据库表：除了本身的功能实现外，要注意主键、索引，字段大小等关键点进行快速审查。

代码：基础语法、单文件行数太多、单函数行数太多、注释不规范、接口封装混乱等等

高危项：

是否有容易死循环、递归溢出风险

lua中table全是引用，修改内存甚至修改配置表数据

帧更新的函数出现各种异常未捕获，造成无限报错

常规项

注释，  类、函数、协议等注释说明

临时代码，为了调试或者临时未实现完整

文件、字符串涉及到的编码是否都采用utf8

判空

变量重名

成员变量在外部多次直接访问和修改

没加local，特别是可能和_G重复

数值溢出，数组越界

lua中数组和哈希表混用的情况要注意

table数字key的用法

安全类

客户端请求的数据是否一一校验

配置表数据校验，尽量在程序启动时就避免一些策划配置错误

永远都是先扣钱再发货

正负数没判断造成扣钱变成加钱

数值溢出、数据库字段溢出、协议包溢出

错误日志和运行日志

数据库语句防注入

协议多次重复请求刷东西

性能类

特别注意帧更新，一般是update、run、tick等接口频率特别高需要做到尽可能简单

减少遍历，比如一次遍历中完成的，分开了几段代码做遍历

高运算或者大量创建的接口慎用，比如排序，大量新创建table

select全都用*

设计类

尽量将逻辑、数据、界面分离，类mvc的框架

类和接口的设计，别整太多很类似的接口，分不清应该调用哪个

一些常用的接口尽量统一调用，不要每个人甚至每个功能模块自己实现一个

总结

1.编码风格尽量统一，特别是多人协作的代码部分。毕竟你需要看别人代码，别人也需要看你的代码

2.多动脑思考，代码肯定是按照我们的思路来运行的

3.多写代码，写方案，写总结。记不住的文档记录下来，不会写的写多了自然熟

4.bug谁都会出，提高个人的编码水平，才能做出高质量的项目

其他参考：

https://blog.csdn.net/huver2007/article/details/75095303

https://blog.csdn.net/powertoolsteam/article/details/81699365

https://blog.csdn.net/messigodlike/article/details/78422833