做好软件设计让你“事半功倍”

文章目录

  • 一、浅谈软件设计
  • 二、什么是好的软件设计/li>
  • 三、如何做好软件设计/li>
    • 3.1 设计原则
      • 3.1.1 SOLID原则
      • 3.1.2 开放-关闭原则(Open–closed principle,OCP)
      • 3.1.3 里氏替换原则(Liskov Substitution Principle,LSP)
      • 3.1.4 接口隔离原则(Interface segregation principle,LSP)
    • 3.2 画“图”:4+1设计建模
      • 3.2.1 用例视图
      • 3.2.2 逻辑视图
      • 3.2.3 开发视图
      • 3.2.4 运行视图
      • 3.2.5 部署视图

一、浅谈软件设计

一个软件系统没有软件设计,相当于建房子没有图纸,软件系统越复杂越庞大,“图纸”的重要性越大,本篇博客将简单聊聊我对软件设计的思考。

一个软件系统由N个组件构成, 一个组件又由N个模块构成。(随便举个例子:支付宝这个软件系统有理财组件、支付组件等等,理财组件又有基金理财、余额宝理财等模块,有些大模块还能再细分出子模块)

因此,一个全新的软件系统就需要从上往下地去设计,大概对应职责分工如下:

架构设计 组件/微服务设计 特性设计 架构师 软件总工/committer 开发 稳定的 较稳定的 灵活易改的

在有些比较庞大的团队,有可能会将特性设计的活安排给一些开发经验比较丰富的人进行专门负责,开发只负责开发,或者只承担一部分的设计,这样的好处是保证大家工作的内容更加聚焦,产出的代码可靠性更高。缺点也是比较明显,个人觉得是有两点:

  1. 随着技术的快速更新迭代,设计人员脱离代码开发容易导致设计浮于业务表面,设计的东西在技术上的落实不可靠或者落后;
  2. 对于开发人员来讲,只会编码不懂设计,容易思维固化,对问题的思考会缺乏深度和广度。

因此,软件设计人员一般还是编写对应的核心代码,保持对软件系统整个“生命周期”的高感知度。

二、什么是好的软件设计/h1>

为啥要做好软件设计呢先要明白,软件实现是啥,其实就是将映射成,这个过程会遇到下面的问题:

  1. 软件实现了基本的功能,可靠性、可维护、可扩展等DFX属性缺乏;
  2. 需求不断变化,不仅仅是考虑实现了当前的需求,还需要考虑未来的变化;
  3. 需求的开发是不同的人共同完成的,相互沟通和自己的理解都可能存在偏差,容易导致结果跟预期不一致。

所以,能解决这些问题的设计就是好的软件设计。

三、如何做好软件设计/h1>

3.1 设计原则

3.1.1 SOLID原则

S(Single Responsibility Principle,SRP):单一职责原则;
O(Open–closed principle,OCP):开放-关闭原则;
L(Liskov Substitution Principle,LSP):里氏替换原则;
I(Interface segregation principle,LSP):接口隔离原则;
D(Dependency inversion principle, DIP):依赖倒置原则。

3.1.2 开放-关闭原则(Open–closed principle,OCP)

对扩展开放,对修改关闭。简而言之: 不修改已有代码(尽可能不更改已有代码的情况下),新需求用新代码实现。

3.1.3 里氏替换原则(Liskov Substitution Principle,LSP)

子类必须能够替换其父类,并保证原来程序的逻辑行为不变及正确性不被破坏。

3.1.4 接口隔离原则(Interface segregation principle,LSP)

不应强迫使用者依赖于它们不用的方法。通俗的理解:对接口设计应用单一职责,根据调用者设计不同的接口。

我这里就不展开讲这些原则,这些需要结合具体的代码去理解去体会。

3.2 画“图”:4+1设计建模

为保证从软件设计到软件实现整个过程中能够“一致性”,准确的用画图的方式承载这些设计思路就很重要,4+1视图就是这么一个东西。

  • 用例视图:上下文用于开发者测试数据打桩、安全暴露边界分析、系统测试、威胁分析
  • 逻辑视图:用户描述模块划分、模块依赖关系、开发顺序,开发人员可以细化到模块功能多元
  • 运行视图:用于描述模块与模块之间、节点与节点之间、线程与线程之间的关系
  • 物理视图(部署视图):展现软件到硬件的映射,以及软件的分布式部署
  • 开发视图:描述软件在开发环境中的静态组织方式,开发人员可以细化到代码目录

做好软件设计让你“事半功倍”

3.2.1 用例视图

描述组件上下文模型的依赖关系

3.2.2 逻辑视图

逻辑模型:包括组件、模块、子模块、功能单元,将业务进行抽象,分离系统的复杂度,做到可扩展性

数据模型:包括数据表、数据表间关联关系

3.2.3 开发视图

对逻辑架构的进一步展开和细化,侧重开发内部的细化,对标准目录进行确定和规范,对一些核心的文件进行明确

3.2.4 运行视图

  • 时序图:描述实体之间基于时间维度的懂爱关系和交互内容,明确运行形式、交互协助形式

  • 状态机:有限状态自动机,需要具备完备性,跟业务解耦,标注稳态还是非稳态,建议不超过7个

  • 数据流图:描绘系统中数据流动和处理的过程,表达数据交互和依赖关系

3.2.5 部署视图

描述组件、微服务的部署环境,集群方式,描述部署节点(环境)/进程 / 编译目标的关系和操作方式

以上这些视图,基本都是可以在一些比较有名的画图软件找到,我本人现在用亿图绘画这些比较多,大家找一个自己熟悉的软件系统赶紧试试吧~~

文章知识点与官方知识档案匹配,可进一步学习相关知识Java技能树首页概览91764 人正在系统学习中

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2022年10月22日
下一篇 2022年10月23日

相关推荐