软件的生命周期

从0到1

涉及到的过程有：计划->分析->设计->实现->测试->维护等。

从1到n

涉及到的过程有：软件的更新与老化、不同软件间的相互取代等。

传统软件处理模型

选择模型的依据有：适应变化的能力、开发效率、项目管理的复杂性、软件质量等。

线性模型

瀑布模型

按照步骤依次实现，管理简单但是应对变化的代价高。

增量模型

以增量的方式实现瀑布模型，较容易适应需求的增加。

V模型

瀑布模型的扩展，强化了测试的重要性。

迭代模型

原型法

在原型上不断迭代以发现用户需求，从而在早期获得足够用户的反馈，提高开发质量，但相应的时间代价也会提高。

螺旋模型

一种风险驱动的过程模型，用周期性的方法进行系统开发。

敏捷开发

快速迭代

涉及到：用户参与、短期开发、大量测试等。

极限编程

1. 描述需求（故事、情景对话等）
2. 设计原型
3. 编写代码（TDD、结对编程等）
4. 持续集成测试
5. 冲刺模型
6. 项目管理（任务墙、目标图）

软件配置管理（SCM）

主要用于追踪和控制软件的变化。

软件配置项（SCI）

软件配置管理的基本单位，包括源代码、数据、文件、软件、硬件、环境等。

基线

是在某时间点上通过评审和认可的版本，也是后续变化的基点。

配置管理数据库（CMDB）

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

版本控制系统（VCS）

分为本地管理、集中管理（通过云端交互）、分布式管理（用户直接交互或通过云端交互）三种。

Git

Git仓库

1. .git目录：存储所有版本、控制数据，相当于本地CMDB；
2. 工作目录：本地文件系统；
3. 暂存区：隔离工作目录和Git仓库。

文件三种状态

1. 已修改：工作目录已修改，但未添加到暂存区（可用git add指令）
2. 已暂存：修改文件已添加到暂存区，但未提交到.git目录（可用git commit指令）
3. 已提交：工作目录与.git目录文件相同。

Git的对象图

指代版本之间的演化关系，其中A->B指代B是A的父版本。

Git中仅存储发生变化的文件，若文件未发生变化，则后续多个版本始终指向同一个文件。
从另一台机器/服务器复制git项目意味着复制对象图，可用git clone指令完成。

Git的基本指令

广义的软件构造

编程

1. 编程语言，如C、C++、Java、Python等；
2. 建模语言，以一定的规则来设计系统，如UML等；
3. 配置语言，配置程序的参数和初始设置，如XML等；
4. 构建语言，如XML等。

静态代码评审

包括结对编程、走查、正式评审会议、利用工具进行自动化评审等。
提高了程序员对代码结构的理解，并有助于确保代码符合行业标准。

动态代码评审

通过执行程序，对运行时状态和性能进行度量，发现代码中的潜在问题，从而分析不足并且改正。

调试与测试

1. 测试：用以确保程序能够正常运行并满足所有需求；
2. 调试：识别错误的根本原因并纠正。
   这两种行为用于发现软件问题，并不会提高软件质量。

重构

使用相应工具，在不改变功能的前提下优化代码。

狭义的软件构造

涉及build的场景

1. 编译代码；
2. 打包和测试解释型语言，如Python等；
3. 编译和打包基于web的应用程序；
4. 执行单元测试；
5. 进行静态分析；
6. 通过不同格式的输入文件，生成可读的PDF或者HTML文档。

编译型语言

通过编译源文件得到目标文件，然后被链接入类库或者可执行程序中，最终得到可安装到目标机器的发布包。
例：C、C++、Java和C#等。

解释型语言

编译器直接将源文件存储在可安装到目标机器的发布包中，不需要对象树。
例：Perl、Python等。

基于Web的应用程序

综合了编译型语言（如Java源文件）和解释型语言（如HTML文件）的构建方法。

build的组成

1. 源树：程序的源代码的磁盘文件结构，也通常反映了软件的体系结构。
2. 对象树：一个单独的树，存储构建的对象文件或可执行程序。
3. 编译工具：将人可读的源文件转换为机器可读的可执行程序文件。
4. 包装发布和目标机器：生成用户端可安装程序。
5. 包装类型：有档案文件、软件包管理工具、定制的GUI安装工具等。

build过程

1. 开发人员构建：从VCS获得源代码并进行私人开发；
2. 发布版本：为测试组、用户提供一个完整的软件包；
3. 健全性构建：与发布版本类似，并非针对客户，趋向于完全自动化。

build工具（Java）

1. Make
2. Ant
3. Maven
4. Gradle
5. Eclipse
6. ……