好的详细设计能提前暴露问题，减少研发中返工的概率

昨天有一个刚参加工作不久的初级软件工程师，向我请教一个工作中的问题，即遇到了一个挑战很大的开发任务，不知道该如何应对？即领导直接下达了一个有Deadline的任务，但这个任务实现难度有点大，除了技术本身，作为后端，还需要协同算法和前端，因此对于初级工程师还是有些挑战。那么遇到这个问题该如何应对呢？

其实很简单，那就是不要急于写代码，而是应该先做详细设计。

一个概念

在阐述详设前，有一个概念需要清楚：

需求是描述系统做成什么样，而详细设计描述如何来实现这个系统，而对应的岗位就是PM和RD。而这句话基本也定义了岗位之间的边界，系统做成什么样由PM说了算，如何实现由RD说了算。

因为我经常遇到，在需求发布会时，研发一直在讨论或者阐述需求应该是什么，不应该是什么？虽然RD可以提意见，但是最终由PM来决定系统做成什么样。这个边界如果模糊的话，往往讨论就会很紊乱，吵成了一锅粥。

PM：产品经理，RD：研发工程师。

什么是详细设计

详细设计也叫做技术调研，它是在有了明确的需求后，需要将需求做拆解，进行技术调研，确认实现的技术方案。往往技术方案会有多个，这里建议给出3个，并给出推荐选用哪个方案。给出接口协议和数据库设计，可初步写出一些Code，做一些技术点的验证。

这里按照我的过往经验，给一个大致的详设模版。

背景

• 需求的描述和拆解

技术方案

• 给出下列方案的优劣势，以及推荐哪个方案等

方案1（推荐）

• 描述整体架构、实现思路，最好以图的形式来展开，一图胜千言。

方案2

同上

方案3

同上

接口协议

• 前后端、后端和算法的接口协议

数据库表设计

• 表字段，存储资源评估等

排期

• 以表格形式来展示

风险

• 列出可能存在的风险和三方依赖

以上内容基本就把实现方案讲的比较清楚了，最后的排期和风险是非常有必要的。

排期用来给出一个客观的工时预估，可以留一些冗余，防止意外问题出现，导致一些Block的点。

风险主要是提出实现过程中，可能会碰到的一些不可控的事项，与大家达成共识。

有了这个评估后，Leader如果去强压一个不靠谱的排期，那么详细设计就可以起到辩驳的作用，且很科学，有理有据。

详细设计完成之后，可以发起评审会议，评审人员一般需要拉PM、QA和相关的研发人员。评审会议中，可以讲述自己的详设，并听取大家的意见，如果有一些建设性的意见，且自己没有考虑到，可以记录Todo，后续升级详设。

对于评审意见，需要分清楚哪些是好的建议，哪些是差的建议，对于前者就采纳，后者要摒弃。如果出现有争议的情况，那么建议经过思考和后续调研后，再给出结论。往往在评审中，会有一种争议的情况，就是用A方案或者B方案均可，那么这种情况下，详细设计发起者是谁，就按照谁的意见来定，因为他是这个系统的负责人。

一般只要一个详细设计做的比较好的话，基本可以覆盖所有的需求细节，且包含了实现、排期和风险等内容，Leader基本就可以判断出这个需求的实现难度和人力。如果详细设计评审成功通过，那么接下来就开始写代码，并在写代码过程中，周期性的群里给大家同步进度，尤其是要给到Leader和上下游的同学，比如QA，联调方等，便于他们安排下一步工作。

详细设计的作用

那么详细设计的作用是什么？就是争取到合理的研发排期，保证研发可以安心的工作，不受Leader的随意Push，导致心态崩掉。

详细设计的排期基本是很靠谱的。我曾经在一次研发过程中，详细设计时，估算了5天的工时，但有一天，笔记本忘带到公司了，最终正好就延迟了1天，花了6天的工时。

软件领域有句名言：Deadline是第一生产力。详细设计排期时一定要把这个点评估进去，因为研发人员往往在Deadline的前一天，会爆发出超强的推进力和工作效率，最终来保障能够在Deadline到来前完成研发，进入下一个环节---提测。

对于初踏入软件领域的工程师，尤其是互联网领域，有了对详细设计的认知后，将会很好地提升自己的综合能力。