Design review 设计评审

目录

背景

几年前在实习时,我完全没有接触过设计评审。当时的团队采用Scrum开发过程。开发团队采取一个架构师(Architect)和三到四个开发者(Developers)的配置。为了保证开发速度,冲刺订单(Spring backlog)里的大多数任务(Ticket)都有架构师写的详细开发步骤。架构师在团队里负责了大多数的软件设计任务,开发者则专注于将架构师的想法实现。

参加工作后,由于开发领域,开发过程,甚至是公司文化都与我实习过的公司有很多不同。在此期间,我也接触到了相当多的设计文档和设计评审。

2019年,我在开发团队里承担的设计任务也越来越多,写过的设计文档有二三十个。参加的设计评审则是更多。一年下来,我对设计评审,这个软件开发中的一个流程,有了自己的一些看法,下面则是我对设计评审的一个小总结。

设计文档

设计评审,需要首先有设计。这里说的设计就是设计文档(全称软件开发设计文档)。这是在软件开发之前,一种把软件设计思路结构化记录下来的资料。我第一次接触设计文档是在大学的软件工程课上。当时我也在课程项目中写过设计文档,但是却对为什么需要设计文档体会不深。毕竟当时的项目都很小,难度也不大。写设计文档无非是根据模板填充文字的游戏罢了。

但是当项目参与人员众多,开发难度大时,软件设计,作为软件开发的一个流程,被重视起来。我们在实践过程中,尤其是在一些重要的工作上 (比如时间跨度长,需要几个Sprint周期才能完成的工作,或者涉及多个团队,需要跨团队分工协作时),需要先把思路写下来,通过设计评审分享出来,得到相关人员的批准或者承诺后,再进行实现。

也许短期看,写设计文档,走完设计评审流程比直接蒙头实现软件要慢的多。但是一个好的设计可以在长期为产品的开发节省大量的时间。试想一下在有其他团队对你的软件库(Library)或者Web Service产生依赖时你才发现你的代码需要重新设计的情况,这时不仅是自己负责的项目会受到影响,使用你的代码的其他团队的项目也都会受到影响。

设计评审是软件开发的一个重要环节,写好设计文档则是让设计评审成功的第一步。在我看来,一个好的设计文档应至少包括如下几项:

  • Problem statement。陈述待解决的问题,以及为什么要解决这个问题,或者说,不解决这个问题的后果是什么。
  • Recommended proposal。详细阐明推荐的解决方案,以及Pros/Cons的比较。
  • Alternatives。其他可行的解决方案,一般来说解决方案不止一种,也需要有Pros/Cons 对比。能让评审人知道trade-off是什么。

更加详细的设计文档除了上面几项外还会有:

  • Background。交代问题的背景,比如总项目的进程,该问题所属项目与总项目之间的关系。
  • Term。术语表。通常在抽象度高的讨论中,会用到很多术语以及缩略语。它们应该在术语表里进行定义,以避免歧义。
  • Plan。项目的计划。实现过程复杂时,需要分解实现过程,定义每个阶段的需要交付的模块。或者是每个阶段性成果Milestone是什么。

评审

一个成功的设计评审需要以下要素。

  • 精简的评审团。只让必要的人参与进来。比如项目负责人,项目的主要贡献者或者受到最大影响的人。他们对设计思路的方向最有发言权,能提出有建设性的意见,而且能最后拍板。邀请不必要的人,会增加讨论中的噪音,以致评审流程变慢。
  • 提前制定好的议案。有效率的讨论需要高质量的议案。设计评审的发起人需要准备好评审大会的议案流程,先讨论重要的点,比如一旦敲定就可以让部分项目先开展实现的点。这样接下来的点可以在不阻塞项目进展的情况下讨论。
  • Meeting Minutes。及时分享会议记录,其中包括参与的人,何时做出了什么决定或者得到了什么共识。当评审大会需要分几次召开时,会议记录作为之前会议的备忘能让我们避免重复讨论。