软件心学格物致知篇(6)愿望清单下篇

最新推荐文章于 2024-09-12 10:35:47 发布

菡萏如佳人

最新推荐文章于 2024-09-12 10:35:47 发布

阅读量1k

点赞数 36

分类专栏：软件心学文章标签：软件工程

本文链接：https://blog.csdn.net/qxmlovezn/article/details/137344804

版权

软件心学专栏收录该内容

11 篇文章 0 订阅

订阅专栏

前言

上一篇我们介绍了愿望清单的两种表现形式：企业战略与客户需求。

本篇会继续介绍愿望清单的其它表现形式并尝试剖析下愿望清单的本质是什么。

愿望清单之架构设计指标

软件工程中，在开发一个系统的时候，需要做的一件事情就是架构设计。

架构在行业内还未有一个明确的定义，通俗的讲架构就是代码的组织形式。它的分类也有很多种，可以按实现层次、技术风格、关注方向等划分。

这里关注的重点不是如何做架构，而是谈谈在很多所谓的架构设计指标中也充斥着愿望清单的味道。

根据愿望清单设计出来的架构，往往也很难符合实际要求。

一般对于系统架构方面的需求会描述在非功能性需求中，架构师会根据这些需求进行合理的架构设计，但是实际情况是很多非功能性需求也是愿望清单。

来举个例子，你或许可以在很多的PRD(产品需求规格说明书)文档的非功能性章节中看到类似的内容：

1.系统要保证高性能
2.系统要留有充分的扩展空间，以适应未来发展的需要
3.系统的并发量不少于1000
4.页面查询时间不少于1秒，接口调用时间不得少于1秒
.......

在这里插入图片描述
以上内容都摘录自真实的项目需求文档，前两点的描述非常主观。

什么是高性能？每个人都有自己的看法，什么叫充分的扩展空间？多少充分算充分？适应未来多久的发展？1年还是5年还是10年？可谓是典型的愿望清单。

后两点伪装的比较好，但也属于愿望清单型的架构指标。

这两点虽然给了具体的指标，其实也存在很大问题：

一个系统有很多的功能，有用户不太经常使用的功能和有用户经常使用的核心功能。

明显两类服务要求的并发量应该是不一样的，对于前者上面描述的并发量绰绰有余，而对于后者又明显不够。

退一步来说，假设列出的数值都能满足的话，那也是属于过度设计。

其中浪费的成本由甲方承担还是由乙方承担呢？

第四点存在的问题和上面的一样，就不再赘述了。

这里可以给一个关于系统响应时间上恰当的描述示例：

系统在95％的情况下，一般时段响应时间不超过1.5秒，高峰时段不超过4秒。
定位系统从点击到第一个界面显示出来所需要的时间不得超过300毫秒。
在网络畅通时，拨号连接GPRS网络所需时间不得超过5秒。
在网络畅通时，电子地图刷新时间不超过10秒。
在推荐配置环境下：登录响应时间在2秒内，刷新栏目响应时间在2秒内，刷新条目分页列表响应时间2秒内，打开信息条目响应时间1秒内，刷新部门、人员列表响应时间2秒内。
在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。

有经验的架构师都知道一个项目中各种资源是有限的，每一次架构的选择都是对于实际业务场景下各方面综合考虑后权衡的结果，是对具体场景的妥协。

只有经验不足的架构师才会觉得可以做到既要又要还要的面面俱到型架构。

不同的行业，系统架构往往不太一样。即使是相同的行业，只要其业务模型流程不一样，其架构也肯定是不一样的。

做架构要理解和顺应硬件天性，别让硬盘抗性能，别让内存存太久，别强求网络一直稳定。

做架构要顺应客观事物发展的天性：损有余而补不足。

需要节省存储空间时，可以采用数据压缩，用算力换IO和空间；想提升复杂计算后的数据获取速度时，可以采用对计算结果进行缓存的机制，用空间和IO换算力。

希望你下一次在非功能性需求中看到愿望清单时能够清楚的识别出来。