研发前花费大量精力做详细设计值得吗？

[VeryZero]

最近一直在思考这个问题，希望跟大家讨论一下。

起因是公司有个惯例，研发前需要做详细设计并且评审。设计包含 REST 接口和参数、模型和字段、行为模型调用层次、时序图、数据库表结构设计，大概就是类似 UML 那一套。部分设计还需要包含各种条件分支、异常处理的逻辑。达成目标就其他人拿到这个设计文档后不需要太多沟通就可以完成开发。

每次做新需求，这个阶段是最痛苦的，我个人非常抵触。我倒不是抵触研发前设计这个步骤，我是抵触性价比不高的过度设计。

我们做设计的目的是为了对齐前后端、各服务之间的想法，防止出现方向性错误。所以我认为 REST 接口和表结构是必须要提前设计的，一方面是因为有了 REST 接口前端才可以提前介入开发，有了表结构大概能知道设计者对需求理解有没有大的偏差，两个结合起来大概就能知道这个需求如何实现了，另一方面，因为这两块重构代价太高了。如果是简单需求变更，这两样个人认为足够了。针对复杂场景可以适当增加时序图，这样评审的时候可以集思广益，帮忙查漏补缺。我最抵触的是类图，这也是工作量最大的一块，我们的要求是如果 DTO 这种，要列出所有字段和类型，如果是 serivce 这种要列出方法级的调用链，比如最上层是 controller ，然后往下调用 service ，再往下 repository ，再往下 mapper 这种。其实就是把项目里的类名复制到画板里，用箭头连起来。这些花了大力气的类图评审的时候大概率就是讨论下字段命名是否规范、类型的定义是否正确、层间调用是否合理等代码层面有没有遵守规范，这种层面的设计和讨论，认为完全没有必要，特别是工期特别紧的时候。因为评审与否对代码质量影响不是决定性的，即使过了评审最终交付的代码也会跟设计有差异，不如把设计和评审的时间用于代码 review ，而且这部分代码都是内部逻辑，随时可以重构，代价也不高。

另外一方面，我们是自研产品，代码架构已经成型，新需求就是给产品添砖加瓦，而且做设计和写代码的大概率是同一个人。然后就会出现一些有意思的情况，有人会先写代码后做设计、也有人画图画了 2 天，代码半天写完了。设计变成了应付交差，为了设计而设计。

不知道你们是如何看待设计这件事的，欢迎参与讨论。

希望大家讨论时聚焦具体领域和场景，本次特指：后端开发，自研产品。其他领域的侧重点和情况可能不一样，观点不具有普适性。

[garyLin]

沉淀设计文档有利于团队内信息共享，避免了某块业务逻辑只有某个人才知道，作为团队 leader 的话希望减少人员上手成本，减少换个人就重写的情况，其实是减少 leader 的管理成本，也是一种管理手段。

对于我来讲，写代码前必须先写一些设计的文档，更偏向于整体性的视角，比如核心流程怎么做，整体的架构是怎样，服务间的关系等，细粒度的比如表设计，就直接链接代码了。到了实际实现过程中还得回头来修改设计文档。这个对我来说是利己的事情，有下面几点好处：

1. 希望其他人有兴趣能够很快参与进来，减少我的开发时间
2. 后面去做其他事情了，减少其他人来询问，避免打扰
3. 向上汇报时候，上级可以看到你思考的过程和结果，对晋升也有帮助

针对 OP 说的类图耗费时间问题，我也同意，确实很耗时。不过如果领导确实不好妥协，看看有没有插件由代码生成类图的工具吧。

如果 OP 实在伤脑筋，不妨找 leader 好好反馈商量一下。

[wu67]

看是什么功能.
如果是确定以后会反复利用的组件/模块, 我会花半天到一天时间考虑流出来的接口或者 prop;
不会反复利用的, 写到哪想到哪, 炸了再说

[levelworm]

得看自己有没有能力进行设计。

[mark2025]

我最抵触的是类图，这也是工作量最大的一块，我们的要求是如果 DTO 这种，要列出所有字段和类型，如果是 serivce 这种要列出方法级的调用链，比如最上层是 controller ，然后往下调用 service ，再往下 repository ，再往下 mapper 这种。其实就是把项目里的类名复制到画板里，用箭头连起来。这些花了大力气的类图评审的时候大概率就是讨论下字段命名是否规范、类型的定义是否正确、层间调用是否合理等代码层面有没有遵守规范
========
精细到类图在当下快速迭代互联网应用场景下有点重了。 能规划好 接口名、 接口的入参、出参 DTO 、时序图就已经很不错了。

