对事不对人. 参与评审的各方是平等的, 各司其职. 项目是服务于公司业务的.
再牛的人, 讨论技术方案, 也要以理服人.
系统是满足需求, 实现业务功能的. 大家都是为了能查漏补缺才坐到一起. 出了问题, 共担责任, 不能置身事外.
架构评审
本质上架构评审跟测试相同, 都是为了保证质量.
评审过程中会讲到实现的关键点. 因此有些相关人员也会参与了解, 比如测试, 数据, 安全等.
架构评审的目的是什么:
- 把关. 确保方案合格, 避免缺陷和遗漏. 不求方案多牛, 至少不要犯错.
- 保证架构设计合理, 符合整体原则.
- 维持对系统架构的全局认知, 避免黑盒效应.
- 通过评审发掘创新亮点, 推广最佳实践.
设计方案不仅仅是考虑功能实现, 还有很多非功能需求, 以及持续运维所需要的工作, 需要的工程实践, 进行平衡和取舍.
方案评审
要先交代需求背景.
为什么要做这个需求, 对于实现的要求是什么.
一个技术方案的好坏与实现要求息息相关, 是不能脱钩的.介绍技术方案整体架构.
先总后分, 先从整体介绍架构设计. 有哪些模块, 各自负责什么职责, 如何衔接. 让大家有个整体认知.
整体架构的描述用架构图, 流程图, 加上简练的语言, 交代明白即可.介绍协议, 库表设计.
分清哪些协议, 表是重要的, 着重讲, 其他不太重要的快速讲.描述分支和异常逻辑, 讲解代码.
一份代码写的好不好, 程序员是否有经验, 主要是看对于异常处理是否到位.复盘.
每次评审后, 要自己复盘, 总结.
方案评审重要的不是你说完, 而是别人听懂. 关注台下人的反应, 你的任务不是讲, 而是让大家听明白.
Refs
算法讲解
尽量不要生硬地摆上好多公式. 更好的方法是用图的方式表达公式和算法思想. 听众更易接受.
- 算法的应用背景.
- 相关研究. 与其它算法的对比等.
- 算法主要思想, 流程图等.
- 关键思想的详细讲解.
- 实验结果.
若有收获，就点个赞吧
0 人点赞
