软件构造第一二节知识整理

1 软件系统的多维度解析

1.1 构建期视角下的软件系统

软件系统是一个复杂的实体,可以从多个维度和视角来理解和分析。在软件的构建期,我们主要关注代码层面的组织和演进。

1.1.1 代码的逻辑组织

源代码是软件系统的核心,它们被组织成函数、类、接口等基本单元,遵循特定的语法规则。这些基本单元之间存在着逻辑上的依赖关系,共同协作完成特定的功能。

理解代码的逻辑组织结构,是阅读、理解和修改源代码的基础。

1.1.2 代码的物理组织

从物理的角度看,源代码文件被组织为目录,遵循一定的命名约定。这些文件进一步被打包为库或者子系统,成为软件系统的构建块。

版本控制系统管理着代码库在构建期的演进历史,记录下开发者每一次的修改。通过版本控制,团队可以协作完成开发任务,追踪bug的引入和修复过程。

1.1.3 代码的演进

软件系统在构建期是不断演进的。新的代码被添加进来,实现新的功能;旧的代码被修改,以修复缺陷,改进性能,或者适应变化了的需求;不再需要的代码被删除,避免成为维护的负担。

代码演进的过程中,复杂度、耦合度等内部质量指标往往会发生改变,需要开发者保持警惕。

1.2 运行期视角下的软件系统

软件交付后,在运行期呈现出另一番景象。在运行期,我们更加关注软件系统的动态行为。

1.2.1 执行状态分析

通过分析内存快照、线程转储等运行时信息,我们可以洞悉系统的内部状态,发现潜在的问题。例如内存泄漏、死锁等问题,往往需要在运行期进行诊断。

1.2.2 组件交互分析

站在更高的层次,运行期的软件系统是一系列相互协作的组件,它们部署在不同的物理节点,通过网络交换信息,共同完成业务逻辑。

UML的顺序图、部署图等工具,帮助我们刻画系统的动态交互过程和物理部署结构。运行日志则记录下系统的关键事件,成为问题定位和优化的重要线索。

1.3 视图转换 - 软件系统的构造过程

软件从无到有,再到投入使用,经历了不同视图间的转换。

编程是一切的起点,通过编写代码,开发者在构建期创造出软件系统。代码被编译、链接,转换为可执行的组件。调试和测试是连通构建期和运行期的桥梁,帮助开发者理解和优化系统在真实环境的行为。版本控制系统则见证和管理着构建期软件的演进历程。

1.4 内外兼修 - 软件质量的影响因素

衡量软件系统的优劣,需要考虑外部质量和内部质量两个方面。

1.4.1 外部质量

外部质量直接影响到软件使用者的体验,包括:
- 功能的正确性:软件是否按照需求和设计如期工作;
- 健壮性:面对异常和错误输入,软件能否稳定运行;
- 执行效率:软件的响应时间和资源消耗是否满足性能要求;
- 易用性:用户是否能方便地安装、理解、使用该软件;
- 可扩展性
- 可复用性
- 兼容性
- 可移植性
- 功能性
- 开发时间
- 可验证性、完整性、可修复性、经济性

1.4.2 内部质量

内部质量反映了软件系统自身的特点,例如:
- 复杂度:单个模块的复杂度是否过高,是否容易理解和修改;
- 耦合度:模块间是否存在过多的交互,一处的修改是否会带来连锁反应;
- 内聚性:单个模块承担的责任是否单一,是否专注于做好一件事情;
- 可读性:代码是否拥有良好的注释,清晰的布局,标准的命名;
- 可理解性
- 清洁度
- 大小

内部质量会直接影响到软件的可维护性。而从长远来看,外部质量很大程度上取决于内部质量的保证。

1.4.3 质量属性的权衡

在软件开发过程中,提高某个质量属性往往意味着牺牲另一个质量属性:
- 功能的快速迭代更新可能会增加软件缺陷的数量;
- 追求极致的执行性能可能会损失代码的可读性和可移植性;
- 赶进度的同时很容易忽视软件设计,最终损害了软件的可扩展性;
- ......

这就要求开发团队必须深入业务场景,明确标识出各种折中方案对项目的影响,以作出恰当的决策。但有一点必须牢记:正确性是不能妥协的底线。

1.5 质量目标 - 软件构建的指导原则

综合以上的分析,笔者建议在软件构建过程中重点关注以下几个质量目标:

1.5.1 面向复用编程

好的代码应该是可以被复用的代码。通过抽象和分层,把软件划分为高内聚、低耦合的模块,沉淀为团队的技术资产。

1.5.2 控制复杂度

复杂度是软件项目失败的万恶之源。应该通过模块化设计和编码规范,控制单个模块的代码量和复杂度,保证其易于理解和修改。

1.5.3 确保正确性 

软件系统的价值在于实现业务目标。在构建过程中,需要进行全面的测试,确保功能的正确性,考虑边界条件和异常场景,提高软件的健壮性。

1.5.4 提高内部质量

良好的内部质量是软件长期演进的基石。编码应该遵循CleanCode、重构等原则,努力提高代码的可读性、可维护性,降低未来修改的成本。