需求评审和任务划分后,进入设计阶段,开始各种设计。UI 人员开始设计 UI 图,后端开始概要设计,前端框架搭建组件划分,测试编写测试计划,这些都并行完成。
一般 UI 会早点设计完,大家开始 UI 评审,平时主要依据原先的需求看看有没有遗漏,交互的过程是否合理,细节上是否要补充,UI 图和前端关系更紧密,所以一般前端人员的关注度会更高。
后端概要设计,主要包含本次需求开发的主要思路,涉及已有模块的主要修改或扩充,是否要做哪些重构,添加哪些新模块,为什么是这样的设计。对已有接口做哪些修改,新加 API 接口的文字简单描述。涉及主要技术选型,数据库的存储的数据字典等等。后端概要设计完后,组织开始概要设计的评审,主要是项目经理、架构分析师、后端开发人员, 前端人员只参与其中和前端 交互 API 有关的部分内容。概要设计时不仅仅关心的是否能很好的实现本次精华后的需求,更多的还要关注是否领域模型的划分,设计的模块是否高内聚低耦合,保存足够的灵活性,是否已有部分需要重构,原先部分是否可以复用,技术选型是否项目总体的选型, 这样才能防止整个项目腐蚀,及时归还技术债务。概要设计评审通过后,开始各个模块 API 接口设计,与前端直接交互的 API 可以由前端来设计,毕竟是他们来使用,如果前端没有能力做到的话,只能由后端人员来设计。设计的 API 可以通过 swagger 实现,或者 easyApi 插件同步到 yapi 的 api 接口管理平台,这样写代码直接就能产生接口文档。API 接口设计完成后组织评审,参与评审人员主要有后端人员、项目经理和架构分析师,评审时不仅关注功能完整性,还需要关心语义是否清晰易懂,职责是否单一明确,设计是否符合规范。如果平时的 API 接口是直接给前端对接使用的,那么就需要相关前端人员参与评审,并负责主持讲解这些 API 接口,这样可以让前端更加积极主动地评审,评审时可以打开 UI 图和需求文档,对照着进行评审,评审不仅关注对前端的接口功能完整,还更需要关注是否好用易用,这样尽量减少前端对接联调时的返工。API 接口评审完成后,可以根据分开同时开发,如果前端先开发完成部分,就可以使用 ypai 的 api 接口管理工具,模拟后端的 API 接口数据进行联调。如果多个后端人员参与本次需求的开发,那么大家依据评审的各个模块的 API 接口并行开发,联调时也可以先通过 yapi 来模拟数据对接。如果有测试开发工程师,就可以根据 API 接口开发测试自动化程序。
前端最好也要进行设计,根据 UI 图划分组件,设计各个组件之间的关系,如何复用等等。组件下面,各个数据层如何划分设计,路由设计等。现在前端也越来越复杂,如果不进行规划设计,等到后期,前端的代码也很难维护。前端的设计评审,主要由前端技术相关人员、项目经理参与。
简要测试方案的设计完成后,前后端开发人员、项目经理和产品经理都要进行评审,评审时不仅关注测试方案的完整,还要关注主要测试用例和需求文档、UI 图是否一致,评审通过后测试人员设计更详细的测试用例和准备测试环境。
敏捷开发中的设计阶段的输出文档,都是简要的,主要沟通使用,不会牵扯太多的细节,主要涉及各个模块的交互设计和之间详细的接口。模块内部的详细设计,都在编码时完成。
敏捷设计和传统式计划式设计的不同,就是敏捷设计一般不进行超前设计,重点是对当下的开发任务设计和原有功能的重构。为了实现当前的开发任务,需要先把原有涉及到的模块分析是否要重构,如何重构,重构后怎么适配本次迭代开发任务。例如,本次开发中要复用原先某一段功能代码,所以需要先把原先功能代码重构抽成可公共使用的类或模块,然后先让原有的功能正常,再被本次开发的功能使用。或者,业务领域模型到了一个临界点,需要把原有一个边界上下文划分成两个,其中一个要包含本次开发的业务领域。传统的计划式设计,会对当下及以后可能的扩展进行设计,这种设计具有超前性,但实际当中超前设计往往就是过度设计,后期需求变更导致设计架构变更,从而那种计划式设计架构失效,并且还形成阻碍,也浪费原先设计所做的各种开发工作。敏捷式设计主要是原有的重构和当下的设计,这样所做的工作都是有效的,虽然敏捷设计会让原有的代码模块重构,但通过自动化测试,使得编码级的变更成本显著降低,再加上不断地重构优化代码结构,使得模块之间耦合足够低,代码保持整洁,这样也会使得重构成本不会增高。敏捷设计中的架构分析师,更多的是以教练的形式协助程序员做好重构和当下开发设计工作,而不是直接做好相关设计,让程序员执行。