技术设计方案

目的是为了在真正开始敲代码之前理清自己的思路，对需求有一个更清楚的认识。
另一点就是时间一久，突然这个功能出现了一个bug让你去修复，你可能会对自己写的代码有些忘却，此时找到之前自己写的设计方案一看便知，这同样也能作为新入职的小伙伴在熟悉现有代码的重要资源！

一.需求相关信息

把这些内容写在设计方案的开头，让跟这个需求相关、不相关的人都能一目了然，如果遇到问题也可以立马精准地找到相应的人。

格式如下

  1. 需求背景：因为我们要做线上推广活动...
  2. PRD: 文档链接
  3. 产品：xxx
  4. UI：xxx
  5. 前端：jerrod
  6. 后端：xxx
  7. 联调时间：2021.07.30
  8. 提测时间：2021.07.31
  9. 上线时间：2021.08.10

二、方案调研

这一部分主要是需要我们在考虑功能实现的技术选型时，对比很多不同的方案，综合考虑每一种方案的优缺点，可以适当地取舍和改进，形成一套适合当前场景的技术方案。

举个比较简单的例子吧，假设你此次接的需求中有一个复杂的动画要实现，那么你以下这几种考虑的方向

  • 以前我有没有做过类似的动画，可以借鉴的？
  • 公司内部有没有什么现成的库或者代码能用？
  • 业界有没有现成的库或者比较不错的实现思路？
  • 如果不用别的库，用原生实现，我会怎么做？有没有什么兼容性等其它问题？

在了解了这四种场景以后，我们此时需要思考别人的方案和我自己的方案哪一个更好，优缺点分别是什么？别人的方案是否适用于我们当前的场景？在综合考虑了众多因素后，我们选择一套相对比较靠谱的方案用于实行。

通过以上几个步骤来支撑我们接下来敲出来的代码的可靠性与质量！

三、具体方案

这部分是最重要的了，它几乎涵盖了你所有需要思考的东西：业务的完整流程、数据结构的设计、关键功能的逻辑描述、异常的处理、安全性、性能、与现有业务的耦合情况、组件复用

起码要保证其他人以及你自己，在看到具体的方案介绍时，可以很清楚地明白你的设计思路、写代码的思路、模块的划分。你可以用任何形式去表达你的思路，例如伪代码、流程图或者纯文字等等

还有一些别的就是，你还需要考虑一下你的某些接口需不需要考虑安全问题，比如点击submit会增加抽奖次数，那不会被别人恶意伪造一些信息进行刷抽奖次数呢？还有你的页面会不会存在一些性能问题？如果以后要在这个需求上扩展别的功能，你觉得你的代码可扩展性如何？当然，你要考虑的肯定远不止这些，希望每个工程师都能对自己的方案考虑周全，做到精益求精，这样才能有所提升！

四、其他

可以记录下与这个需求相关的一切，我个人觉得可以写的有这些：

  • issues文档
    你在写设计方案时遇到的问题以及解决办法
    你的代码上线以后，用户的反馈如何，如果好，好在哪里；如果不好，到底是哪里出了问题，该如何解决
  • advise文档
    在此次整个开发流程中，有觉得哪个流程不太好的（低效、无用的沟通等等），可以记录在此，然后找相关人员讨论改进（复盘）
    more…

最后，我等设计方案写完以后，找上司过一下，再找相关人员会约一个时间一起听我讲一遍我的设计方案。