重点掌握：软件开发过程与版本控制工具

Software Development Life Cycle (SDLC) 软件开发生命圈（了解即可）

从无到有，从有到好。

Traditional Software Process Models

要求

区别不同开发过程模型的异同

根据不同场景给出相应模型

线性过程 Linear：顺序，要求一点要明确，难以更改
迭代过程 Iterative：每个阶段给用户反馈，用户需求不明确

选择合适模型依据：用户参与程度，适应变化能力，开发效率，管理复杂段，开发出的软件质量

瀑布过程 Waterfall (Linear, non-interative)

线性推进、阶段划分清楚、整体推进、无迭代、管理简单

无法适应需求增加/变化(prohibitively costly)

用户只在最后一个阶段看到？？

增量过程 Incremental (non-iterative)

线性推进、增量式（多个瀑布的串行、无迭代、比较容易适应需求的增加

系统切成小模块，每个模块/增量Waterfall，每个模块都要能运行，模块之间不影响，模块接口要简单，要求比较稳定。

V字模型 V-Model (for verification and validation)

瀑布模型的扩展开发，强调每个阶段测试

瀑布阶段在code阶段之后向上弯曲，对 Life Cycle 的每个阶段及相关阶段进行测试。

原型过程 Prototyping (iterative)

迭代：开发出来之后由用户试用/评审，发现问题反馈给开发者，开发者修改原有的实现，继续交给用户评审。在这个过程中，用户需求不明确，循环往复这个过程，直到用户满意为止。时间代价高，但开发质量也高。

螺旋模型 Spiral (iterative)

适用于非常复杂的过程
多轮迭代基本遵循瀑布模式
每轮迭代有明确的目标，遵循“原型”过程，进行严格的风险分析，方可进入下一轮迭代

Agile Development 敏捷开发

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

将任务划分成一个个小规模的任务，因此较小的团队也能够适应大规模软件的开发。在每个小步骤的迭代中，用户可以参与开发，软件可以随时修正，质量因此得到了保证。因此，敏捷开发是一次次小迭代，将任务细分成一个个小任务，在每个小任务上完成迭代。

敏捷宣言 Agile Manifesto + 个人和交互高于过程和工具 + 工作软件高于全面的文档（不需要文档） + 客户合作高于合同谈判（客户参与） + 应对变化高于遵循计划（快速适应变化）

比原型模型更适应于满足客户需求，风险较低

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

极限编程 (XP, eXtreme Programming)

协作编程（两人编程）、测试驱动、测试与编程绑定

极限编程关注于测试驱动的开发(TDD)，自动化构建、持续集成、持续交付。

Software Configuration Management (SCM) and Version Control System (VCS) 软件配置管理与版本控制系统

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

SCI (Software Configuration Item) 软件配置项: 软件中发生变化的基本单元（如文件）。

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

CMDB：配置管理数据库（存储软件的各配置项随时间发生变化的信息+基线），分为本地和远程

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

Why version control is required

for individuals
1. Reverting to a past version 回滚到上一个版本
2. Comparing two different versions 比较两个版本的差异
3. Pushing full version history to another location 备份软件版本历史
4. Pulling history back from that location 获取备份
5. Merging versions that are offshoots of the same earlier version 合并
for teamwork
1. Communications and share/merge works among multiple developers 在多个开发者之间共享和协作
2. Logging individualized works of different developers for auditing 记录每个开发者的动作，便于“审计”

Version control terminology 版本控制术语

Repository: a local or remote store of the versions in a project 仓库：即于SCM（软件配置管理）中的CMDB（配置管理数据库）
Working copy: a local, editable copy of a project that we can work on 工作拷贝：在开发者本地机器上的一份项目拷贝
File: a single file in the project 文件：一个独立的配置项
Version or revision: a record of the contents of the project at a point in time 版本：在某个特定时间点的所有文件的共同状态
Change or diff: the difference between two versions 变化：即code churn，两个版本之间的差异
Head: the current version HEAD：程序员正在其上工作的版本

Version Control System (VCS)

三类版本控制系统 - Local VCS 本地版本控制系统 - - 仓库存储于开发者本地机器无法共享和协作。 - Centralized VCS（集中式版本控制系统） - - 仓库存储于独立的服务器，支持多开发者之间的协作 - Distributed VCS（分布式版本控制系统） - - 仓库存储于独立的服务器+每个开发者的本地机器

