【软件构造】软件配置管理和软件构造过程

软件构造过程可以分为两个过程，分别是从0到1的软件开发生命周期（SDLC）和从1到n的软件版本迭代。本文着重讲解后者内容

软件配置管理与版本控制

基础概念

• 软件配置管理(SCM)：追踪和控制软件变化，包含版本控制和基线建立
• 软件配置项(SCI)：软件中发生变化的基本单元
• 基线(Baseline)：软件持续变化过程中的“稳定时刻”
• 配置管理数据库(CMDB)：存储软件的各配置项随时间发生变化的信息与基线

SCM追踪和控制软件中SCI的变化，并将这些变化放置在CMDB储存。软件在开发过程中不断进行更新，但期间可能会有若干需要进行发布的稳定版本；在SCM中软件的某个版本实际就是软件所有SCI的某个版本信息的组合，而基线就代表这个版本，是串联所有SCI的一条线。基线也储存在CMDB之中。

版本控制

版本控制是SCM最关键的功能，其作用包含：

• 存取版本备份
• 比较版本差异
• 进行版本合并
• 方便多人协作
• 方便审计操作

版本控制系统(VCS)在现在最让人熟悉的例子当然是Git，但是在Git出现之前VCS的类型也经历了多次演变。

1. 传统版本控制方法
   不适用VCS，单纯通过复制文件和修改文件名来控制版本
2. 本地版本控制系统
   仓库储存在开发者本地机器，可以满足开发者对本地开发的版本控制需求，但是无法进行多人协作，版本备份也仅能在进行开发的一台机器上通过VCS获取。
3. 集中式版本控制系统
   仓库储存于独立的服务器，支持多开发者之间的协作。但是所有文件都储存在单一的服务器中，开发者必须保持联网才能进行开发，而且对文件进行的每次修改上传都要保存在中央服务器中。提交的修改应小则小，开发者必然要进行频繁的提交；这就使得开发者在网络不好时必须拿出大把时间来等待上传完成，甚至若是断网了，开发者就只能干瞪眼了。
4. 分布式版本控制系统
   仓库储存于独立的服务器和每个开发者的本地机器。Git就是这种版本控制系统。commit指令将版本提交到本地版本库，push质量将本地版本库的内容提交到远程仓库。开发者本地可以储存远程仓库的所有内容，在本地进行软件任何部分的开发，并且可以依本地和远程提交将版本提交分为两级：琐碎的小修改先在本地版本库进行提交，完成若干的本地版并提交后再将其提交到远程仓库，没有必要总是接入网络。

Git

Git作为分布式版本控制系统，还有很多值得一提的特点。

1. Git仓库分为三个部分，分别是暂存区、本地版本和远程仓库。其中暂存区的作用是隔离工作目录和Git仓库，允许开发者对工作区的修改进行选择性的提交。毕竟commit是原子性操作，只能将暂存区的文件全部提交，如果要选择性提交就必须依赖add指令。同时缓存区还有缓冲作用，给开发者多一层确认的机会。
   
2. 在传统VCS中，如果你修改了某个文件，VCS会单独储存发生变化的代码行；而Git则会直接再储存一份修改后的原文件。相比之下Git显然会占据更大的空间，但这种整文件储存的方式减少了需要管理的SCI的个数，在性能上有更加优秀的表现，是使用了空间换时间的策略。

通用软件构造过程

1. 编码
   编码过程需要开发者利用多种开发工具来应用多种构造语言。比如说语言可以按照用途划分：
   • 编程语言
   • 建模语言
   • 配置语言
   • 构建语言

语言的作用是交流，而交流可以发生在开发者之间，也可以发生在开发者和计算机之间。

2. 代码评审和静态测试
   代码评审是对编码成果的系统性检验，包含结对编程、走查、正式评审会议等多种形式，以人审为主。
   
   静态测试主要依据自动化工具，例如Java的CheckStyle等。代码评审和测试不仅能优化代码，还能提升开发者的能力，提供开发者之间交流和互相教学的机会。
3. 动态代码测试
   执行程序并观察现象、收集数据、分析不足，抓住代码的潜在问题，进一步优化代码
4. 调试和测试
   测试用于发现错误，调试用于定位错误和发现错误的根源。测试人员设计尽可能详尽的测试用例，对软件或模块进行系统性的测试，并将测试结果反馈给编码人员。编码人员按照测试结果对程序进行调试，对错误的来源进行更精确的定位，并理解错误的原因。
5. 重构
   在多轮评审测试调试过程发现的问题都需要在重构过程中进行修正。重构要求在不改变功能的前提下优化代码，进行过重构的代码都要进行回归测试，确保重构没有引入新的Bug。