6.8软件构造笔记4

1.传统的软件过程与模型
两个基本类型：liner（线性过程），iterative（迭代过程）

五个过程与模型：
①Waterfall （瀑布过程）：线性非迭代。

线性推进，阶段划分清楚，整体推进，过程简单，但是无法适应需求的变化。

 

②Incremental（增量过程）：无迭代
线性推进，增量式（多个瀑布的串行），比较容易适应需求的增加。

 

③V-Model（V字模型）：用于校验与验证
可以认为是瀑布过程的一种扩展

④Prototyping（原型过程）：迭代
在原型上持续不断的迭代，发现用户变化的需求，循环往复，直到使用户满意为止（开发周期长，但开发的质量也高）。
⑤Spiral（螺旋过程）：迭代
·多轮迭代基本遵循瀑布过程
·每轮迭代有明确的目标，遵循“原型”过程，进行严格的风险分析，方可进入下一轮迭代。

2.敏捷开发
通过快速迭代以及小规模的持续改进，以快速适应变化。
Agile = 迭代+增量——每次迭代处理一个增量

2.2 Software Configuration Management(SCM) and Version Control System(VCS)
1.SCM 与 VCS
软件配置管理：追踪和控制软件的变化。

软件配置项（SCI）：软件中发生变化的最小单元。

基线：软件变化过程中的“稳定时刻”。

为了存储各配置项随时间变化的信息和基线信息，就有一个数据库来管理这些内容，即配置管理数据库(CMDB)。

VCS分为三种：
①本地版本控制系统：仓库存储在本地开发系统，无法合作和共享；
②集中式版本控制系统：仓库存储在独立的服务器上，支持多开发者之间的合作，但没办法抵抗服务器崩溃导致无法开发的风险；
③分布式版本控制系统：仓库存储于在每个开发者的本地机器+独立的服务器。

2.Git
git是一个典型的分布式管理系统。其选用的数据结构是一张有向无环图，每次commit会在图上增加一个新的节点，并将HEAD指向这个节点。通常一个子节点有一个父节点，当一个父节点有多个子节点时说明创建了一个分支，而当一个子节点有多个父亲节点时说明进行了合并。

 

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

传统VCS存储的是文件每个版本之间的变化，这种办法的优点是存储空间较小，但由于存储的只是变化，取出指定时期的文件要先取出原文件，再取出变化内容，最后做合并形成新文件，所以取出文件的时间复杂度较高。git存储的则是文件，所以取出特定版本的文件比较方便，但是代价的是空间复杂度较高。

关于分支的合并：对于合并操作来说，如果是把一个做了更改的分支合并到一个未作更改的分支，那么就将未作更改的分支的指针移到做过更改分支的指针的位置。

而如果两个分支都做了更改，那么就找到更改的共同的祖先节点，以祖先节点为开始，将两个分支所有做出的更改都放在一起，在工作分支上形成一个新的节点。

注意：删除分支时，只是删除了分支指针，并没有删除在该分支上的commit。

 

2.3 Process, Systems and Tools of Software Construction
1.软件构造的一般过程
广义上的软件构造：Design-> Programming-> Debug-> Testing-> Build-> Release

狭义上的软件构造（专指Build过程）：Validate-> Compile-> Link-> Test-> Package-> Install-> Deploy

2.关于代码评审
原则：
①不要重复你的代码(DRY)
②仅在需要的地方做注释
③快速失败/报错
④避免使用幻数
⑤一个变量有且仅有一个目的
⑥使用好的命名
⑦避免使用全局变量
⑧返回结果而非打印它
⑨使用空白符提升可读性

远离bug：
（1）通常来说，代码评审使用人的审查来发现bug。DRY使得你只用在一处地方修复bug，避免bug的遗漏。注释使得原作者的假设很清晰，避免了别的程序员在更改代码的时候引入新的bug。
（2）快速报错/失败使得bug能够尽早发现，避免程序一直错更多。避免使用全局变量使得修改bug更容易，因为特定的变量只能在特定的区域修改。
易读性：
对于隐晦或者让人困惑的bug，代码评审可能是唯一的发现方法，因为阅读者需要尝试理解代码。使用明智的注释、避免幻数、变量目的单一化、选择好的命名、使用空白字符都可以提升代码的易读性。
可更改性：
DRY的代码更具有可更改性，因为代码只需要在一处进行更改。返回结果而不是打印它使得代码更可能被用作新的用途。