Git

版本图 <--> git命令

git文件状态 --> 目录

Git 命令

创建本地仓库：git init

文件添加到本地仓库：git add

文件提交到本地仓库：git commit -m “commit message”

查看工作区状态：git status

比较差异修改：git diff

回到上一个版本：git reset --hard HEAD^

穿越到指定提交：git reset --hard

清空暂存区：git rm --cached

丢弃工作区更改: git checkout --

丢弃暂存区更改: git reset HEAD

丢弃本地版本库更改: git reset --hard HEAD^

添加远程仓库关联：git remote add origin

创建分支：git branch

切换到分支：git checkout

创建并切换分支：git checkout -b

合并指定分支到当前分支：git merge : 如果是把一个做了更改的分支合并到一个未作更改的分支，那么就将未作更改的分支的指针移到做过更改分支的指针的位置。如果两个分支都做了更改，那么就找到更改的共同的祖先节点，以祖先节点为开始，将两个分支所有做出的更改都放在一起，在工作分支上形成一个新的节点。

删除分支：git branch -d : 只是删除分支指针，没有删除在该分支上的commit

clone: git clone -b

git push -u origin master

git push ：远程端若更改后要先与本地端合并后才能push

git pull : 从远程获取最新版本并merge到本地

git fetch : 从远程获取最新版本到本地，不会自动merge

Git repository

.git directory: 本地的 CMDB（配置管理数据库）
Working directory 工作目录：本地文件系统
Staging area 暂存区：隔离工作目录和Git仓库
已修改 Modified: different between file in working directory and file in git directory
已暂存 Staged: file added into staging area
已提交 Committed: file keep same in working directory and git directory

Git Object Graph

Object Graph: 版本演化关系图，是一个有向无环图。

A->B: 在版本B的基础上作出变化，形成了版本A

一个父对象可以有多个子对象（创建了分支）；除了initial commit没有父对象，一个子对象的父对象最多两个（合并分支）。

branch: a name that points to a commit

HEAD: pointing to the current commit

Git Object Graph 储单个文件的每个版本一次，并允许多次提交来共享该副本。若文件没有变化，则后续多个版本始终指向同一个文件；若文件发生变化了，存储两份不同的文件，两个版本指向不同的文件。

每个节点的存储的信息是文件信息指针tree、作者信息author、提交者信息commiter，而在每个tree中，包含所有文件的信息，对于每个文件指针，如果文件变化了，则指向变化后的新文件，如果没有变化，则指向上次提交的文件，不做重复存储。

传统VCS：存储版本之间的变化（行）。优点：存储空间较小。缺点：由于存储的是变化情况，取出指定时期的文件要先取出原文件，再取出变化内容，最后做合并形成新文件，所以取出文件的时间复杂度较高。
Git：存储发生变化的文件（而非代码行），不变化的文件不重复存储，这样易于取出特定版本文件、易于创建分支（创建分支时，需要进行叠加来获得当前版本）。缺点：空间复杂度增加。

General process of software construction

$广义软件构造过程$

$狭义软件构造过程$

Programming

Construction Languages
purpose 用途上划分
1. Programming languages (e.g., C, C++, Java, Python) 编程语言
2. Modeling languages (e.g., UML) 建模语言
3. Configuration languages (e.g., XML) 配置语言
4. Build languages (e.g., XML) 构建语言
form 形态上划分
1. Linguistic-based 基于语言学的构造语言
2. Mathematics-based (formal) 基于数学的形式化构造语言
3. Graphics-based (visual) 基于图形的可视化构造语言

Programming Languages

IDE 集成开发环境包括 - Source code editor with intelligent code completion, code refactoring tool 源代码编辑器：智能代码补全工具、代码重构工具 - File management tool 文件管理 - Library management tool 库管理 - Class browser, object browser, class hierarchy diagram 软件逻辑实体可视化 - Graphical User Interface (GUI) builder 图形化用户界面构造器 - Compiler, interpreter 编译器、解释器 - Build automation tools 自动化build工具 - Version control system 版本控制系统 - Extensible by more external third-party tools 外部的第三方工具

Modeling Languages

目的：可视化、推理、验证和交流系统的设计。

e.g. UML (Unified Modeling Language)

FuLucas's blog

软件构造笔记三——软件构造过程与配置管理
Click back to the top

Home

About

Archives

软件构造笔记三——软件构造过程与配置管理