软件构造--Chapter3总结

软件构造过程与配置管理

Software Develpoment Lifecycle

Software Develpoment Lifecycle，简称SDLC，即从无到有的过程。大体包括六个部分，Planning、Analysis、Design、Implementation、Testing&Integration、Maintenance。前期需要完成计划、分析、设计等过程，而我们直观认知的写代码部分则在实施阶段，目前我们常常会忽略测试与集成、维护阶段，有规模较小、不涉及这些阶段的因素。大部分的精力往往花费在前期、后期，而并非中期的写代码实现的阶段。当有新的功能需求时，又回到第一阶段，重新开始SDLC。

如何保持软件生命力不随时间推移而消亡是一个重要的问题，而不断推出适合的新功能，以此来吸引用户是一个不错的解决方法。在软件功能不断新增、维护的过程中，软件的版本也在一点点更新，他们或许是完成了细微的改动，或许是一次大的版本更新。

Traditional Software Process Models

传统的软件演变过程有线性过程和迭代过程。


也有些其他的模型，例如瀑布过程、增量过程、V字模型、原型模型、螺旋模型等。根据用户参与程度、开发效率、软件质量来选取对应的模型，只有适合自己的才是最好的。

瀑布过程

瀑布过程属于线性推进，各个阶段的划分都比较清晰，在整体上是推进的，并没有迭代。瀑布过程管理起来相对简单，但是无法适应需求增加/变化。

增量过程

增量过程属于线性推进，是多个瀑布的串行，并没有迭代。增量过程比较容易适应需求的增加。

V字模型

V字模型是瀑布模型的扩展，过程步骤是弯曲向上的，而不是线性向下的，形如V字，故称V字模型。
V字模型主要分为三个阶段：项目定义、项目实施、项目测试和整合。其中项目定义从操作概念到需求和构建，再到细节上的设计，而项目测试和整合从整合、测试、验证到系统级别验证、确认，再到操作和维护。在项目测试和整合阶段，一步步完成验证和确认，渐渐回到起点（等待新需求）。

原型模型

用户的需求是不断变化的，软件设计者和实现者需要根据用户反馈进行修改。原型模型就是在原型上持续不断的迭代发现用户变化的需求。
开发者开发出来后由用户评审，发现问题就进行反馈，开发者根据反馈进行修改，再次评审，这一过程成为迭代。一次次完成迭代，直至用户满意为止。这样下来，以时间开销换取较高的开发质量。毕竟，风险与收益并存，不能得兼，总要牺牲一些的。

螺旋模型

螺旋模型是一个非常复杂的过程。

螺旋模型涉及多轮迭代，基本遵循瀑布模式。每轮迭代有明确的目标，又遵循“原型”过程，只有进行严格的风险分析符合要求，才能进入下一轮迭代。

Agile Development

Agile Development，即敏捷开发，通过快速迭代和小规模的持续改进，以快速适应变化。

每一次迭代，可能经过的步骤不尽相同。具体的迭代的时间越多，需要经历的步骤也越多。
在这样的工作速度下，需要每天开一次例会确定一下各工作者的分工、进度；根据不同进度，1~4周会完成一次任务进度的冲击。

Software Configuration Management（SCM）

SCM是追踪和控制软件的变化，它的核心是版本控制和基线的确立，软件配置项是SCM的基本单元。
基线是软件持续变化过程中的“稳定时刻”，例如对外发布的版本。
版本是为软件的任一特定时刻的形态指派一个唯一的编号，可以理解为ID。常见的版本号形如X.X.X，第一个X是major，第二个X是minor，第三个X是patch，三个X的更新对应着不同级别的软件修改。

Version Control System（VCS）

在软件开发过程中会推出众多版本，开发人员需要对这些版本进行控制，以便回滚到历史版本、比较版本差异等。同时，版本控制也有利于协同开发，将多个开发者的工作合并，也便于记录开发者的动作，便于“审计”。
本地版本控制系统，仓库存储于开发者本地机器，不便于共享与协作；集中式版本控制系统，仓库存储于独立的服务器，便于多开发者协同开发，常见的有CVS,SVN；分布式版本控制系统，仓库存储于独立的服务器、同时也存储于每个开发者的本地机器，对协同开发更加便利，常见的有Git。

Git as an example of SCM tool

Git是当今比较流行的版本控制工具，很多代码社区都是基于Git工作的，例如国外的Github、国内的Gitee。

