传统软件的过程模型
基本的类型
线性过程、迭代过程
现有的模型
瀑布过程、增量过程、V字过程、原型过程、螺旋模型
选择合适的过程模型的依据
用户参与度有多大
开发效率/管理复杂度
开发出的软件的质量
waterfall(sequential,non-iterative)
requirements -> design -> implementation -> verification -> maintenance
线性推进
阶段划分清楚
整体推进
无迭代
管理简单
无法适应需求增加
incremental(non-iterative)
系统被分成很多小的开发项目
首先处理最高优先级的需求
某一部分一旦被开发出来就被冻结了
线性推进
增量式(多个瀑布模型的串行)
无迭代
比较容易适应需求的增加
V-Model(for verification and validation)
可以是瀑布模型的一个扩展
测试之后的检查环节结束之后,再回去修改
prototyping(iterative)
software prototyping是开发出一个软件的原型,但是不是软件的最终版本
过程
确认基本需求
开发原型
评审
增强提升原型
如下图所示,也就是在原型上不断的迭代,发现用户变化的需求
好处
卡发出来之后由用户试用/评审,发现问题反馈给开发者,开发者修改原有的实现,继续交给用户评审
循环往复这个过程,直到用户满意为止,时间代价高,但开发质量也高
spiral(iterative)
多轮迭代几倍遵循瀑布模式
每轮迭代由明确的目标,遵循原型过程,进行严格的风险分析方可进入下一轮迭代
agile development(敏捷开发)
通过快速迭代和小规模的持续改进,以快速适应变化
agile = 增量+迭代
每次迭代处理一个增量
特点
极限的用户参与
极限的小步骤迭代
极限的确认/验证
extreme programming(XP)
软件配置管理(SCM)
追踪和控制软件的变化
软件配置项
软件中发生变化的基本单元(例如:文件)
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指向两个父亲:合并
一个branch是一个指向一个commit的名字
head指向当前的commit
和传统的版本控制系统
传统VCS存储版本之间的变化(行)
git存储发生变化的文件(而非代码行),不变化的文件不重复存储
git command
git merge
实际上是将当前分支于master分支合并,也就是两个分支同时指向当前分支
others
欢迎关注公众号BBIT
让我们共同学习共同进步!