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

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

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

  基于文章中的设计方案,自己做了点修改。设计方案包括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 2021-09-05 21:49  咖啡机(K.F.J)  阅读(399)  评论(0编辑  收藏  举报