『互联网架构』软件架构-软件系统设计(一)

按照正常的互联网玩法,产品经理原型画好进行需求评审,评审完后,需要把需求丢给技术经理,或者技术负责人,进行一整套的概要设计,然后针对概要设计评审,概要评审后进行开发。这次咱们一起说说概要设计的体系结构。了解下套路。

软件系统设计

软件系统设计在很多人眼里就是写文档,写文档是一种负担,其实系统设计头脑风暴,是一种非常开心的事情。所以必须掌握什么是系统的设计。它里面有哪些方法论,如何去做一些系统设计。

我们平常做开发设计吗?

才毕业回郑州那几年,都是一句话就是需求,开发完了河南本地连个测试人员都没有,开发人员说开发完了就开发完了,直接拿给用户进行测试。有的用户直接骂娘,有的用户用的感觉很不爽哭的(工作没做完),有的用户直接摔东西的。聪明的一点的用户都直接联系开发人员帮他来操作。直接测试都没有,用户就是测试人员,说实话7,8年前的告诉用户怎么用,他怎么用。他感觉很神秘,这几年随着互联网产品越来越多,智能手机的普及,大家对软件的要求越来越严格了。很多之前的习惯的同事,现在都没转变过来,真是土,土的掉渣。后来其实也没太关注设计,可能就是之画个图。直到后来跟第三方系统进行交互数据,刚开始草草的设计下,导致之后的2个月都没好过。所以说系统设计是一项非常重要的工作。而不是老铁们经常说的就是写个文档就行了。

  1. 拿这键盘直接干。
  2. 深思熟虑,考虑到多方的问题,在开始我们的编码。
  3. 需求里面是一句话,直接就是干,别墨迹。
  4. 做设计的时候,开发人员在考虑?还是技术经理在考虑?

用什么方法做?

瀑布流程(互联网直接忽略)

需求确定的基础上,系统设计的方方面面设计的都很全面,把每个阶段都有非常严格的验证条件,在主流的大型软件的开发方式。

基于原型,快速迭代(互联网常用)

许多创业公司的老板真心喜欢,感觉业务可以进行快速的开发,其实在里面还是有很多的坑在里面的。很少有人基于瀑布来开发。其实快速迭代也变成了很多老板让各位老铁赶项目的理由了。我几个亿的单子,先让用户验证,让用户体验到,大家不能耽误我们伟大的商业模式,就算是这种开发模式也是需要有文档的,对设计不清楚的地方也会有很多,很多的坑在里面,包括后期的性能和扩展也好,如果前期底子没有搭建好的话,后期伤筋动骨。随随便便改一个小功能可能要对程序进行伤筋动骨。但是这个时候老板是不会管你的,测试人员更不会管你,产品也不会管你,他们只知道我们满足业务和需求。

具体设计什么

具体到底需要设计什么?如果系统没有做好一个设计,如果你还是基于所谓的原型,快速迭代敏捷开发以这为借口的话,程序后期越来越大,越来越大的时候真心很伤,根本都不改你的系统,就比如说:银行,社保里面的代码基本是10年前的代码,里面的问题一大堆,但是没有人敢改,这也是设计部合理导致的一个毛病。

  • 体系结构设计 1.指明了一个系统是什么,它是整个软件中最本质的表现

开发人员看文档的时候,首先就要看体系结构。它是软件系统最本质的东西,主体的形态,人的骨架就是体系结构。如果你设计的体系结构是个大猩猩,后期不管如何进化,如何发展,它始终无法变成一个人,只能是个猩猩。比如盖房子,可能盖高层,可能盖土房,可能盖平房,或者是窑洞,一开始就想盖高层,它需要的材料,地基深度什么都是不一样的。所以体系结构就需要了解软件设计的本质。也可以说架构。

2.应当设计的很稳定

盖到一半,要换地基是不是很悲催。开发的设计的时候一定要三思而后行。

3.设计的原则

3.1 适应性

