软构复习3 软件构造过程与版本管理

一、SDLC（软件开发的生命周期）

从无到有，从1到n

二、软件流程模型：
两类基本类型：
线性过程，迭代过程

现有的软件流程模型：

瀑布过程：

• 线性推进

• 阶段划分清楚

• 整体推进

• 无迭代

• 管理简单

• 无法适应需求增加/变化

 

增量过程（非迭代）：

• 线性推进

• 增量式（多个瀑布的串行）

• 无迭代

• 比较容易适应需求的增加

V型模型：用于验证，是瀑布式的延伸

原型过程（迭代）

迭代：开发出来之后由用户试用/评审，发现问题反馈给开发者，开发者修改原有的实现，继续交给用户评审。

循环往复这个过程，直到用户满意为止。 时间代价高，但开发质量也高。

螺旋（迭代）

 

 三、敏捷开发：

通过快速迭代和小规模的持续改进，以快速适应变化

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

四、软件配置管理(SCM)和版本控制系统(VCS)

软件配置管理：追踪和控制软件的变化

软件配置项（SCI）：软件中发生变化的基本单元（例如：文件）（build-time,component,period）

基线：软件持续变化过程中的“稳定时刻”（例如：对外发布的版本）

 

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

版本控制：为软件的任意特定时刻指派一个唯一的编号，成为身份标识

用于：回退到上个版本，比较两个版本之间的差异，备份，合并，在多个开发者之间共享协作，记录每个开发者的动作，方便审计

仓库：即于SCM中的CMDB

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

文件：一个独立的配置项

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

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

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

版本控制系统（VCS）

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

集中式版本控制系统：仓库存储于独立的服务器， 支持多开发者之间的协作

分布式版本控制系统：仓库存储于独立的服务器+每个开发者的本地机器

五、Git：

git仓库的三个组成部分：

 

git directory：本地的CMDB

working directory：工作目录：本地文件系统

staging area：暂存区：将工作目录和Git仓库隔离开

 文件的三种状态：已修改（但是未交到缓存区），已暂存（交到了暂存区域），已提交（工作目录和Git目录中的文件一样）

Object Graph：版本之间的演化关系图，一条边A->B表征了“在版本B的基础上作出变化，形成

了版本A”（存储在git仓库的git directory中）

一条有向无环图

commit就是object图中的一个节点

一般：一个commit指向一个父亲

两个commit指向一个父亲：分支

一个commit指向多个父亲：合并

HEAD指向当前工作的commit

一个分支只是一个指向一个commit的名称

结点 一个 commit 存储一个树形结点。tree 中包含了数个 blob；每个 blob 是一个压缩了的仓库文件，不保存文件名信息。

对于每个文件的每个版本（或是不同文件名但相同内容的文件），Git 只会存储一个 blob，而允许多个 commit tree 指向同一个 blob。 一个 commit 中与之前相比未发生变化的文件，无需重复存储。文件未发生变化，则后续多个版本始终指向同一个 blob；文件发生变化了，存储两份不同的 blob，两个版本指向不同的 blob。

 

软件构造的一般过程包括编码、重构、调试、测试、性能分析、代码评审、构建。

编码 从用途上划分：编程语言、建模语言、配置语言、构建语言

从形态上划分：基于语言学的构造语言、基于数学的形式化构造语言、基于图形的可视化构造语言

建模语言：用于可视化、推理、验证和传达系统设计 配置语言：用于配置程序的参数和初始设置

代码评审 结对编程 走查 正式评审会议 自动化评审 性能分析 动态分析：执行程序并观察现象、收集数据、分析不足 Profiling：对代码的运行时状态和性能进行度量，发现代码中的潜在问题