设计阶段的思考

        需求评审和任务划分后，进入设计阶段，开始各种设计。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 图是否一致，评审通过后测试人员设计更详细的测试用例和准备测试环境。

        敏捷开发中的设计阶段的输出文档，都是简要的，主要沟通使用，不会牵扯太多的细节，主要涉及各个模块的交互设计和之间详细的接口。模块内部的详细设计，都在编码时完成。

        敏捷设计和传统式计划式设计的不同，就是敏捷设计一般不进行超前设计，重点是对当下的开发任务设计和原有功能的重构。为了实现当前的开发任务，需要先把原有涉及到的模块分析是否要重构，如何重构，重构后怎么适配本次迭代开发任务。例如，本次开发中要复用原先某一段功能代码，所以需要先把原先功能代码重构抽成可公共使用的类或模块，然后先让原有的功能正常，再被本次开发的功能使用。或者，业务领域模型到了一个临界点，需要把原有一个边界上下文划分成两个，其中一个要包含本次开发的业务领域。传统的计划式设计，会对当下及以后可能的扩展进行设计，这种设计具有超前性，但实际当中超前设计往往就是过度设计，后期需求变更导致设计架构变更，从而那种计划式设计架构失效，并且还形成阻碍，也浪费原先设计所做的各种开发工作。敏捷式设计主要是原有的重构和当下的设计，这样所做的工作都是有效的，虽然敏捷设计会让原有的代码模块重构，但通过自动化测试，使得编码级的变更成本显著降低，再加上不断地重构优化代码结构，使得模块之间耦合足够低，代码保持整洁，这样也会使得重构成本不会增高。敏捷设计中的架构分析师，更多的是以教练的形式协助程序员做好重构和当下开发设计工作，而不是直接做好相关设计，让程序员执行。