满足用户需求,达成商业的目的。而不是开发人员自己歪歪,高水平的设计人员就是设计出来刚刚满足用户需要的软件,而不是不惜一切代码设计出来一个最先进的软件,没有最好,只有最合适。打造闭环是最好的,对于很多互联网项目,可能不是刚需需求,可能不是成熟的商业模式,如果非要进行闭环,试错的机会都不给,开发的成本老板接受不了,老板无法快速推广到市场里面。开发的功能越多,功能越强大的话,一旦业务发生调整的话,软件不好发生变动。所以要分为很多个阶段。开发和产品经理很多容易犯这个毛病,刚开始就设计都喜欢大而全,精而细。 产品经理经常爱说:『别人的系统都有这个功能,你为什么做不了!』,其实可以这么怼过去,给他上一课:『这样的产品设计根本就不能满足现阶段产品设计的适应性!』

3.2 结构稳定性

我们设计的要相对的稳定性,一定确定一定要相对的稳定性,如果经常变动,就相对于房子的地基,你看到那个房子盖好后的地基经常发生变动。如果软件经常发生,太悲剧了。体系结构设计的不稳定,范围不清楚,如果一个系统刚开始是B2C,突然要变成B2B,表结构,系统模块,界面,全部都要发生比较大的改变。整个项目变的很轮乱,需求不停的变动导致系统很混乱。导致开发人员不敢动代码(牵一发动全身),都是复制一份 代码。最后维护多份代码。对于高水平的设计师都是有一定经验的,可以预先知道那些需求是基本不变的,那些需求是可变的。 必须导出:可变需求和可变需求。 举个例子:之前项目中针对消息中心的设计,消息中心:对于用户来说会有很多种类的消息。消息除了pc端,移动端也有很多的消息,物流消息,营销消息,通知消息。当时就有一个问题, 实际的消息中心,就是接收到各种渠道的消息,然后分发到各个平台(邮件,短信,推送,系统消息信息)。之前没有消息中心,都是业务方自己各自来完成的。为了满足原子性,原子是不可变的,消息中心需要做的就是按照业务方的需求把消息发送出去,发送到对应的渠道,短信。但是消息中心是在业务平台之后设计的,业务平台不可能因为发送消息修改自身的业务代码。在消息中心专门设计了一个监听模块,监听业务方的一个动作,这个模块跟业务平台是紧耦合的,事件监听模块随着业务而变动,消息中心的核心功能不会发生变动的,因为功能很纯粹就是发消息,收消息,推送消息。这就是当时如何保证稳定性的问题。在模块上进行划分。如果之后在需要拆分的话,直接把模块进行拆分。监听模块,按照业务的变更进行变更。 稳定性,就不会被业务需求方赶着走,项目是可控的。天天不用担心老板又有新需求。

3.3 扩展性

软件在扩展新功能的难易程度。扩展性越好,适应变化的能力越强,尤其是敏捷开发,如果扩展能力不强的话,很容易进入一个死胡同里面去。区分可变动和不可变动。软件体量约小,扩展能力越强,船小好调头。为什么项目分阶段,就是为了可扩展。系统的体量肯定受限业务的,越大的项目扩展性越难,所以要进行分布式(应用层,中间业务层,原子服务层),分层(控制层,服务层,数据访问层),越是往下稳定。 合理的业务模块划分,扩展的时候根据模块进行拆分扩展。业务的边界划分。

3.4 是不是所有的系统在设计的时候都要考虑扩展性

一次性项目,只要完成现阶段的功能就可以了,例如两个单独的公司的对接接口,其实很多时候因为可能是一次性的,没必要考虑扩展性,如果考虑可能就变成了过度设计。如果做开放平台的话,肯定要考虑扩展性。

3.5 可复用性

用一次还可以继续在用,工具类,公共的组件。工具类一定设计的纯粹(对使用环境没有假设,少配置零配置,没有依赖)

  • 表结构设计
  1. 方法论
  2. 表结构设计
  3. 性能扩展性考虑
  • 系统的模块设计
  • 原型界面设计
  • 设计模式
  • 数据结构和算法

PS:在之前也是不做设计的,但是做过设计的后明显是跟不做设计有很大的区别的。很多提前设计的好,做设计很容易可控。不管大家对设计的理论有多少,设计是必须的。凡事预则立不预则废。设计是为了让开发,测试人员,产品经理(设计没有偏差)。

原文发布于微信公众号 - 编程坑太多(idig88)

原文发表时间:2019-02-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券