为什么要坚持code review - SegmentFault
有和没有之间的态度差别
很简单，一段代码完成之后，有人看和没有人看，在质量上还是会有差别的。
当你知道你的代码会被人一行一行review时，你的代码一定为努力写的最好，而不是为了完成功能而应付了事，这就是态度上的区分。因为当你知道你写的代码是有人看的，你会更加在意你写的东西，你一定不想背后被人说，代码写的像一坨**。
而且确实我自己在review代码时，就能看出哪些为了赶上线而写的就和平常写的会有差别。
代码的可读，可维护
代码的可读和可维护在大团队很关键，最初我们代码审核为什么严格到令人发指，就是因为可读性和可维护性。
严格的code review可以感觉整个团队写出的代码就像是一个人写的。这样就是为了能让你随时切换到其他业务上，而且不需要什么适应时间。
可读性和可维护对于大型的多人合作系统，可以说非常关键，当一个团队30多人在一个单页面开发时，如果风格各异，代码仅仅符合功能和测试要求的话，你会发现多人开发的成本和新需求的升级的成本会越来越高。
举个常见的例子：
如果某个业务突然需要提高进度，这时的办法就是加人力，但是如果代码风格各异，加入的人力适应时间和学习成本是极高的，有时甚至不如保持原有人力去加班hold。要不就只能找些技术很强，可以无障碍学习的资深工程师江湖救急。
我们这边其实就是会出现上面项目突然加急的情况，但是，因为有code review，所以我们多人合作时，基本上可以保证1+1≈2的效率。为什么这么任性，就是因为在code review时已经控制了大家的写法和模式，让新加入的同学能够马上看懂以前逻辑并且做大概的业务了解就能上手了。
我这边最近就经历了这些，因为需要还一些历史遗留的技术债务，所以我需要调整底层的一些代码结构，这时保证功能和互相调用ok的情况下切换代码位置和路径就是我遇到的最大的障碍。
不过由于之前业务代码的高质量和开发模式基本上完全一致，所以我能很快找到统一的切入点，预先就能预估好可能会踩的坑。
如果没有code review之前严格的约束，我基本上需要每个业务功能去分析了，效率降到极低。
对于新人，快速引导，快速反馈
对于新人加入我们的团队，最快的上手方式就是，简单熟悉完之后，接手一个业务项目，然后我们会通过不断的code review给与开发方式，编码习惯，设计模式之间的反馈。
第一个项目的review 基本上会是最严格的。
其实对于技术人员，code review 就是用代码在做沟通。
及时发现非代码上的问题
有时我在review代码时会发现，有些地方经常在反复修改，或者有时实现会非常别扭。这时我就会问开发人员，是不是需求不明确导致的，是不是对需求的理由有偏差。
因为对于正在开发的同学，经常会陷入到业务具体的实现中，有时就是饶了很大的圈子但是自己确不知道。这时review时是能感觉到的，而且我也成功的多次阻止过。
Read full article from 为什么要坚持code review - SegmentFault
No comments:
Post a Comment