[bsg1992]

如果时间上给的时间比较充足，做详细设计没有任何问题。
按我个人习惯 时间够我肯定会做一下详细设计 接口文档 数据库设计 业务实现以及组件设计

[rencoo]

挺好的啊

[TenProX]

肯定没什么问题。主要看你们有没有一个良好的协作。

[Abbeyok]

我觉得除非是特别明确市场的，不然都先做出来

[IvanLi127]

做详细设计本身是不会有错的，错的是工期不足和人手不够。
愿意拿实现当详细设计的，要么项目轻松秒杀，要么根本没时间设计，只能摸着石头过河。
反正现代语言都能快速编码和验证，不在意反复返工的话不做单独的详细设计也没啥事。拿代码说话也挺快的，除非要和看不懂这份代码的人交流...

[8E9aYW8oj31rnbOK]

我非常喜欢这个视频，尤其是评论区里总结的，

https://www.douyin.com/video/7377036466293181731

“概括来说就是：行动带来最优解，而非思考。你思考过后的所谓完美方案通过行动验证后很大概率不是最好方案，而行动后迅速调整才能不断逼近所谓的最优方案”

“1.清晰的答案来自实践，而非空想。
2.先实现，后优化。”


“每一个选择，都是对路径的修正；每一个路径，都是对目标的探索。思考构建理想，行动实现理想。辩证地看行动中的每一次失败，都是思考中的宝贵经验。”

“程序往往是综合性的，即使答案百分百正确，效率过差，结果往往也是无法忍受的。因此先寻求局部最优解，在不断迭代，达到预定迭代要求后，可以在保证正确率的程度上，也可以满足效率，答案可能不是全局最优，但已经达到了程序最优。”

[powerman]

这就是中式开发的问题了，又要快又要好，多快好省，楼主明显抵触的不是详细设计，楼主抵触的是给的工时时间短，但是却要浪费在这些看似可有可无的事情上，然后用自己的加班时间来完成代码，简而言之就是不给钱，但是又要出细活，还要加班干，这才是中式开发的经典矛盾

事实上，详细设计跟评估是很有必要的，前提还是，时间得给够，有足够的时间去想，去调研去评估，去思考去设计，而不是上来闷头就写一堆狗屎

[leegradyllljjjj]

我们也是，crud 不知道有什么好设计的，只是在流程上出了一个文档

[boqiqita]

去掉类图，减少 3 天时间，review+重构，增加 5 天时间

[matrix1010]

DB schema 可以自动生成，流程图要是大部分服务一样没必要画。设计重点该关心的是每个功能/需求的定制化部分。如果是非常基础的 CRUD 则没什么必要做详细设计

[sumu]

从打工者的角度看：如果是新手，那必须花时间，如果工作了多年，那纯纯浪费时间。
从管理者的角度看：越详细越好，不要害我背锅，反正工资不是我出
从公司角度看：无所谓，做出来有没用鬼知道，但不能让人闲着，闲着会出事的

[VeryZero]

@boqiqita 实际情况可能是画类图，增加 3 天时间，review+重构，增加 3 天时间。
根据之前的情况，设计只是指导开发，并不是一模一样，等开发时遇到问题产生的设计变更也不会同步到设计文档上。设计文档基本都是一次性的，除非对同一个需求做了二次迭代，有可能会对同一个设计文档做迭代。

[VeryZero]

@nbhaohao 想象中是这样的，而且事实相反，我刚到公司的时候拿到设计文档是懵逼的。连写这份文档的人自己都懵，最后还是靠代码来自己梳理。现在 IDE 这么牛逼，阅读代码的效率其实很高。主要问题在于梳理完的东西都在脑子里，时间长了会忘记，也没法沉淀分享给别人。我的解决方案是使用 NotionAI ，把经常遇到的问题整理成知识库，遇到问题直接问 AI 就可以了

[VeryZero]

@powerman 一语中的。项目转测时间已经定了，时间明显不够，为了赶进度人人都 996 ，还要花掉一半的时间做设计。

[duluosheng]

大项目是值得的，小项目前期先快速试错

[unregister]

@dlmy 概要设计是咋写的？