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

[VeryZero]

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

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

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

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

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

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

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

[cybort]

先写代码再写设计也有意义，方便后续复盘和检查。

[shizhibuyu2023]

「把项目里的类名复制到画板里，用箭头连起来」。觉得「类图」工作量大就搞点提效的事呗，尝试写点脚本来搞呗，或者搞个工具画完类图直接导出代码（我估计有现成的）
从前端的角度来看非常值得，后端时间拉长，那前端延期的可能性就减小，也有更多时间摸鱼🤡

[godpeo]

矫枉过正，有些东西是在开发的过程中 发现问题后 需要不停修改的

[VeryZero]

@shizhibuyu2023
前端也要设计 😄

[shizhibuyu2023]

@VeryZero #4 没事，那点设计基本等于摸鱼，真要搞也有很多自动化工具和 AI 工具可以借力，不用动多少脑子，边听小说边搞都能搞定😎

[VeryZero]

@godpeo 这也是这么认为的，设计评审只是保证了大方向上没有偏差，不会出现开发完成后推倒重来的尴尬，但是具体代码实现上，只有真正开发了才能暴露出一些问题。

而规则制定者想让我们把在开发时才能遇到的问题在设计阶段就提前想到，这也是设计比较耗费精力的原因，很大一部分时间就是盯着天花板想有没有什么东西漏了。实际这些东西到了开发阶段都是水到渠成的事儿。

[hefish]

还是看领头的人。 快速迭代出可用产品，根据市场情况继续迭代，挺好。 精细化设计，然后仔细开发，减少回退，也没错。 看人，看情况。

[Hyschtaxjh]

听起来很日式

[lidongyooo]

如果楼主不是管理层，设计就设计呗。能多点时间摸鱼，也能减少工作差错的可能性，何乐而不为。况且这种形式的工作做多了，何尝不是工作技能的提升。总有些时候是会要用到这些东西的。

[dlmy]

为什么要在研发前花费大量精力做详细设计呢？

现实中一般都是先去做，手上有了东西才能出去吹：
1 、写概要设计，然后开始写代码，先做一个 MVP 版本（最小可行性产品版本）出来试试水
2 、根据市场反应，调整产品业务发展方向，研究变现通道
3 、包装产品，写详细设计，搞一些高大上的名词跟架构图上去
4 、后续基于 MVP 版本进行业务的快速迭代跟开发

[crackidz]

写完就丢的代码可以不做设计

MVP 代码切忌过度设计

需求明确的瀑布开发需要详细设计

不可混在一起说，换句话说就是你需要根据情况取舍

[zzzzzzggggggg]

值得

[yufeng0681]

这种具体案例，在内部讨论简化，更有目标性。
我的观点：要做详细设计，但是不要变成为了做而做。
1 、复杂的算法要做详细设计，充分讨论
2 、业务逻辑可以按简化的规则落实写作

[sb137885]

有必要

[akira]

等你去到一家 需求就一句话，然后直接让你开工的 公司，你就知道这种有设计的是多么的舒服

[laminux29]

1.一个大型项目，详细的设计文档、专家评审、财务规划、人力规划、时间安排、小规模试错、难点攻关等等，这些都是前期阶段重要的工作流程，也是保障项目成功率，保障项目质量的必要环节。

2.如果你工作的方式，是凭兴趣来，这么显然这家公司的工作方式，不适合你。如果你想玩那种完全随自己意愿的开发，建议你自己去做开源软件，这样就完全由你一个人把控了，想怎么搞就怎么搞。

[xiaofan2]

这里的权衡点我觉得是看粒度 比如类图类似的在实际迭代过程中实际上会不断变化 而领域涉及、数据库库表设计、接口设计这种在实际过程中变动不会很大 这块值得详细设计

[xiaofan2]

另外还有一点 设计出来的文档是否在后续迭代的过程中不断地迭代，这其实才是最难维护的点，需要开发额外的自动化机制来保证。至少在我经历的公司中，文档维护的很好的公司基本上没有....

[charlie21]

只做一旦 bug 出现了有助于快速定位 bug 在哪里的事

[nbhaohao]

值得, 想象一下新员工入职, 如果有设计文档, 那么给新员工入职介绍项目的时候, 也会很轻松, 反之只能让新人自己看代码, 而且随着项目时间推移, 没有人能够记住所有细节, 比如这块为什么这么设计.

[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]

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

[Leonkennedy2]

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

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 概要设计是咋写的？

[murmur]

@unregister 我们实际上写的就是文字的需求描述、界面设计、技术选型，没有什么概要设计了，这玩意改个名就是技术方案给用户签字的

[txhwind]

1. 首先看公司需求，需要快速迭代做 MVP 的肯定不适合，如果对可用性、稳定性要求高的，多花时间在文档上也不过分。
2. 具体形式可以商议，类图感觉是没太大用，不如用文档模版+自然语言。

[powerman]

