软件构造课程总结（三）——软件构造过程与配置管理

软件开发生命周期

传统的软件过程模型

两个基本类型：

• 线性过程
• 迭代过程

已有模型：

• 瀑布模型
• 增量过程
• V字模型
• 原型过程
• 螺旋模型

选择合适的过程模型的依据：

• 用户参与程度（适应变化的能力）
• 开发效率/管理复杂度
• 开发出的软件的质量

敏捷开发

敏捷开发：通过快速迭代和小规模的持续改进，以快速适应变化。

Agile = 增量 + 迭代

每次迭代处理一个小规模增量

▪ 极限的用户参与

▪ 极限的小步骤迭代

▪ 极限的确认/验证

极限编程

结对编程，任务板，流程控制

软件配置管理（SCM）和版本控制系统（VCS）

软件配置管理

追踪和控制软件的变化。

软件的任何组成部分（源代码、数据、文档、硬件、各种环境）都可以随着软件生命周期中的时间而更新。

软件配置项：软件中发生变化的基本单元（例如：文件）

基线:软件持续变化过程中的"稳定时刻"(例如:对外发布的版本)

CMDB：配置管理数据库，用于存储软件的各配置项随时间发生变化的信息 + 基线

版本控制

版本：为软件的任一特定时刻（Moment）的形态指派一个唯一的编号，作为“身份标识”。

版本控制作用：

• 对于个人
  • 可以回滚到上一个版本
  • 可以比较两个版本差异
  • 备份软件版本历史
  • 获取备份
  • 合并不同版本
• 对于团队
  • 在多个开发者之间共享和协作
  • 记录每个开发者的动作，便于“审计”

多个版本之间，会形成线性或者分支结构。

术语

存储库：即于SCM中的CMDB

工作拷贝：在开发者本地机器上的一份项目拷贝

版本：在某个特定时间点的所有文件的共同状态

变化：即code churn，两个版本之间的差异

HEAD：程序员正在其上工作的版本

版本控制分类

1. 本地版本控制系统

   仓库存储于开发者本地机器无法共享和协作

2. 集中式版本控制系统

   仓库存储于独立的服务器，支持多开发者之间的协作

3. 分布式版本控制系统

   仓库存储于独立的服务器 + 每个开发者的本地机器

Git（典型SCM工具）

Git存储库

Git存储库的三个部分：

• 本地的CMDB
• 工作目录：本地文件系统
• 暂存区：隔离工作目录和Git仓库

项目文件的三个状态：

• 已修改
• 已暂存
• 已提交

Git中的对象图

我们使用Git所做的所有操作—克隆、添加、提交、推送、日志、合并、……——都是在图形数据结构上的操作，该结构存储项目中所有文件版本以及描述这些更改的所有日志条目。

Git对象图存储在存储库的.git目录中。

从另一台机器/服务器复制一个git项目意味着复制整个对象图。

对象图是一个Git项目的历史记录，它是一个有向无环图（DAG）。

Git存储发生变化的文件（而非代码行），不变化的文件不重复存储。

分支/合并

分支是在修订控制下的对象的复制，以便可以沿着两个分支并行地进行修改。

合并操作合并了两个分支机构。

常用操作

git checkout –b 分支  //创建分支
git commit           //提交分支
git checkout master  //切换到master分支
git merge master     //把master分支合并到当前分支
git branch –d 分支   //删除分支
git clone            //克隆远程库
git fetch            //拉取分支
git push             //推送当前分支

GitHub

一个基于web的Git服务器和互联网托管服务。它提供了Git的所有分布式版本控制和SCM功能，并添加了它自己的功能。它为每个项目提供了访问控制和一些协作特性，如bug跟踪、特性请求、任务管理和wikis。

• 基本流程：提交、分支和合并

• 协作流程：分叉和拉请求

软件构造的一般流程

编码

构造语言

• 用途上划分：编程语言，建模语言，配置语言，构建语言
• 形态上划分：基于语言学的构造语言，基于数学的形式化构造语言，基于图形的可视化构造语言

编程语言

