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