V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
beryl
V2EX  ›  程序员

如何写一个好的技术方案

  •  
  •   beryl · 2021-08-31 09:59:01 +08:00 · 5555 次点击
    这是一个创建于 940 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    2. 设计原则 /方案取舍

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

    4. 排期

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

    14 条回复    2021-09-05 19:27:38 +08:00
    Jooooooooo
        1
    Jooooooooo  
       2021-08-31 10:29:19 +08:00   ❤️ 4
    至少还得有:

    流量评估 (包括自身服务 /下游服务 /中间件等)
    上线方案 (如有上下游关联)
    监控方案
    降级 /灰度 /回滚方案
    beryl
        2
    beryl  
    OP
       2021-08-31 11:37:36 +08:00
    @Jooooooooo
    嗯,好像还漏掉一个,数据量级评估
    Jooooooooo
        3
    Jooooooooo  
       2021-08-31 11:41:45 +08:00
    @beryl 噢对, 容量评估.
    rapperx2
        4
    rapperx2  
       2021-08-31 11:44:29 +08:00
    已加收藏,坐等大佬回复
    weegc
        5
    weegc  
       2021-08-31 11:54:02 +08:00
    静待大佬补充
    hellotitan
        6
    hellotitan  
       2021-08-31 12:48:36 +08:00 via Android
    存储选型?
    sunmoon1983
        7
    sunmoon1983  
       2021-08-31 13:04:52 +08:00
    收藏备用,坐等大佬回复
    mcfog
        8
    mcfog  
       2021-08-31 13:19:02 +08:00 via Android   ❤️ 4
    我做过不少次关于这个话题的分享,也列过类似的提纲,但这些都是不太重要的“结论”而不是核心的“理论”

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

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

    基于这个理论和各个公司、部门、系统的不同情况,好的文档并没有一个统一的结构写法
    ChrisV5
        9
    ChrisV5  
       2021-08-31 13:44:55 +08:00   ❤️ 2
    小王,这有个需求,明天上线,今晚加个班。
    dany813
        10
    dany813  
       2021-08-31 14:17:41 +08:00
    收藏好多,哈哈
    namelosw
        11
    namelosw  
       2021-08-31 16:09:16 +08:00   ❤️ 4
    其实我觉得大部分流程都是些简单流程,最重要的就是把需求合理地定下来,然后就是设计核心的方案。业务方面就不献丑了,一般还是跟着业务人员节奏走。

    至于那些很机械的流程,又不给 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
        12
    taowen  
       2021-09-01 11:05:21 +08:00
    如何写一个”好“的技术方案,什么叫好,标准是什么?

    the design decisions that need to be made early in a project. whatever it is
    sha851092391
        13
    sha851092391  
       2021-09-01 18:35:38 +08:00
    需求说明
    +需求背景:简单介绍需求的背景情况,帮助看文档的人理解是解决什么问题的。
    +需求拆分:要想对一个大的东西进行有效分析,拆解就是分而治之的去分析,也更好的理解需求的范围。
    概要设计
    +系统现状:背景中想阶段的情况说明,或者说是现在系统的不足点。
    +总体思路:针对方案作一个概括性的说明,例如通过 xxx 技术解决该问题之类的。
    +系统架构:建议画图加描述性的文字说明更清晰,不然长篇大论看着都头大。
    详细设计
    +设计约定:统一描述语言,类似建模时对一下模型名称进行统一,方便之后的沟通。
    +功能实现:数据结构设计、接口设计、逻辑设计、系统交互等。
    +非功能性设计:就是扩展性设计、高可用等实现的说明。
    +方案选择:其实设计是针对其中一个方案进行设计,否则成本本大,这里从各维度对比几种方案之后,为啥选择这个方案。
    测试方案
    +影响范围:该方案影响访问了的描述。
    +用例:针对各功能点的用例清单,提供 ut 或者后续 qa 人员的参考。
    +注意事项:一些特别需要注意的情况或逻辑的说明。
    上线部署
    +环境准备:安装各种环境应用的描述和步骤。
    +应用准备:应用准备,脚本、sql 、初始化数据之类的文件。
    +发布步骤:发布应用一步一步的如果做,执行什么命令等。
    +线上验证:上线之后的回归验证流程吧。
    ychost
        14
    ychost  
       2021-09-05 19:27:38 +08:00
    技术方案一般设计与落地还是有出入的,一般只出个大体的方案,落地的时候才去完善细节,除了正常业务外,还有日志监控、埋点回流、效果分析等模块
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2795 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 15:27 · PVG 23:27 · LAX 08:27 · JFK 11:27
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.