review的个人价值

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

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

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

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

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

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

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

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

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

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