web前端--Code Review - Super_gaga

2022年马上结束了，年底了，做一些总结吧。

主要关于每次前端的Code Review注意事项，

review的目的：

有和没有之间的态度差别

一段代码完成之后，有人看和没有人看，在质量上还是会有差别的。

当你知道你的代码会被人一行一行review时，你的代码一定为努力写的最好，而不是为了完成功能而应付了事，这就是态度上的区分。因为当你知道你写的代码是有人看的，你会更加在意你写的东西，你一定不想背后被人说，代码写的像一坨**。

而且确实我自己在review代码时，就能看出哪些为了赶上线而写的就和平常写的会有差别。

代码的可读，可维护

代码的可读和可维护在大团队很关键，最初我们代码审核为什么严格到令人发指，就是因为可读性和可维护性。

严格的code review可以感觉整个团队写出的代码就像是一个人写的。这样就是为了能让你随时切换到其他业务上，而且不需要什么适应时间。

可读性和可维护对于大型的多人合作系统，可以说非常关键，当一个团队多人在一个单页面开发时，如果风格各异，代码仅仅符合功能和测试要求的话，你会发现多人开发的成本和新需求的升级的成本会越来越高。

如果某个业务突然需要提高进度，这时的办法就是加人力，但是如果代码风格各异，加入的人力适应时间和学习成本是极高的，有时甚至不如保持原有人力去加班hold。要不就只能找些技术很强，可以无障碍学习的资深工程师江湖救急。

对于新人，快速引导，快速反馈

让新加入的同学能够马上看懂以前逻辑并且做大概的业务了解就能上手

对于新人加入我们的团队，最快的上手方式就是，简单熟悉完之后，接手一个业务项目，然后我们会通过不断的code review给与开发方式，编码习惯，设计模式之间的反馈。

第一个项目的review 基本上会是最严格的。

其实对于技术人员，code review 就是用代码在做沟通。

及时发现非代码上的问题

有时我在review代码时会发现，有些地方经常在反复修改，或者有时实现会非常别扭。这时我就会问开发人员，是不是需求不明确导致的，是不是对需求的理由有偏差。

因为对于正在开发的同学，经常会陷入到业务具体的实现中，有时就是饶了很大的圈子但是自己确不知道。

很很多团队拒绝code review 主要是基于时间不允许，项目追的太紧之类的。

我们要求每次提交的内容尽量少，完成一个小的功能点就可以提交。这样review的人看起来也会越快，反馈的时间也会约迅速。

例如，完成目录结构和框架就可以提交一版，这时可以review文件名字起的是否合理之类的。

在每次提交代码的时间上，我们也是期望每天都会有提交，最长也不要超过3天，不然最后提交的代码对于review的人也是负担，出现的问题也不一定来得及修复。如果长期这样，确实是会影响到开发效率。

其实合理的code review即不用浪费很多时间，而且问题都能快速暴露，快速修复。代码始终都能在保证在一个正确的方向上。

对代码不对人

发现存在在做代码code review时，有些同学会把情绪上升到对人的看法，这点是要不得的。cr是一件工作，更是对自己，对团队的负责；提升自己，提升团队。

及时反馈

组内同学在cr时有问题应该及时发表comment，责任同学修改或者回答完问题后，应该及时关闭问题；当所有问题都有反馈后，代码才应该进入merge

最后一步

我一般会在merge提一个comment LGTM(Looks Good To Me) ，一些在GitHub表较常用的比较火的词，What do cryptic Github comments mean?

做的一些总结如下：

发表于 2022-12-14 19:34 Super_gaga 阅读(125) 评论(0) 编辑收藏举报