如何写一个好的技术方案

[beryl]

以设计一个 V2EX 的某个新功能，例如节点订阅需求的技术方案为例子。那么这个技术方案应该分位几部分呢？

1. 需求描述
   1.1 背景
   1.2 业务场景

2. 设计原则 /方案取舍

3. 总体设计
   3.1 核心流程(数据流)/模块关系
   3.2 核心实现
   3.2.1 数据结构定义
   3.2.2 接口协议定义

4. 排期

个人理解这些是必备的描述，除此之外还需要更多和业务相关的设计

[Jooooooooo]

至少还得有:

流量评估 (包括自身服务 /下游服务 /中间件等)
上线方案 (如有上下游关联)
监控方案
降级 /灰度 /回滚方案

[beryl]

@Jooooooooo
嗯，好像还漏掉一个，数据量级评估

[Jooooooooo]

@beryl 噢对, 容量评估.

[rapperx2]

已加收藏，坐等大佬回复

[weegc]

静待大佬补充

[hellotitan]

存储选型？

[sunmoon1983]

收藏备用，坐等大佬回复

[mcfog]

我做过不少次关于这个话题的分享，也列过类似的提纲，但这些都是不太重要的“结论”而不是核心的“理论”

理论很简单，想明白你的这个{技术,发布,架构, anything}方案 /文档的目标读者是谁，他（们）经常关注的重点 /痛点是什么，你们作为研发要同步给他们的信息是什么，把这些信息分门别类记录下来（因为你不会准备 10 份文档给 10 个部门看），就是一份好的技术文档。

另外别忘了目标读者还有一个是同一个需求的其他开发，同一个项目下一个需求的开发，也很可能包括 2 个月后的自己

基于这个理论和各个公司、部门、系统的不同情况，好的文档并没有一个统一的结构写法

[ChrisV5]

小王，这有个需求，明天上线，今晚加个班。

[dany813]

收藏好多，哈哈

[namelosw]

其实我觉得大部分流程都是些简单流程，最重要的就是把需求合理地定下来，然后就是设计核心的方案。业务方面就不献丑了，一般还是跟着业务人员节奏走。

至于那些很机械的流程，又不给 KPI，该挑战就挑战，挑战失败就按着方子走就行了。

---

技术设计方面

我个人经验，设计方案我觉得比较好用的一个东西是 Event Storming/事件风暴，就是找几个人一起设计，带上业务人员，在白板上一边贴条一边讨论，产出是一套技术设计。

虽然 Event Storming ​DDD 社区用得比较多，但是我感觉普通建模也很有用。概括一下基本就是：
1. 用事件驱动的思路把系统里会发生的所有事情在白板上贴条
2. 然后想想这些事件怎么来的，大多都是用户操作 /命令 /Command
3. 贴完了按这些事件和命令建模，设计好系统里的数据模型 /聚合，也贴回白板上
4. 最后按照聚合之间的相关性划分模块，小系统就是代码里的模块，大系统就是微服务之类的

这个过程基本上可以看做一个收集需求，然后按需求，在白板上设计系统并重构的过程，好处：
1. 过程很容易找出业务上遗漏或者自相矛盾的地方
2. 不那么纠结，列事件就是大家七嘴八舌往上贴，这时候不用想设计
3. 事件到模型的建模是核心工作，已经把其他几个步骤分离出去了，这样基本就在专心解决一个封闭问题，更容易做快做好
4. 建模的时候还有机会在白板上重构，比重构代码容易多了
5. 模型贴出来之后，哪些跟哪些关系更紧密一目了然，划分系统画圈就行了，总比拍脑袋强
6. 其中 Command 就约等于 API，模型就约等于 DAO 之类的东西，这两样有了系统基本水到渠成了。写文档啥的都是机械劳动，分出去做一做就好了

---

排期方面

这个我理解其实不算技术方案的范畴，但是还挺重要的。最理想的是不排期只关心 WIP，然后每天站会看看，有没有人遇到困难需要帮助。

如果非得要排期的话，比较好的还是拆任务估点，就是复杂度 1 2 3 5 这种：
1. 设计人员列出所有任务，然后尽量把任务拆得越碎越好
2. 然后叫上实现人员，每个任务先讲明白要做什么
3. 大家估计复杂度 1 2 3 5 这样的点数，想好了之后像石头剪刀布一样出个点数，然后讨论一下定下来一个大家觉得合理的点数
4. 一般尽量不搞 3 5 这样的复杂任务，碰到 3 或者 5 可以试着拆成更小的独立子任务，实在拆不了再用 3 5
5. 这样做一两个月以后，就会大概对每个点要做多久有个估计，可能有的团队半天，有的团队两天，然后乘以点数就行了。养成习惯之后，时间越长月好估算。

这种方式的好处：
1. 拆得够碎会强迫你把系统在纸上实现一遍，才会发现很多少想的东西，不搞清楚直接排期害人害己
2. 把组员喊上一起估计，会考虑到组员的平均实力，而不是按 lead 或者大牛的工作效率定
3. 因为有点数，所以在一半的时候就很容易知道是不是落后于排期，该砍掉没用的东西，该加人帮忙都尽早，很多事情早了其实都好说。如果时间很超前还可以搞搞重构，或者腾出来时间带着大家学习或者造造轮子啥的。避免总是前期摸鱼，后期赶 deadline 的不健康节奏。

另外实践这个方式的一个常见问题就是太忙，牺牲了拆任务和估点的质量，凑合凑合就完了，结果就陷入了导致下个月更忙的死循环。所以做这个一定要挤出时间认真做，不要偷懒。

[taowen]

如何写一个”好“的技术方案，什么叫好，标准是什么？

the design decisions that need to be made early in a project. whatever it is

[sha851092391]

需求说明
+需求背景：简单介绍需求的背景情况，帮助看文档的人理解是解决什么问题的。
+需求拆分：要想对一个大的东西进行有效分析，拆解就是分而治之的去分析，也更好的理解需求的范围。
概要设计
+系统现状：背景中想阶段的情况说明，或者说是现在系统的不足点。
+总体思路：针对方案作一个概括性的说明，例如通过 xxx 技术解决该问题之类的。
+系统架构：建议画图加描述性的文字说明更清晰，不然长篇大论看着都头大。
详细设计
+设计约定：统一描述语言，类似建模时对一下模型名称进行统一，方便之后的沟通。
+功能实现：数据结构设计、接口设计、逻辑设计、系统交互等。
+非功能性设计：就是扩展性设计、高可用等实现的说明。
+方案选择：其实设计是针对其中一个方案进行设计，否则成本本大，这里从各维度对比几种方案之后，为啥选择这个方案。
测试方案
+影响范围：该方案影响访问了的描述。
+用例：针对各功能点的用例清单，提供 ut 或者后续 qa 人员的参考。
+注意事项：一些特别需要注意的情况或逻辑的说明。
上线部署
+环境准备：安装各种环境应用的描述和步骤。
+应用准备：应用准备，脚本、sql 、初始化数据之类的文件。
+发布步骤：发布应用一步一步的如果做，执行什么命令等。
+线上验证：上线之后的回归验证流程吧。

[ychost]

技术方案一般设计与落地还是有出入的，一般只出个大体的方案，落地的时候才去完善细节，除了正常业务外，还有日志监控、埋点回流、效果分析等模块