编程工具：集成开发工具IDE（文件管理，库管理，软件逻辑实体可视化，图形化用户界面构造器，编译器、解释器，自动化build工具，版本控制系统，外部的第三方工具）

举例：Eclipse，IDEA

建模语言

建模语言是任何人工语言，可以用来表达由一组一致的规则定义的结构中的信息、知识或系统的语言，目的是可视化、推理、验证和交流系统的设计。

典型建模语言：UML

配置语言

配置语言用于形成配置文件，程序配置参数和初始设置。应用程序应提供工具来创建、修改和验证其配置文件的语法；某些计算机程序仅在启动时读取其配置文件。其他人则会定期检查配置文件是否有更改。

目的：1. 部署环境设置 2. 应用程序特性的变体 3. 组件之间连接的变体

配置语言示例：XML、YAML、JSON

审核和静态代码分析

代码评审

代码评审是对源代码的系统检查（同行评审）。

旨在发现在初始开发阶段被忽视的错误，提高整体质量。

评审以各种形式进行，如结对编程、非正式演练和正式检查。

正式的代码评审会议

正式的代码审查，如Fagan检查，涉及到一个有多个参与者和多个阶段的仔细和详细的过程。

正式代码评审是一种传统的评审方法，即软件开发人员参加一系列会议，逐行评审代码，通常使用材料的打印副本。

正式的检查是非常彻底的，并已被证明在发现正在审查的代码中的缺陷方面是有效的。

轻量级的代码评审

轻量级的代码检查通常比正式的代码检查需要更少的开销。

轻量级评审通常作为正常开发过程的一部分进行：

1. Over-the-shoulder：开发人员观察另一个开发人员编码来学习
2. Email pass-around：源代码管理系统在代码签入后自动将代码发送给审核员。
3. Pair programming：两位作者在同一个工作站上一起开发代码
4. Tool-assisted code review：作者和审稿者使用软件工具，非正式的工具例如巴斯宾和IRC，或为同行代码评审设计的专门工具。

利用工具进行的静态代码分析

静态代码分析是对在没有实际执行程序的情况下执行的计算机软件的分析（在执行程序时执行的分析称为动态分析）。

该过程提供了对代码结构的理解，并可以帮助确保代码符合行业标准。

自动化工具可以帮助程序员和开发人员执行静态分析。

代码审查的目的

两个主要目的：

1. 改进代码。查找bug，预测可能的bug，检查代码的清晰度，以及检查与项目样式标准的一致性。
2. 增强程序员能力。代码审查是程序员学习和教授彼此的一种重要方式，关于新的语言特性、项目设计或其编码标准的变化，以及新的技术。

代码审查在业界中被广泛应用。

代码审查可以改进的问题：

• 错误或潜在的错误
• 不清楚，混乱的代码
• 对Java的误解
• 滥用（或未使用）基本的设计概念

动态代码分析/分析

动态分析：要执行程序并观察现象、收集数据、分析不足

对代码的运行时状态和性能进行度量，发现代码中的潜在问题。

调试和测试

测试：发现程序是否有错误。

软件测试是为向利益相关者提供有关被测试产品或服务的质量信息而进行的一种调查。

测试技术包括执行一个程序或应用程序的过程，目的是发现软件错误（错误或其他缺陷），并验证该软件产品是否适合使用。

软件测试涉及到执行一个软件组件或系统组件来评估一个或多个感兴趣的属性。

调试：定位错误、发现错误根源。

调试是识别错误的根本原因并纠正它的过程。

与测试相比，测试是最初检测错误的过程，调试是测试成功的结果。在一些项目中，调试占用了总开发时间的50%。对于许多程序员来说，调试是编程中最困难的部分。

和测试一样，调试也不是一种提高软件质量的方法，但它也是一种诊断缺陷的方法。软件质量必须从一开始就构建。构建高质量产品的最佳方法是仔细开发需求，设计良好，并使用高质量的编码实践。调试是最后的手段。

重构

重构：在不改变功能的前提下优化代码。

重构是改变软件系统的过程，即它不改变代码的外部行为，但又改进其内部结构。重构会带来短期的时间/工作成本，以获得长期的利益，并对您的系统的整体质量进行长期的投资。