软件构造（三）

一、传统软件的过程模型

基本的类型

线性过程、迭代过程

线性推进、阶段划分清楚、整体推进、无迭代、管理简单、、无法适应需求增加

1.1.incremental(non-iterative)

系统被分成很多小的开发项目，首先处理最高优先级的需求，某一部分一旦被开发出来就被冻结了，线性推进，增量式（多个瀑布模型的串行），无迭代，比较容易适应需求的增加

1.2.V-Model(for verification and validation)

是瀑布模型的一个扩展，测试之后的检查环节结束之后，再回去修改

1.3.prototyping（iterative）

software prototyping是开发出一个软件的原型，但是不是软件的最终版本

过程：确认基本需求--开发原型--评审--增强提升原型；在原型上不断的迭代，发现用户变化的需求

好处

由用户试用/评审，发现问题反馈给开发者，开发者修改原有的实现，继续交给用户评审，循环往复这个过程，直到用户满意为止，时间代价高，但开发质量也高

1.4.spiral（iterative）

多轮迭代几倍遵循瀑布模式，每轮迭代由明确的目标，遵循原型过程，进行严格的风险分析方可进入下一轮迭代

1.5.agile development（敏捷开发）

通过快速迭代和小规模的持续改进，以快速适应变化，agile = 增量+迭代，每次迭代处理一个增量

特点：极限的用户参与、极限的小步骤迭代、极限的确认/验证

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

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

二、版本迭代

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

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

版本控制（VCS）：古老的版本控制方法：通过过复制文件并修改文件名

为软件的任一特定时刻的形态指派一个位移的编号，作为“身份标识”

可用于：回退到上一个版本、比较差异、备份软件版本历史、获取备份、合并、在多个开发者之间共享和协作、记录每个开发者的动作，便于查看

仓库：软件配置管理中的配置管理数据库

文件：一个独立的配置项

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

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

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

本地版本控制系统：仓库存储与开发者本地机器，无法共享和协作

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

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

三、git

git repository

git仓库由三个部分

.git ：本地的CMDB

工作目录：本地文件系统

暂存区：隔离工作目录和git仓库（staging area）

每一个文件属于上述三种状态之一

object graph

版本之间的演化关系图，一条边A->B代表B基础上形成A

commit

是对象图中的节点

多个commit之间的关系一般来说由三种：

每个commit指向一个父亲

多个commit指向同一个父亲：分支

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

一个分支是指向一个commit的名字

传统VCS存储版本之间的变化（行）

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

git command

git merge 将当前分支于master分支合并，也就是两个分支同时指向当前分支