简介
新入职一个华为十年工作经验的老Java。让写一个设计方案,其实也不算难,根据业务需要存取三千万数据,三天没写出来,最后做了辞退处理。其实我相信这个老技术员是有能力的,只是没有合适的机会表达。但是也侧面的说明写好方案设计是多么的重要,当公司找一个高级程序员的时候,是不会只满足于让你写代码的,还要会参与设计与方案撰写。
所以在这里给大家分享一下如何写好一个技术方案,其实就是:背景与目的,难点与需求,详细设计,测试策略,文档沉淀,文章会分别介绍一下,各部分的写做目的和技术要求。其实写好方案就一句话:表明你的问题,简单清楚的提出解决方案。后面还会提供一个简单模板,供大家参考。
现在来场景带入,你入职了我们公司,上一个华为老兵折戟沉沙,领导让你写个简单的方案意思一下,让你写,我们的系统要经的起核弹的考验,让你设计一个方案出来,并且让我带你写。
背景与目的
- 概述问题的背景、现状和影响范围,明确需要解决的核心问题。
- 阐述解决方案的目的和意义,以及对项目或业务的预期效益,为后续设计提供清晰的方向。
很多同学会想,我一共就两天时间,还要写什么口水话,不是浪费时间?其实大家都很忙,来参加你的评审,或者看你的报告,连你要做什么,为什么要做都不知道,一上来直接就讲技术不合适,这里要求,简洁、清楚的说出:为什么要做这个方案,要达到怎样的结果就可以。那怕只有几十个字也无所谓。
你的方案背景:2024年世界局势动荡,对系统提出诸多挑战,一次小小的停电就能把系统打崩,我们需要的是真正意义的上健壮系统。目的:我们希望,系统能抵御各种灾难,能经的起核弹的考验。
难点与需求
- 深入分析项目的难点和关键所在,为详细设计提供解决方向。
- 列出功能性、非功能性需求,包括性能、安全性、兼容性等。
这一部分更多的是承上启下,第一部分明白了我们为什么要做,要做到什么样。第二步就是明确,难点是什么,具体的需求是什么。相当于背景和目的是给领导看的,难点与需求是给技术人员看的。以及你为自己的方案解决点提出一个可行的点,以及具体的实现目标。
你的方案项目难点在于:物理毁灭系统硬件,是软件不可恢复的。所以你提出要做灾备,并且大胆的提出异球备份计划,项目计划为:流浪系统。做好系统后,发送到月球上就可以了。需求:一、做一个完整的能独运行,且能同步数据的系统,包括软硬一体。二、找个外包公司做个火箭。
详细设计
- 针对难点和需求,提出详细的架构设计和技术方案。
- 阐述技术方案的选择理由,并分析其优缺点、适用场景和局限性。
- 使用UML建模(如用例图、类图、序列图、状态图等)进行清晰表达,常见工具有:Visio、draw.io、processon
- 考虑合适的设计模式,并做代码示例,且画好类图。
- 考虑方案的可扩展性、可维护性和安全性,并提出相应的措施。
详细设计,是整个方案的核心,整个书写需要循序渐进,
- 第一步:是架构设计,需要让大家明白整体的架构和组件间的交互关系,或者说,你的方案涉及到架构的哪一步,让大家有个整体的认知。
- 第二步:技术选型,为什么这么选技术,优缺点是什么。
- 第三步,学会用图表达你的含义。UML也是一种语言,让人看图就能明白意图。能写好一个技术方案的核心,就是详设部分,而UML和设计模式,就是详设的核心,请注意。
设计模式就不多说了,这里重点介绍一下UML建模语言,Unified Modeling Language(UML)是一种用于软件系统设计和建模的标准化语言。注意UML是一种语言,它提供了一套图形化的符号和约定,用于描述系统的结构、行为、交互和功能。UML图可以分为两大类:
- 结构图:描述系统的静态结构,包括类的组织、对象之间的关系以及系统的部署架构。包括以下七种类型图:
- 类图:描述系统的类及其之间的关系,包括继承、关联和聚合关系。
- 对象图:描述系统中某一时刻的对象及其之间的关系。
- 包图:描述系统的包及其之间的关系。包是用于组织UML元素的逻辑分组。
- 组件图:描述系统的组件及其之间的关系。组件是可部署的软件单元。
- 部署图:描述系统的部署架构,包括硬件和软件的物理分布。
- 构件图:描述系统的构件及其之间的关系。构件是可部署的软件单元的物理实现。
- 轮廓图:描述系统的轮廓,即系统的外部可见部分。
- 行为图:描述系统的动态行为,包括对象之间的交互、系统的流程以及状态的变化。包括以下四种类型图:
- 用例图:描述系统的用例及其之间的关系。用例是系统的功能性需求。
- 活动图:描述系统的流程,包括活动、动作和控制流。
- 状态机图:描述对象的有限状态机,包括状态、触发器和转换。
- 交互图:描述对象之间的交互,包括消息、序列和协作。
UML提供了丰富的图表示法,可以用于描述软件系统的各个方面。更多时候用图说话,比文字更容易理解。这些图并不是都要画,选择一部分,完成你的表达即可。
你的方案,架构组件图要有吧,灾备的部署图要有吧,用例图和交互图要有吧,然后把异球备份的理念讲清楚就好。
测试策略
- 制定测试策略,包括测试用例、测试环境、测试数据等。
- 覆盖所有功能需求和非功能需求,并考虑各种边界情况和异常情况。
- 主要给出测试建议与方向,详细策略应该测试完善。
严格来讲,做为开发,测试策略不应该你来写。因为自己踢球自己做裁判,本身不合理,知道有问题早就改了。详细的策略,应该是测试跳过开发,直接和产品确认需求,然后写测试策略。但是这里,主要是给出测试一些思路和建议,只有明白了内部逻辑,才能更好的明白完成测试策略书写。所以重点在于给出测试建议。
你的建议就是,停电模拟核弹来袭,毕竟我们公司暂时现在没有核弹采购需求。
文档沉淀
- 针对详设,以图表文档方式沉淀方案,引导开发与测试。
- 主要书写数据库表结构、接口请求文档、项目计划与工作量安排、公议记要,风险评估等。
方案写完了,要做一些文档沉淀,和给开发做一些引导。比如数据库应该怎么设计,接口参数怎么定,项目工作量怎么安排等,一般工作安排不会让开发来做,但是给出一个工作量预估领导还是很喜欢的。最喜欢你估两周,让你三天做完。预估工时的办法很简单,以你为标准,你需要多久写完,然后乘以二至三倍就可以了。
你把设计文档写完,数据库表、接口文档等也写完,让领导给你找个做火箭的外包公司,然后把系统发到月球上去。或者做个简单异地灾备,你的任务就算完成了。如果你不做这个方案,一开始就说方案不实际,或者三天后文档拿不出,你猜结果会是什么。
模板
xxx系统设计方案(模板)