一个软件系统没有软件设计,相当于建房子没有图纸,软件系统越复杂越庞大,“图纸”的重要性越大,本篇博客将简单聊聊我对软件设计的思考。
一个软件系统由N个组件构成, 一个组件又由N个模块构成。(随便举个例子:支付宝这个软件系统有理财组件、支付组件等等,理财组件又有基金理财、余额宝理财等模块,有些大模块还能再细分出子模块)
因此,一个全新的软件系统就需要从上往下地去设计,大概对应职责分工如下:
在有些比较庞大的团队,有可能会将特性设计的活安排给一些开发经验比较丰富的人进行专门负责,开发只负责开发,或者只承担一部分的设计,这样的好处是保证大家工作的内容更加聚焦,产出的代码可靠性更高。缺点也是比较明显,个人觉得是有两点:
因此,软件设计人员一般还是编写对应的核心代码,保持对软件系统整个“生命周期”的高感知度。
为啥要做好软件设计呢?首先要明白,软件实现是啥,其实就是将需求描述
映射成代码实现
,这个过程会遇到下面的问题:
所以,能解决这些问题的设计就是好的软件设计。
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):依赖倒置原则。
对扩展开放,对修改关闭。简而言之: 不修改已有代码(尽可能不更改已有代码的情况下),新需求用新代码实现。
子类必须能够替换其父类,并保证原来程序的逻辑行为不变及正确性不被破坏。
不应强迫使用者依赖于它们不用的方法。通俗的理解:对接口设计应用单一职责,根据调用者设计不同的接口。
我这里就不展开讲这些原则,这些需要结合具体的代码去理解去体会。
为保证从软件设计到软件实现整个过程中能够“一致性”,准确的用画图的方式承载这些设计思路就很重要,4+1视图就是这么一个东西。
4+1视图这个概念最早是1995年被一个叫Philippe Kruchten提出来的,作者提出应该用多个视图来描述一个软件系统,每个视图聚焦于说明软件的某个方面。
描述组件上下文模型的依赖关系
逻辑模型:包括组件、模块、子模块、功能单元,将业务进行抽象,分离系统的复杂度,做到可扩展性
数据模型:包括数据表、数据表间关联关系
对逻辑架构的进一步展开和细化,侧重开发内部的细化,对标准目录进行确定和规范,对一些核心的文件进行明确
时序图:描述实体之间基于时间维度的懂爱关系和交互内容,明确运行形式、交互协助形式
状态机:有限状态自动机,需要具备完备性,跟业务解耦,标注稳态还是非稳态,建议不超过7个
数据流图:描绘系统中数据流动和处理的过程,表达数据交互和依赖关系
描述组件、微服务的部署环境,集群方式,描述部署节点(环境)/进程 / 编译目标的关系和操作方式
以上这些视图,基本都是可以在一些比较有名的画图软件找到,我本人现在用亿图绘画这些比较多,大家找一个自己熟悉的软件系统赶紧试试吧~~
(以上为DreamKite本人原创,转载请附上原文链接)