技术方案应该这么写

简介

   新入职一个华为十年工作经验的老Java。让写一个设计方案，其实也不算难，根据业务需要存取三千万数据，三天没写出来，最后做了辞退处理。其实我相信这个老技术员是有能力的，只是没有合适的机会表达。但是也侧面的说明写好方案设计是多么的重要，当公司找一个高级程序员的时候，是不会只满足于让你写代码的，还要会参与设计与方案撰写。
   所以在这里给大家分享一下如何写好一个技术方案，其实就是：背景与目的，难点与需求，详细设计，测试策略，文档沉淀，文章会分别介绍一下，各部分的写做目的和技术要求。其实写好方案就一句话：表明你的问题，简单清楚的提出解决方案。后面还会提供一个简单模板，供大家参考。
   现在来场景带入，你入职了我们公司，上一个华为老兵折戟沉沙，领导让你写个简单的方案意思一下，让你写，我们的系统要经的起核弹的考验，让你设计一个方案出来，并且让我带你写。

背景与目的

• 概述问题的背景、现状和影响范围，明确需要解决的核心问题。
• 阐述解决方案的目的和意义，以及对项目或业务的预期效益，为后续设计提供清晰的方向。

  很多同学会想，我一共就两天时间，还要写什么口水话，不是浪费时间？其实大家都很忙，来参加你的评审，或者看你的报告，连你要做什么，为什么要做都不知道，一上来直接就讲技术不合适，这里要求，简洁、清楚的说出：为什么要做这个方案，要达到怎样的结果就可以。那怕只有几十个字也无所谓。
  你的方案背景：2024年世界局势动荡，对系统提出诸多挑战，一次小小的停电就能把系统打崩，我们需要的是真正意义的上健壮系统。目的：我们希望，系统能抵御各种灾难，能经的起核弹的考验。

难点与需求

• 深入分析项目的难点和关键所在，为详细设计提供解决方向。
• 列出功能性、非功能性需求，包括性能、安全性、兼容性等。

  这一部分更多的是承上启下，第一部分明白了我们为什么要做，要做到什么样。第二步就是明确，难点是什么，具体的需求是什么。相当于背景和目的是给领导看的，难点与需求是给技术人员看的。以及你为自己的方案解决点提出一个可行的点，以及具体的实现目标。
  你的方案项目难点在于：物理毁灭系统硬件，是软件不可恢复的。所以你提出要做灾备，并且大胆的提出异球备份计划，项目计划为：流浪系统。做好系统后，发送到月球上就可以了。需求：一、做一个完整的能独运行，且能同步数据的系统，包括软硬一体。二、找个外包公司做个火箭。

详细设计

• 针对难点和需求，提出详细的架构设计和技术方案。
• 阐述技术方案的选择理由，并分析其优缺点、适用场景和局限性。
• 使用UML建模（如用例图、类图、序列图、状态图等）进行清晰表达，常见工具有：Visio、draw.io、processon
• 考虑合适的设计模式，并做代码示例，且画好类图。
• 考虑方案的可扩展性、可维护性和安全性，并提出相应的措施。

详细设计，是整个方案的核心，整个书写需要循序渐进，

• 第一步：是架构设计，需要让大家明白整体的架构和组件间的交互关系，或者说，你的方案涉及到架构的哪一步，让大家有个整体的认知。
• 第二步：技术选型，为什么这么选技术，优缺点是什么。
• 第三步，学会用图表达你的含义。UML也是一种语言，让人看图就能明白意图。能写好一个技术方案的核心，就是详设部分，而UML和设计模式，就是详设的核心，请注意。

  设计模式就不多说了，这里重点介绍一下UML建模语言，Unified Modeling Language（UML）是一种用于软件系统设计和建模的标准化语言。注意UML是一种语言，它提供了一套图形化的符号和约定，用于描述系统的结构、行为、交互和功能。UML图可以分为两大类：

• 结构图：描述系统的静态结构，包括类的组织、对象之间的关系以及系统的部署架构。包括以下七种类型图：
  • 类图：描述系统的类及其之间的关系，包括继承、关联和聚合关系。
  • 对象图：描述系统中某一时刻的对象及其之间的关系。
  • 包图：描述系统的包及其之间的关系。包是用于组织UML元素的逻辑分组。
  • 组件图：描述系统的组件及其之间的关系。组件是可部署的软件单元。
  • 部署图：描述系统的部署架构，包括硬件和软件的物理分布。
  • 构件图：描述系统的构件及其之间的关系。构件是可部署的软件单元的物理实现。
  • 轮廓图：描述系统的轮廓，即系统的外部可见部分。
• 行为图：描述系统的动态行为，包括对象之间的交互、系统的流程以及状态的变化。包括以下四种类型图：
  • 用例图：描述系统的用例及其之间的关系。用例是系统的功能性需求。
  • 活动图：描述系统的流程，包括活动、动作和控制流。
  • 状态机图：描述对象的有限状态机，包括状态、触发器和转换。
  • 交互图：描述对象之间的交互，包括消息、序列和协作。

  UML提供了丰富的图表示法，可以用于描述软件系统的各个方面。更多时候用图说话，比文字更容易理解。这些图并不是都要画，选择一部分，完成你的表达即可。
  你的方案，架构组件图要有吧，灾备的部署图要有吧，用例图和交互图要有吧，然后把异球备份的理念讲清楚就好。

测试策略

• 制定测试策略，包括测试用例、测试环境、测试数据等。
• 覆盖所有功能需求和非功能需求，并考虑各种边界情况和异常情况。
• 主要给出测试建议与方向，详细策略应该测试完善。

  严格来讲，做为开发，测试策略不应该你来写。因为自己踢球自己做裁判，本身不合理，知道有问题早就改了。详细的策略，应该是测试跳过开发，直接和产品确认需求，然后写测试策略。但是这里，主要是给出测试一些思路和建议，只有明白了内部逻辑，才能更好的明白完成测试策略书写。所以重点在于给出测试建议。
  你的建议就是，停电模拟核弹来袭，毕竟我们公司暂时现在没有核弹采购需求。

文档沉淀

• 针对详设，以图表文档方式沉淀方案，引导开发与测试。
• 主要书写数据库表结构、接口请求文档、项目计划与工作量安排、公议记要，风险评估等。

  方案写完了，要做一些文档沉淀，和给开发做一些引导。比如数据库应该怎么设计，接口参数怎么定，项目工作量怎么安排等，一般工作安排不会让开发来做，但是给出一个工作量预估领导还是很喜欢的。最喜欢你估两周，让你三天做完。预估工时的办法很简单，以你为标准，你需要多久写完，然后乘以二至三倍就可以了。
  你把设计文档写完，数据库表、接口文档等也写完，让领导给你找个做火箭的外包公司，然后把系统发到月球上去。或者做个简单异地灾备，你的任务就算完成了。如果你不做这个方案，一开始就说方案不实际，或者三天后文档拿不出，你猜结果会是什么。

模板

  xxx系统设计方案（模板）