2020春季学期哈工大软件构造学习心得二

前言

上一章主要讲了软件构造的结果形态以及如何是一个“好”的软件
这一章主要学习软件开发遵循着一个什么样的过程

- 软件生命周期与配置管理

From 0 to 1，from 1 to n（从无到有，从有到好）

传统软件过程模拟
两种基本形态：线性过程和迭代过程

已有的模型还有很多：

• Waterfall (Linear, non-iterative) 瀑布过程
  线性推进
  阶段划分清楚
  整体推进
  无迭代
  管理简单
  无法适应需求增加/变化
• Incremental (non-iterative) 增量过程
  线性推进
  增量式（多个瀑布的串行）
  无迭代
  比较容易适应需求的增加
• V-Model (for verification and validation) V字模型
  V字模型表示一个开发过程，它可以被视为瀑布模型的扩展。
• Prototyping (iterative) 原型过程
  在原型上持续不断的迭代（即开发完成后由用户评审，发现问题反馈给开发者，开发者修改后，继续交给用户评审的过程），发现用户变化的需求，循环往复此过程，直到用户满意为止。
• Spiral (iterative) 螺旋模型
  基于给定项目的独特风险模式，螺旋模型指导团队采用一个或多个过程模型的元素，如增量、瀑布或进化原型
  多轮迭代基本遵循瀑布模式
  每轮迭代有明确的目标，遵循“原型”过程，进行严格的风险分析，方可进入下一轮迭代

选择合适模型的依据：适应变化的能力；开发效率；管理复杂度；开发出软件的质量等

敏捷开发

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

• 极限的用户参与
• 极限的小步骤迭代
• 极限的确认/验证

协同软件开发

开源软件构建模型：没有协同管理控制

软件配置管理（SCM）和版本控制系统（VCS）

软件配置管理（SCM）：追踪和控制软件的变化
软件配置项（SCI）：软件中发生变化的基本单元，任何需要管理 的要素都时软件配置项（源代码、数据、文档、软硬件、环境等）
基线：软件持续变化过程中的“稳定时刻”
CMDB ：配置管理数据库存储软件的各配置项随时间发生变化的信息+基线。俗称：仓库

分支和进化图（属于SCI或一个系统）
在分支上进行并行开发，如测试新功能

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

优点是可以回溯上个版本；可以比较两个版本差异；可以备份；可以合并；可在多个开发者之间共享和协作
版本（Version）：在某个特定时间点的所有文件的共同状态
工作拷贝：在开发者本地机器上的一份项目拷贝
HEAD：程序员正在其上工作的版本

Git
git是管理软件演化过程中的变更的工具，可以通过命令，实现workspace,staging,local repository,remote repository之间的转移
文件共有三种状态：已修改，已暂存，已提交

一个Git存储库有三个部分：
1.本地的CMDB（存储所有版本控制数据的存储库）
2.工作目录：本地文件系统
3.暂存区：隔离工作目录和Git仓库

我们使用Git所做的所有操作-克隆、添加、提交、推送、记录、合并…都是在一个图形数据结构上进行的操作，该结构存储项目中的所有文件版本，以及描述这些更改的所有日志项。
Git Object Graph（对象图）存储在存储库的.Git目录中。
从另一台机器/服务器复制git项目意味着复制整个对象图。

Object Graph：版本之间的演化关系图，一条边 A->B表征了“在版本B的基础上作出变化，形成 了版本A”（注意是版本B是parent）

每次提交在对象图中就是一个节点，每个commit指向一个父亲。
多个 commit指向同一个父亲：分支
一个commit 指向两个父亲：合并
Git存储发生变化的文件（而非代码行），不变化的文件不重复存储（与之前commit中未发生变化的文件，无需重复存储）
文件未发生变化，则后续多个版本始终指向同一个文件；文件发生变化了，存储两份不同的文件，两个版本指向不同的文件

软件构造的过程
广义的软件构造过程 (Design$\Rightarrow$Programming$\Rightarrow$Debug$\Rightarrow$Testing$\Rightarrow$Build$\Rightarrow$Release)
狭义的软件构造：
(Build: Validate$\Rightarrow$Compile$\Rightarrow$Link$\Rightarrow$Test$\Rightarrow$ Package$\Rightarrow$ Install$\Rightarrow$ Deploy)

