最近看了一篇文章，文章中提到在开发流程中包含一个设计方案的阶段，位于需求评审之后，用于描述自己对于该需求的实现思路、模块划分等相关考虑的点，可供今后自己或他人查阅。
目的就是在编码前理清思路，整体架构，查缺补漏，作为他人或自己的技术参考文档。
自己在项目开发的过程中，也曽有过这样类似的想法，但没有作者那样写的系统，也没有在团队中落地。
基于文章中的设计方案，自己做了点修改。设计方案包括4个部分：需求、调研、实现和复盘。
1）需求
在设计方案的开头，列出相关人员（便于精确找人），需求信息和各类时间。
需求背景：因为我们要做线下推广，提高xxxxxxxxx PRD：产品文档链接 产品：老吴 UI：梨子 测试：小木 前端：隽隽 服务端：必煦 联调时间：2021.07.30 提测时间：2021.07.31 上线时间：2021.08.10
2）调研
功能的技术选型，对比不同方案的优缺点，适当取舍，形成一套适合当前场景的最优方案。
以复杂动画为例：
- 自己之前有没有做过类似的动画，可以借鉴？
- 公司内部有没有自制的动画库，可以引用？
- 业界有没有现成的动画库或不错的实现思路，可以参考？
- 用原生实现，与遇到哪些问题，兼容会不会很困难？
- .........
3）实现
需要思考很多方面：业务的完整流程、数据结构的设计、关键功能的逻辑描述、异常处理、安全、性能、与现有业务的耦合情况、组件复用等。
保证自己和他人在看到这份方案时，能清楚明白你的设计思路、代码意图和模块划分。
可用任意方式表达自己的思路，例如伪代码、图表或纯文字等。
流程图让自己和他人对需求有个直观的了解。
伪代码在不写具体代码前，展示自己的编码思路，传达代码意图，即使是不会代码的人也能读懂，给你点意见。
function getSomeData() { let data; if(无缓存) { // 请求数据 if(请求异常) // 展示错误页面; data = 请求到的数据; } // 展示页面 }
模块划分是架构的一个点，需要考虑哪些是独立模块、哪些是公共模块、哪些是与业务耦合的模块。
用例图可整理出大大小小的场景，在列出后就会发现流程中缺少的部分，以及各种未考虑到的边界。
还有安全问题，例如防止恶意的接口访问。页面中是否有性能问题。未来若扩展需求，那么当前设计的扩展性是否能满足需求的变化。
4）复盘
复盘总结的内容可自由发挥，按照自己的实践，记录与需求相关的一切，例如：
- 撰写方案时遇到的问题，以及解决方案。
- 代码上线后，收到的反馈，做的好的方面和做的差的方面。
- 别人在做设计方案时，有什么值得学习的地方。
- 在整个项目开发中，流程中的哪个点处理的不好（例如低效无用的沟通等），之后讨论改进方案。
- .........
posted on
