第三章 软件构造过程与配置管理

第三章 软件构造过程与配置管理

Software Development Lifecycle(SDLC)软件开发生命周期

From 0 to 1 从无到有

From 1 to n 从有到好

传统软件开发模型

两种基本的方式

• 线性过程

  • 用户需求要明确，不易更改
  • 

• 迭代过程

  • 各阶段给用户反馈确定需求
  • 

五种模型

• 瀑布过程（Waterfall (Linear, non-iterative)）

  • 

  • 在概念、启动、分析、设计、构建、测试、实施和维护阶段，进展被视为稳步向下流动（如瀑布），易于使用，但事后更改代价高昂。

  • 特点

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

• 增量过程（ Incremental (non-iterative)）

  • 

  • 切成小模块，每次开发一个小模块

  • 要求

    • 每个小增量都能单独运行
    • 新开发的不能影响之前开发的

  • 特点

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

• V字过程（V-Model (for verification and validation)）

  • 

  • 每个阶段进行验证测试

• 原型过程（Prototyping (iterative) ）

  • 

  • 先开发一个原型(一般是一个可运行的界面)，供用户评价，在圆形的基础上不断地迭代发现用户变化的需求，如果原型不好也可抛弃

  • 优点

    • 开发者早期可以从用户获得有价值的反馈
    • 开发质量高，但时间代价高
    • 适应用户的变化

  • 缺点

    • 未经过整体分析设计，整体架构不好

• 螺旋模型（Spiral (iterative)）

  • 

  • 非常复杂的过程：

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

  • 适用于大程序，风险不确定的程序，高质量的程序

选择模型的依据

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

Agile Development（敏捷开发）

• 通过快速迭代和小规模的持续改进，以快速适应变化。
• 适用于需求不稳定的程序，当需求不稳定时，敏捷模型大于原型模型
• Agile = 增量 + 迭代，每次迭代处理一个小规模增量
• 极限的用户参与，极限的小步骤迭代，极限的确认 / 验证

敏捷宣言

• 不注重文档
• 适应变化，而不是遵循合同
• 客户参与开发过程中
• 每天团队交互

极限编程

• 列出需求不要文档，先写测试，编程目的是过测试。
• 

SCM和VCS

Software Configuration Management (SCM) and Version Control System (VCS)

软件配置管理

• 追踪和控制软件的变化
• 软件的任何组成部分（源代码、数据、文档、硬件、各种环境）都可能随着软件生命周期中的时间而更新。
• 软件配置项：软件中发生变化的基本单元（例如：文件）

版本控制和基线的建立

• 版本控制

  • 为软件的任一特定时刻（ Moment ）的形态指派一个唯一的编号，作为"身份标识"

  • 为什么需要版本控制

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

  • 版本控制的术语

    • Repository 仓库：即于SCM中的CMDB
    • Working copy 工作拷贝：在开发者本地机器上的一份项目拷贝
    • File 文件：一个独立的配置项
    • Version or revision 版本：在某个特定时间点的所有文件的共同状态
    • Change or diff 变化：即code churn，两个版本之间的差异
    • Head 程序员正在其上工作的版本

  • 版本控制方法

    • Local VCS（本地版本控制系统）

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

    • Centralized VCS （集中式版本控制系统）

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

    • Distributed VCS（分布式版本控制系统）

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

• 基线的建立

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

CMDB ：配置管理数据库

• 存储软件的各配置项随时间发生变化的信息+基线

Git

实际的三个区域

• workspace
• Local repository
• Remote repository

注意：staging只是将文件打上标签

Git仓库的三个部分

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

文件的三个状态

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

Object Graph

• 

• 版本之间的演化关系图

• 一条边 A->B 表征了"在版本 B 的基础上作出变化，形成了版本 A "

• 有向无环图

• 历史图中的每个节点都是项目的一个提交，是该时间点所有文件的完整快照。

  • 除了初始节点，每个commit指向一个父亲
  • 多个commit指向同一个父亲：分支
  • 一个commit指向两个父亲：合并

• 只存储变化的文件，不变的文件存的是文件指针

和传统的VSC对比

• 传统VCS

  • 存储版本之间的变化（行）

• Git

  • 存储发生变化的文件，不变化的文件不重复存储

git 命令

• git checkout -b xx 创建并切换分支

• git checkout -d xx 删除分支

• git checkout xx 切换分支

• git merge xx 合并到当前分支，注意原分支还在

• git commit

• git fetch origin 一定要先获取最新版本

• git push origin xx

• 示例

  • 

  • 

软件构建的一般流程

(1) Programming

• Construction languages

  • 从用途上划分

    • 编程语言（C,C++）

    • 建模语言（例如UML）

    • 配置语言（XML,JSON）

      • 配置程序

    • 构建语言（XML）

  • 从形态上划分

    • 基于语言学的构造语言
    • 基于数学的形式化构造语言
    • 基于图形的可视化构造语言

• Programming tools

  • 集成开发环境

    • 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 外部的第三方工具

(2) Review and static code analysis（代码评审）

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

• 形式

  • Formal code review 正式的代码评审会议

  • Lightweight code review 轻量级的代码评审

    • 两个人一起编程Pair programming

  • Static code analysis 利用工具进行的静态代码分析

    • 该过程提供了对代码结构的理解，有助于确保代码符合行业标准。
    • 自动化工具可以帮助程序员和开发人员进行静态分析。

• 目的

  • 改进代码
  • 提升程序员，相互学习

(3) Dynamic code analysis / profiling

• 动态分析：要执行程序并观察现象、收集数据、分析不足
• 对代码的运行时状态和性能进行度量，发现代码中的潜在问题

(4) Debugging and Testing

• 测试：发现程序是否有错误
• 调试：定位错误、发现错误根源

(5) Refactoring

• 重构：在不改变功能的前提下优化代码（不改变外部行为的前提下改善内部结构）
• 重新排列代码，进行一系列小的、保留语义的转换，让代码更易于维护和修改