Git的版本控制流程主要涉及三个区域：本地机器代码、本地仓库、远程仓库。
本地机器代码，即平日我们写代码的文件、文件夹等；本地仓库，即存在于本地机器上，缓存提交到远程仓库的文件、文件夹的仓库；远程仓库，即不在本地机器上，在服务器上的存放文件、文件夹的仓库。
Git的所有操作都是在一个图数据结构上进行。在版本之间的演化关系图，一条边A->B代表了在版本B的基础上作出变化，形成了版本A；每个commit指向一个父亲，多个commit指向同一个父亲–分支；一个commit指向两个父亲–合并。
在Git中，未发生变化的文件并不进行重复存储。

文件未发生变化，则后续多个版本始终指向同一个文件；文件发生编发，存储两份不同的文件，两个版本指向不同的文件。
Git的配置如下链接所示：
[https://blog.csdn.net/qq_53940095/article/details/124434632]

Git Bash

作为初学者，还是建议学习通过使用Git Bash使用Git工具；在有一定熟练度之后，再使用IDE集成的Git工具（确实挺方便的）。
要对现有的某个项目开始用Git管理，只需要到此项目所在目录执行指令git init，用git add命令告知Git开始对这些文件跟踪，再进行提交。

git init
git add*.c
git add readme.txt
git commit -m 'initial project version'

从现有仓库克隆：

git clone [url]

确定哪些文件当前处于什么状态

git status

查询具体修改哪些地方

git diff
git diff --cached

跳过使用暂存区域、移除文件

git commit -a
git rm

对远程仓库的操作

git remote
git remote add [shortname][url]
git fetch
git pull
git push [remote-name][branch-name]
git remote show [remote-name]
git remote rm

General process of software construction

一般的软件建设的过程大概有七大部分：Programming（coding）编码、Build构建、Code review Static code analysis代码评审、Dynamic code analysis/profiling性能分析、Testing测试、Debugging调试、Refactoring重构

Programming

构建的语言有很多种类。从用途上划分，有编程语言（C，C++，Java等）、建模语言（UML）、配置语言（XML、JSON）、构建语言（XML）；从形态上划分，有基于语言学的构造语言、基于数学的形式化构造语言、基于图形的可视化构造语言。

Review and static code analysis

通过代码评审，可以发现开发者忽略的错误，规范开发者的代码等。代码评审有多种形式，常见的有结对编程、走查、正式评审会议、自动化评审。
正式代码评审会议是比较传统的代码评审，但同时也非常重要，能够有效发现存在的缺陷。
自动化评审可以通过一些工具进行，如CheckStyle，SpotBugs，PMD等（针对Java）

Dynamic code analysis/profiling

动态分析要执行程序并观察现象、收集数据、分析不足。在动态分析部分，程序要经过充分的测试。其中，可以利用测试度量技术（如覆盖率）确保代码的可能功能被充分测试到。
Profiling用来测量程序程序的时空复杂度，特定指令或函数的调用频率或持续时间，发现代码中潜在的问题。

Debugging and Testing

首先要明确一点，测试不能证明程序没有错误。在测试中我们通过测试用例可以验证在这些用例上是否存在错误。
调试是识别错误的根本原因并对其进行纠正的过程，调试往往是成功测试的后续环节。
测试和调试都不会提升软件质量，它们是发现和解决缺陷的主要手段；提高软件质量要通过认真分析需求、良好进行设计、高质量编码实现。
另外，编程新手常常会使用printf、“sout”之类的地方定位部分错误，这只是十分简单的一种找错方法，调试还是需要通过断点，监测的手段去定位错误并修改，掌握调试是十分重要的。

Refactoring

Refactoring，即重构，是在不改变功能的前提下去优化代码。
在IDE下，如Eclipse、IDEA中，都有提供Refactoring的功能，包括变量重命名、修改包目录等等，为程序员提供了便利。

Build

此部分为狭义上的构建，粗略理解为build-time到run-time，借助工具，将软件构造个阶段的活动“自动化”。
传统编译语言，如C，C++，Java和C#，在编译后得到目标文件，后续被链接入类库或可执行程序中，最终得到可部署到目标机器的发布包；
解释语言没有编译成目标代码，需要一个对象树。源文件本身被收集到发布包，准备安装在目标机器上；编译工具侧重于转换源文件和存储，把它们放在发行包里；编译成机器代码不是在构建时执行的，甚至尽管它可能在运行时发生；
基于Web应用的编译和打包，是编译代码、解释代码、配置或数据文件的混合。有些文件（如HTML文件）是直接从源代码复制的树到发布包，而其他（如Java源文件）首先编译成目标代码。
对于Java语言，常见的Build工具有Make、Ant、Maven、Gradle、Eclipse IDE，而其中Maven和Gradle用到的比较多。Build工具配合相应的build script（告诉工具如何build）使用。