如何做好技术评审
当前工作中，平均每周要参加 1~2 次技术评审工作，每个业务线团队的评审会参差不齐。有些评审会信息传递清晰、高效，过程非常愉悦，大家也能参入其中并理解和汲取所需。有些评审会冗长、混乱，那些应该覆盖的信息大量缺失，评审会完成依然“不知其所云”，参与评审的人经常没有参与感。
技术方案的本质是从技术视角出发提供的问题域的解决方案，技术方案评审的本质是一个协作决策过程，通过干系人共同参与，从多维度评估待评审的技术方案是否对问题域提供了合理、可行且最优的解决方案。
评估技术方案的完整性、正确性、合理性
**完整性 **要求方案不能对要解决的问题有所遗漏，不完整意味着不能满足需求。
**正确性 **要求技术方案能够对问题域提供解决方案。
合理性 则要求不仅仅关乎”正确“和“完整”，其要求在特定的上下文中多个因素间的平衡，比如，时间成本、资源投入成本、技术实现成本等多因素平衡。
技术评审中，以下角色应该各司其职，深度参与
架构师/TL
- 整体技术方案的架构合理性和一致性
- 横向架构属性满足度：可扩展性、可维护性、性能、安全、合规性等
- 对现有系统架构的影响评估
- 工期与技术成本的合理性
- 技术栈选型与团队能力的匹配度
产品品经理
- 功能性需求的实现是否覆盖
- 用户敏感的非功能性需求的实现是否覆盖
- 业务概念的一致性
- 产品视角的安全：敏感信息明文/密文存储与反显；敏感数据泄漏；资损等等
- 系统状态机是否满足业务状态机要求
测试工程师
- 方案的可测试性
- 是否需要压测
- 变更影响需要回归的范围
技术评审文档模板
业务上下文
同步业务相关信息，区分事情的重要和紧急程度；包括但不限于业务的整体背景、ROI、长期和短期目标、产品方案等
技术上下文
第一个维度，提供当前系统现状的技术背景说明，包括但不限于整体技术架构、系统部署架构 第二个维度，架构师基于对业务、产品、技术现状及诉求的理解，分析当前重点衍生的技术需求，作为产品需求在技术视角的补充，包括但不限于诸如技术安全、业务安全、性能要求、规模要求，目的是尽量避免技术需求的遗漏，以及为关键的部分预留可迭代的空间；
技术安全：功能安全、数据安全、存储加密、传输加密、签名验证、防伪造和篡改的问题，要防范安全漏洞。
业务安全：多个业务共享数据时需要重点考虑，事务安全、保证一致性、要预防黑产攻击。
概要设计
对系统的宏观问题提供解决方案，典型的元素包括： 1.整体方案选型：基础设施选型、技术栈选型、子系统拆分及交互的高层选型等等
2.应用架构及其变更
3.技术架构：系统稳定性、性能、安全性的方案选型
详细设计
这部分信息是领域实现的设计，关注领域内的元素和他们之间的关系。一般是根据领域进行分工，各领域可以独立完成设计；目的是把控质量、指导开发，降低后期的风险；典型的包含以下元素： 1.领域模型
2.交互流程
3.领域实体状态机
4.数据模型
5.关键协议
6.接口设计
7.监控/验证及灰度
影响分析
描述当前设计方案对系统、业务、团队所带来的影响
风险评估
目的是为了消除问题，避免小问题可能变成大问题，因为在实际情况下，很多出现的问题都是曾经考虑过但是又被忽略的问题
决策过程
技术方案的设计过程是进行权衡分析的过程，方案中应该对过程所做决策进行留存记录。
以上根据实际情况，进行适当裁剪
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！