从零开始搞基建（3）——设计方案

　　最近看了一篇文章，文章中提到在开发流程中包含一个设计方案的阶段，位于需求评审之后，用于描述自己对于该需求的实现思路、模块划分等相关考虑的点，可供今后自己或他人查阅。

　　目的就是在编码前理清思路，整体架构，查缺补漏，作为他人或自己的技术参考文档。

　　自己在项目开发的过程中，也曽有过这样类似的想法，但没有作者那样写的系统，也没有在团队中落地。

　　基于文章中的设计方案，自己做了点修改。设计方案包括4个部分：需求、调研、实现和复盘。

1）需求

　　在设计方案的开头，列出相关人员（便于精确找人），需求信息和各类时间。

需求背景：因为我们要做线下推广，提高xxxxxxxxx
PRD：产品文档链接
产品：老吴
UI：梨子
测试：小木
前端：隽隽
服务端：必煦
联调时间：2021.07.30
提测时间：2021.07.31
上线时间：2021.08.10

2）调研

　　功能的技术选型，对比不同方案的优缺点，适当取舍，形成一套适合当前场景的最优方案。

　　以复杂动画为例：

• 自己之前有没有做过类似的动画，可以借鉴？
• 公司内部有没有自制的动画库，可以引用？
• 业界有没有现成的动画库或不错的实现思路，可以参考？
• 用原生实现，与遇到哪些问题，兼容会不会很困难？
• .........

3）实现

　　需要思考很多方面：业务的完整流程、数据结构的设计、关键功能的逻辑描述、异常处理、安全、性能、与现有业务的耦合情况、组件复用等。

　　保证自己和他人在看到这份方案时，能清楚明白你的设计思路、代码意图和模块划分。

　　可用任意方式表达自己的思路，例如伪代码、图表或纯文字等。

　　流程图让自己和他人对需求有个直观的了解。

　　

　　伪代码在不写具体代码前，展示自己的编码思路，传达代码意图，即使是不会代码的人也能读懂，给你点意见。

function getSomeData() {
  let data;
  if(无缓存) {
    // 请求数据
    if(请求异常) // 展示错误页面;
    data = 请求到的数据;
  }
  // 展示页面
}

　　模块划分是架构的一个点，需要考虑哪些是独立模块、哪些是公共模块、哪些是与业务耦合的模块。

　　用例图可整理出大大小小的场景，在列出后就会发现流程中缺少的部分，以及各种未考虑到的边界。

　　

　　还有安全问题，例如防止恶意的接口访问。页面中是否有性能问题。未来若扩展需求，那么当前设计的扩展性是否能满足需求的变化。

4）复盘

　　复盘总结的内容可自由发挥，按照自己的实践，记录与需求相关的一切，例如：

• 撰写方案时遇到的问题，以及解决方案。
• 代码上线后，收到的反馈，做的好的方面和做的差的方面。
• 别人在做设计方案时，有什么值得学习的地方。
• 在整个项目开发中，流程中的哪个点处理的不好（例如低效无用的沟通等），之后讨论改进方案。
• .........

标签：需求,动画,基建,代码,从零开始,设计方案,模块,思路
来源： https://www.cnblogs.com/strick/p/15179933.html