1 问题背景
一切为了进度,软件开发的首要目标就是以最快的速度满足客户需求,“快”是第一要素,但是短期指标;可复用性、扩展性等长期指标被忽略,导致后期的维护、功能增减调整都非常困难。
一个小的业务需求会牵一发而动全身,一个小的故障修复可能引入更多的问题。整个系统包袱越来越沉重,软件的质量和开发周期越来越不可控。
排除软件开发人员的水平和项目进度的原因,主要影响因素还包括软件架构,和软件缺陷的修复能力。对于量产软件,架构问题是先天性的,后期很难大改,只能前期预防;软件缺陷问题是无法避免的,只能期望快速修复。抛砖引玉,也可先参看《嵌入式软件bug从哪来,怎么去》。
2 软件架构问题
2.1 软件架构的特点
1. 承载力
正如一艘船最多能装多少人,从软件方面来说是软件架构能承载多少业务或功能需求,当然,这需要架构师一开始架构系统的时候,就需要有一定的预见性。但也没必要为了极小概率事件增加过多的冗余。
2. 易用性
易用性决定了软件的整体开发效率,好的架构会让团队成员容易上手,子系统容易对接,开发效率高,各模块和子系统的编写只需要关注系统的设计和编码工作,其他模块间通信方面的事情架构可以提供很好的兼容。
3. 扩展性
一个水杯除了用来喝水,也可用来喝酒,适应不同场景,在一定范围内满足不同的需求,是非常有必要的。软件架构也是这样,要新增更多的功能就要具备更高的扩展性。可扩展性的关键就在于新增部分不能影响其他,如果增删导致系统整体使用异常,那么这个架构的可扩展性就很差。
4. 伸缩性
伸缩性就是设计的方案或系统是否可以根据需求适配不同数量的功能或子系统,在我们设计的软件系统中,架构的可伸缩性决定了架构的可适配性,例如,当硬件资源不足时,可以调整配置如flash的空间分配,支持减少一些服务但仍能正常运行。
5. 容错性
软件运行中的异常,如用户的非法操作,或者软件本身的小缺陷导致整个系统无法使用,那这个架构容错性就很差。软件中的一些缺陷无法避免,但是我们应尽量保证这个缺陷的影响范围最小。倘若出现系统无法使用的情况,应该有备份方案,比如自动重启或者自动恢复数据等功能,也应该能够让开发人员及时知道问题的发生,以及问题所在的位置并记录错误信息。
在架构设计中,以上五项基本能力缺一不可,某项能力的突出并不能带动其他项,如果某一项能力比较弱,随着时间的推移,问题会越来越大,甚至系统崩溃。就像木桶原理那样,一个木桶的容量不是取决于最长的那根木板,而是取决于最短的那根。
-
嵌入式软件
+关注
关注
4文章
240浏览量
26613 -
架构
+关注
关注
1文章
509浏览量
25444 -
系统
+关注
关注
1文章
1006浏览量
21310
发布评论请先 登录
相关推荐
评论