发表于 2024年7月28日1年前 最近一直在思考这个问题，希望跟大家讨论一下。起因是公司有个惯例，研发前需要做详细设计并且评审。设计包含 REST 接口和参数、模型和字段、行为模型调用层次、时序图、数据库表结构设计，大概就是类似 UML 那一套。部分设计还需要包含各种条件分支、异常处理的逻辑。达成目标就其他人拿到这个设计文档后不需要太多沟通就可以完成开发。每次做新需求，这个阶段是最痛苦的，我个人非常抵触。我倒不是抵触研发前设计这个步骤，我是抵触性价比不高的过度设计。我们做设计的目的是为了对齐前后端、各服务之间的想法，防止出现方向性错误。所以我认为 REST 接口和表结构是必须要提前设计的，一方面是因为有了 REST 接口前端才可以提前介入开发，有了表结构大概能知道设计者对需求理解有没有大的偏差，两个结合起来大概就能知道这个需求如何实现了，另一方面，因为这两块重构代价太高了。如果是简单需求变更，这两样个人认为足够了。针对复杂场景可以适当增加时序图，这样评审的时候可以集思广益，帮忙查漏补缺。我最抵触的是类图，这也是工作量最大的一块，我们的要求是如果 DTO 这种，要列出所有字段和类型，如果是 serivce 这种要列出方法级的调用链，比如最上层是 controller ，然后往下调用 service ，再往下 repository ，再往下 mapper 这种。其实就是把项目里的类名复制到画板里，用箭头连起来。这些花了大力气的类图评审的时候大概率就是讨论下字段命名是否规范、类型的定义是否正确、层间调用是否合理等代码层面有没有遵守规范，这种层面的设计和讨论，认为完全没有必要，特别是工期特别紧的时候。因为评审与否对代码质量影响不是决定性的，即使过了评审最终交付的代码也会跟设计有差异，不如把设计和评审的时间用于代码 review ，而且这部分代码都是内部逻辑，随时可以重构，代价也不高。另外一方面，我们是自研产品，代码架构已经成型，新需求就是给产品添砖加瓦，而且做设计和写代码的大概率是同一个人。然后就会出现一些有意思的情况，有人会先写代码后做设计、也有人画图画了 2 天，代码半天写完了。设计变成了应付交差，为了设计而设计。不知道你们是如何看待设计这件事的，欢迎参与讨论。希望大家讨论时聚焦具体领域和场景，本次特指：后端开发，自研产品。其他领域的侧重点和情况可能不一样，观点不具有普适性。
起因是公司有个惯例，研发前需要做详细设计并且评审。设计包含 REST 接口和参数、模型和字段、行为模型调用层次、时序图、数据库表结构设计，大概就是类似 UML 那一套。部分设计还需要包含各种条件分支、异常处理的逻辑。达成目标就其他人拿到这个设计文档后不需要太多沟通就可以完成开发。
每次做新需求，这个阶段是最痛苦的，我个人非常抵触。我倒不是抵触研发前设计这个步骤，我是抵触性价比不高的过度设计。
我们做设计的目的是为了对齐前后端、各服务之间的想法，防止出现方向性错误。所以我认为 REST 接口和表结构是必须要提前设计的，一方面是因为有了 REST 接口前端才可以提前介入开发，有了表结构大概能知道设计者对需求理解有没有大的偏差，两个结合起来大概就能知道这个需求如何实现了，另一方面，因为这两块重构代价太高了。如果是简单需求变更，这两样个人认为足够了。针对复杂场景可以适当增加时序图，这样评审的时候可以集思广益，帮忙查漏补缺。我最抵触的是类图，这也是工作量最大的一块，我们的要求是如果 DTO 这种，要列出所有字段和类型，如果是 serivce 这种要列出方法级的调用链，比如最上层是 controller ，然后往下调用 service ，再往下 repository ，再往下 mapper 这种。其实就是把项目里的类名复制到画板里，用箭头连起来。这些花了大力气的类图评审的时候大概率就是讨论下字段命名是否规范、类型的定义是否正确、层间调用是否合理等代码层面有没有遵守规范，这种层面的设计和讨论，认为完全没有必要，特别是工期特别紧的时候。因为评审与否对代码质量影响不是决定性的，即使过了评审最终交付的代码也会跟设计有差异，不如把设计和评审的时间用于代码 review ，而且这部分代码都是内部逻辑，随时可以重构，代价也不高。
另外一方面，我们是自研产品，代码架构已经成型，新需求就是给产品添砖加瓦，而且做设计和写代码的大概率是同一个人。然后就会出现一些有意思的情况，有人会先写代码后做设计、也有人画图画了 2 天，代码半天写完了。设计变成了应付交差，为了设计而设计。
不知道你们是如何看待设计这件事的，欢迎参与讨论。
希望大家讨论时聚焦具体领域和场景，本次特指：后端开发，自研产品。其他领域的侧重点和情况可能不一样，观点不具有普适性。