语言从用途上划分：编程、建模、配置和建构语言
从形态上划分：基于语言学的构造语言、 基于数学的形式化构造语言、 基于图形的可视化构造语言
其中比较重要的：
建模语言是任何一种人工语言，它可以用一组一致的规则定义的结构来表达信息、知识或系统，其目的是可视化、推理、验证和交流系统的设计

代码的评审
意在发现开发初期忽略的错误，提高整体质量。评审以各种形式进行，如结对编程、非正式演练和正式检查
轻量级代码审查通常比正式的代码检查需要更少的开销，但是如果处理得当，它同样有效；轻量级评审通常是作为正常开发过程的一部分进行的

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

测试
测试（Testing）：发现程序是否有错误
调试（Debugging）：定位错误、发现错误根源，是确定错误的根本原因并加以纠正的过程。
与测试相反，测试是最初检测错误的过程，调试是成功测试的结果；与测试一样，调试不是提高软件质量的方法，但它是诊断缺陷的一种方法
重构（Refactoring）：在不改变功能的前提下优化代码，它既不改变代码的外部行为，又改进其内部结构。

自动化
版本控制工具
源代码树和对象树（ Source trees and object trees）：一个程序的源代码存储为许多磁盘文件。这种不同的文件排列方式称为源代码树。源树的结构通常反映软件的体系结构。
对象树是一种单独的树层次结构，用于存储由构建过程构建的任何目标文件或可执行程序
这两个是特定开发人员使用的一组源文件和编译的对象文件。
编译工具：获取输入文件并生成输出文件的工具（例如，将源代码文件转换为目标代码和可执行程序）
构建机器（Build machines）：执行编译工具的计算设备
–本地编译环境：软件在与生成计算机相同的目标计算机上执行；
–交叉编译环境：需要两台不同的计算机，目标计算机上具有不同的操作系统或CPU。
发布打包和目标机器（Release packaging and target machines）：软件打包、分发给最终用户，然后安装到目标机器上的方法。
–从源和对象树中提取相关文件，并将其存储在发布包中。
–发布包应该是一个单一的磁盘文件，并且应该压缩以减少下载所需的时间。
–任何不重要的调试信息都应该删除，这样就不会干扰软件的安装。

打包类型：
–存档文件：zip和unzip
–包管理工具：UNIX样式，如.rpm和.deb
–自定义构建的GUI安装工具：Windows样式

–编译器：源文件$\Rightarrow$对象文件
–链接器：多个相关的对象文件$\Rightarrow$可执行程序映像
–基于UML的代码生成器：模型$\Rightarrow$源代码文件
–文档生成器：脚本$\Rightarrow$文档

基于web的应用程序的构建系统是编译代码、解释代码和配置或数据文件的混合体。
一些文件（如HTML文件）直接从源代码树复制到发布包中，而其他文件（如Java源文件）首先被编译成目标代码。

Java编程是动态类加载。生成可执行程序不需要构建时链接步骤。相反，当运行的程序需要Java类时，Java类被单独加载到内存中。没有要加载的单个可执行程序映像。Java程序只是一个动态库的集合，尽管单独的类一次加载一个，而不是作为更大的共享库的一部分。
Java程序需要执行两件事：一，JVM必须提供包含main方法的类的名称。这被用作执行的起点。二，JVM还必须提供一个类路径，该路径用于标识附加类的位置

除了指定可以在其中找到.class文件的目录列表之外，Java类还可以放入更大的归档文件中，即JAR文件。大多数Java应用程序都喜欢使用JAR文件格式（后缀为.JAR），因为操作JAR文件比打包和分发大量.class文件更容易。
JAR文件通常被用来分发程序。
你不仅可以将自己的软件打包成JAR文件，还可以通过获取其他人的JAR文件并将其添加到自己的类路径中来合并第三方软件包。由于动态加载系统，您可以随时更换和升级JAR文件。

是否只有一种方法可以将每个源文件编译并链接到可执行程序中，并且只能生成一种类型的发布包？
实际上，可以存在任何数量的变体，每个变体都使用稍微修改过的构建过程并创建稍微不同的发布包。