review的个人价值

发表于 2021-04-27

| 0

| 阅读次数: 7

在通常的开发流程中，会有各种各样的评审(review)环节，比如产品稿评审、设计评审、测试用例评审、code review等。为了做这些评审，难免会引入一些会议。有的人会觉得这些事没什么用，太浪费时间。而实际上，这些事情是非常重要的，如果你产生了评审不重要的印象，原因无非两个，一是认知不到位，而是你所在的环境评审实施的不好。

关于评审的价值，首先对于团队来说，最大的作用其实就是提升团队的下限。试想一下，如果各个环节都不进行评审，而是直接产品交付一个产品稿，开发就对着开发，任何个人的疏忽都会给整个项目带来无尽的风险。多次的评审环节，实际上就是将一个业务方案，分别用产品稿、代码、测试用例等形式描述，再分别引入更多的人来检查，避免一个人的疏忽造成业务上的风险。

此外，本文的重点，我实际上是想讲讲除了给团队带来的价值外，对于一个个体的人来说，参与评审有什么价值。

首先说一下对于被评审的人，即产品稿、代码等的提交人来说，评审就是一个其他人来帮助你提升的过程，是难得的能获取直接的反馈信息的机会。其实对于很多人来说，相比于学生时代，工作时代学东西的最大难点就是没有人批改「作业」，看了书看了视频之后，没办法确认自己究竟学没学会。而及时的反馈，无论学什么，都是非常重要的。而在参与评审的人中，会包括你的上级，能力更强的同事。他们能够详细的了解你的方案、代码的话，相信是能够给出很多有价值的反馈的。评审，实际上就是给你自己提供一个机会，能够接收到他们的反馈信息。

这里其实隐含了一条对于提交人的要求，就是要能够清晰的表达出自己的方案，这样别人才能低成本的参与到评审中来。比如写代码，要运用合理的设计模式，写出易读的代码。写文档，要有合理的布局、分段，突出方案的重点。向别人讲方案时，要考虑听众的知识背景，确保他们可以听的懂你的方案。

评审对于提交人的另一个重要作用，是分担风险和责任。要知道，无论你公司的制度是什么样的，无论你的职位如何，当你负责的项目没有做好时，最终的结果，一定是有相当一部分是由你自己承担的。承担的形式，可能是直接的绩效损失，可能是别人对你的能力产生了质疑，不管怎样，都是大家不希望面对的。而评审，就是将一部分后果，转移到整个团队上。当然，别想太多，主体的责任一定是还在提交人本人身上。这里，同样体现了提交人清晰表达的重要性。提交人需要将自己方案的关键点，更多的让评审人们接受到。如果评审人成功的接收这些信息，并且在评审时进行充分的讨论并最终达成共识，这一部分决策就可以认为是团队共同做出的了。

接下来再来看对于评审人来说，积极的参与对其他人的评审，又有什么作用。首先的价值还是一个学习的机会。所谓三人行，必有我师，从别人的方案里，一定是能够发现一些非常好的点，值得自己学习的。当发现别人的方案和自己的设想不一致时，是一个进行深度思考的机会，可以对自己进行一个连续的追问，看看到底哪种方案比较好，直到得出一个无法质疑的结论。这种深度的思考，对于自己的思考方式会有很好的改善作用。

另外，参与评审也是一个快速提升经验的方法。参与评审，实际上是花费评审的时间，得到一个无限接近于 自己做了这件事 的效果。评审的足够细致的话，你就会对这件事怎么做，有一个非常全面的认识，这件事也就完全可以作为你项目经历的一部分。

本文到这里就要结束了，不知道大家能否通过本文建立起对为什么要做评审、怎么做评审的认知。大家可以通过知乎 , 公众号( Mobility ), 个人网站 等和我交流。

原文地址: https://lcy362.github.io/posts/57205