CodeReview
2023-12-15 09:50:31 4 举报AI智能生成
CodeReview
作者其他创作
大纲/内容
CodeReview关注哪些
代码规范与质量
命名
变量命名、方法命名、类命名、包命名
常犯错误
命名拼写错误、命名与实际含义不符（超出或小于）、用词不准
变量命名
推荐使用简洁明了带有业务语义的命名方式。不建议使用tmp、list、a、b等无法表述清楚当前变量是什么含义的命名方式。不建议使用下划线命名的变量名称如：_aop_signature。
常量命名方式推荐大写字母，多个词之间通过下划线连接，如图中的常量值我们建议提取成常量定义IS_RESHOOT。
方法命名和类命名
采用合适的词描述清楚当前方法/类的功能即可，此外注意采用驼峰式命名，代码可读性更高。
注释
是否有注释、注释是否合理
常犯错误
通篇无注释、注释不准确
注释恰当
能够清楚的表达当前行/方法/类的功能，不建议出现注释与代码不匹配情况。
适当的注释
议对于较为复杂的代码要提供适当的注释，都说好的代码是自注释的，但是无法保证的是有较复杂的业务背景情况下还有人能够看明白，此时需要添加部分注释。
日志打印
日志打印级别、日志打印参数、日志格式、异常打印、是否应该打印日志
常犯错误
日志打印级别误用、日志参数未打印、日志格式不规范、异常信息未打印、打印日志过多
日志打印级别是否合理
建议采用适当的日志级别进行打印，比如系统异常情况采用error级别打印，如果只是打印流程中某一个结果可以选用info级别，当部分参数不符合预期的情况下可以采用warn。
日志打印关键参数
建议在日志打印中打印出关键的参数信息，否则很难定位异常原因。
异常信息是否打印
异常处理日志打印时建议打印异常信息（e）到日志中，便于排查问题。
日志是否打印过多
尤其是针对服务调用频繁的服务，需要重点关注是否有必要打印日志，高QPS服务容易导致日志打印过多，引发磁盘容量不足等风险。
异常处理
异常是否抛出、是否规范的异常编码等
常犯错误
异常该抛出未抛、肆意的使用RuntimeException等
逻辑正确
业务逻辑是否正常
常犯错误
空指针问题、逻辑不正确等
代码风格一致
代码风格与应用整体风格一致
常犯错误
代码风格不一致
代码复杂度
圈复杂度
常犯错误
大量嵌套if导致非常复杂等
架构设计
关注分层
分层是否合理、是否存在跨层调用
分层混乱、跨层调用
关注扩展性
扩展适配
硬编码扩展性低
业务域划分
业务域划分清晰
业务域划分混乱
性能问题
慢SQL
索引设计、是否存在慢SQL语法
索引未设计、慢SQL用法如like %xxx语句等
缓存设计
添加缓存、是否存在缓存击穿问题
该加而未加缓存、缓存击穿问题等
安全性问题
是否存在安全风险
文件上传验权、越权访问问题
文件上传未验权、越权访问数据等
CodeReviewer的自我修养
站在CodeReviewer角度
作为代码的"质检员"，借助于团队形成的代码规约来严格把控代码质量
作为学习者，通过团队同学的CodeReview代码从中学习代码中的优秀设计
站在被CodeReviewer角度
作为学习者，通过团队同学的CodeReview意见从中学习优秀设计思想和代码规范
作为规范的输出者，通过良好的代码设计输出自己的代码设计理念，通过CodeReview等场所对外输出；
CodeReview文化建设
建设代码规约
团队范围内的代码规约需要团队层面能够达成共识，可以是团队leader牵头制定，也可以由大家一起通过CR的过程碰撞产生，总之需要能够沉淀代码规约并在团队范围内达成共识，这是形成文化的基础。
CR形式多样化
可以针对某一份代码在固定的时间（周会等）中进行分享并带领大家一起进行Review，增强大家的参与感和趣味性；也可以跨越领域去交换CR别的团队的代码，学习一下别的团队的代码规范。
调动积极性
鼓励团队同学积极参与，结合奖励机制不断的引导。
坚守文化
文化的形成，关键还在于坚持，只有坚持长期主义才能形成良好的CR文化，很多团队可能会存在坚持了一阵，时间久了慢慢又回归了旧的状态，这是我们不愿看到的。
适度的奖励机制
ICBU部门层面通过设立适当的奖励机制来鼓励大家参与卓越工程，参与CodeReview，有效的引导大家参与团队内的CodeReview，也有效的助推文化的形成和建设。
0 条评论
下一页