@VeryZero #38 这说明你们 leader 还是不行啊，既然选了中式开发，那就要猪突猛进，什么注释啊，什么设计啊，什么设计模式，什么表结构啊，设计个屁，中式开发要求的是速度，怎么快怎么来，狗屎代码往上糊，功能满足就 OK ，反正等到项目上线，后期维护，debug ，人早跑没了，吃屎的都是下一波人了，这一波项目赶紧上线，PPT 吹一波，工资奖金到手，下半年 是不是还在这个坑里面 揾食都不知道

[andytao]

> 1.清晰的答案来自实践，而非空想。
> 2.先实现，后优化。
很喜欢这两句，感觉很接地气；
@Leonkennedy2

[isnullstring]

动手前花大量时间做设计，说明团队很大，小团队根本没这个时间也耗不起
团队大越害怕出现方向性的错误、个人理解出较大差异，所以宁愿一开始错好过后面错

都在大小团队待过，大团队舒服但是容易养废（习惯需求嚼烂喂到嘴边），小团队难受但是学到更多（天天被催，事事找你）

[lazydog]

你们这个风格看着有点像百度的风格。做好详细的记录是好事，可以根据需求大小、重要性等做动态调整。我们公司内部差不多也是这样，设计前 Leader 会根据需求特征来沟通你的技术方案大体一个什么走向（他个人比较在意画图这些），但是不会一刀切。因为涉及到多个团队合作的时候，如果对方团队临时变更一下方案，那我们这边的技术方案也可能需要重新设计，成本也会比较高，最终的需求可能就会倒排了。

[godloveplay]

@lidongyooo 非常实用主义👏

[wyfig]

个人感觉这种做法没有问题并且非常有必要的。 我们目前公司小作坊模式，别说设计类图什么的，我们产品经理岗位老板都觉得是多余的。 想做个什么功能，需求方都描述不清楚，就问我们多久可以干完。 具体怎么干，自己去摸索。经常出现的情况就是，功能开发完了需求方不知道这个是干什么的，别说方向对不对了，反正就是一团麻，公司倒闭指日可待。。。。

[kamilic]

中华田园敏捷就不要既要又要了 🐶

[woodfizky]

我司现在就在吃前人留下的流程不完善导致的各种亏，你显然是身在福中不知福。。

一般来说你在前面的环节省的时间精力等资源，后面出现问题会狠狠的给你把这部分资源再重新吃掉，骨头都不吐。

设计上节省，那后续就会有设计不满足要求等问题。项目没有名为"设计"的脊梁，是很难变成有健壮性的项目的，后续你会浪费各种时间救火+修 bug 、然后复盘、然后优化(shi 上雕花)或者重构(不太可能)。

测试上节省，那自然潜在的问题到生产环境才暴露，在生产环境救火+修 bug 那难度可比测试环境大多了。

验收上节省，那后续用户出尔反尔你又没话说了。

所以我觉得是值得的，除非你有自信在节省那些你觉得"没有性价比"的环节之后，还能有把握不出现那么多问题，不然我觉得该有的都要有。

[changf]

事实上，中式开发是不存在“先实现后优化”的时间，除非导致了严重的生产问题，才会排期进行优化。问题在软件生命周期暴露阶段越靠前，解决成本越低。
因此前期的详细设计，非常重要。这对项目质量管理有重要意义。当然不能排除所有问题，能尽量早地暴露问题就足够了。团队的力量远比一个人靠谱，有的程序员盲目自信，上去就干，遇到困难就抱怨：都是前人写的屎山。殊不知，屎山正是无数上去就干，不经思考的人积累下来的。
另一方面，详细文档其实价值不大，它只是大伙思考结果的一个形式。但是领导需要这么个形式，来确认下属有按照规范流程开发。各人的文档水平不一，不好说能传递多少有效信息，而且需求后续的不断迭代，文档的更新维护也需要耗费大量人力。所以文档的核心作用不在于给干活的人看，而是给领导看的。
总结一下，时间若充足，详细设计+详细文档；时间不足，详细设计+简略文档。详细设计对质量管理有重要意义。

[xubeiyou]

这种东西说白了就是方便交接- - 方便更好理解代码的

[wanniwa]

工时给够就行了，但是确实中间层的那些 dto 都评审，看来还是主管比较闲，想掌控项目的每个细节，也不是坏事

[sampeng]

值。。研发经常干那种开发一个月，扔那 1 年不管的项目的。

[yuruizhe]

半天开发完的代码，还要做设计啊，太浪费时间了

[lingo]

值得。一个人包揽设计、前端、后端的项目我都觉得这样做是值得的。

[yyqxjwxy]

我司就是流程不规范，一个深圳的沙雕领导对技术狗屁不懂，刚来就扔给你十几个页面肝，一年了项目上不了线，楼主真是身在福中不知福啊

[Haku]

项目越大，设计越值得，项目小到工期不超过 3 天的个人觉得可以不设计

[ala2008]

我们只有技术评审，简单的就不用