跳转至

7.0 Agile and Git

Differences between Agile and Waterfall

  • Waterfall Model (瀑布模型)：
  • Manage the project in strict sequential phases. 例如，调研完成后才能开始设计，设计签署后才能开始开发。
  • 如果瀑布模型的软件项目出错，往往会错得很严重。
  • Agile Development (敏捷开发)：
  • 旨在管理项目并在事情出错时最小化问题。
  • 将大型项目分解为称为iterations (迭代) 的小型、可管理的区块。
  • Development is iterative, while the waterfall model is a one-time activity.
  • Planning is adaptive, while the waterfall model follows the original plan.
  • In agile, the characters are blurred, while in the waterfall model, the characters are clear.
  • Agile welcomes changes in requirements, while the Waterfall model resists changes.
  • Agile uses working software as the primary measure, while the Waterfall model may focus more on documentation.

Core agile development cycle

敏捷开发是一个持续的循环过程，其核心周期包括以下步骤：

  1. Iterations (迭代)：将大型项目分解为小型、可管理的、固定时间间隔的迭代周期。
  2. 有价值的产出：在每次迭代结束时，都会产生一些有价值的东西（例如，可工作的软件功能）。
  3. 用户反馈：迭代的产出应该能够被发布以获取用户或利益相关者的反馈。
  4. 迭代内的阶段（在一个迭代中会经历）： - 根据难度和优先级对当前期望的功能列表进行排序。 - 开始开发列表中最顶端的特性。 - 在迭代结束时，向用户展示已完成的工作。 - 更新功能列表：移除已完成的功能，根据用户反馈添加新功能并重新排列现有功能的优先级。 - 分析 (Analysis)、测试 (Test)、设计 (Design)、编码 (Code) 这些活动在敏捷中是持续进行的，而不是像瀑布模型那样作为一次性的阶段。

How user stories can be used for planning and time estimation

  • Planning (规划)：
  • User stories (用户故事) 是从最终用户的角度描述软件的一个期望功能。
  • 它们将需求分解为可以在短时间内交付的小工作单元。
  • 所有用户故事构成一个主故事列表 (Master story list) 或产品待办事项列表 (Product Backlog)。
  • 在每次迭代开始时，团队从这个列表中选择一部分故事进行开发，形成迭代计划。
  • 用户故事有助于团队和利益相关者就需求达成共识。
  • Time Estimation (时间估算)：
  • 为功能特性进行时间估算是困难但必要的。
  • 团队通常会对用户故事进行估算，例如使用Story Points (故事点) 或其他相对估算方法，而不是精确的时间单位。故事点综合了工作的复杂度、工作量和不确定性。
  • 通过几个迭代后，团队可以计算出其Team Velocity (开发速率)，即每个迭代能完成多少故事点。
  • 开发速率可以用来预测未来迭代的工作量和项目完成时间。

The purpose of test-driven development (TDD)

  • 核心思想：在编写实际功能代码之前，先编写测试用例。
  • 目的：
  • 确保代码符合需求：通过先定义测试，开发者可以更清晰地理解需求，并编写出能够通过这些测试的代码。
  • 测试即文档：测试用例本身成为了系统功能的一种精确描述和文档。
  • 提高代码质量和可维护性：促使开发者编写模块化、可测试的代码。
  • 充满信心地进行更改：当与持续集成过程结合时，单元测试使团队能够充满信心地对软件进行更改，因为测试可以快速发现因更改引入的错误。
  • TDD 生命周期：测试失败 -> 编写代码使测试通过 -> 重构代码。

The purpose of version control software

  • 背景：大型软件开发涉及多人协作，容易出错，且错误可能在数周或数月后才被发现。
  • 目的：
  • 跟踪和管理代码变更历史：记录每一次对代码的修改。
  • 支持团队协作：允许多个开发者同时在同一个代码库上工作。
  • 解决冲突：提供机制来处理不同开发者对同一代码部分所做修改之间的冲突。
  • 回滚工作：能够将代码恢复到之前的某个稳定状态。
  • Git 是目前世界上使用最广泛的分布式版本控制系统，由 Linus Torvalds 于2005年开发。

The operation of a Git project

  • Repositories (仓库)：
  • Git 项目在一个 Git repository 中进行开发。
  • 可以使用 git init 在当前文件夹中初始化一个新仓库。
  • 可以使用 git clone 从其他地方克隆一个现有仓库，创建所有文件和历史记录的本地副本。
  • Commits (提交)：
  • 项目的历史记录被构造成一个图结构（非线性）。
  • 图中的每个节点代表对代码的一组更改，称为commit。
  • 每个提交都有一个唯一的哈希值作为其 commit ID。
  • 提交步骤：git add <filename> (将更改的文件添加到暂存区)，然后 git commit -m "message" (将暂存区的更改提交到分支)。
  • Commit Messages (提交信息) 非常重要，应不仅总结更改了什么，还要说明为什么更改。
  • Branches (分支)：
  • 一系列连续的提交构成一个branch。
  • HEAD 指向你当前所在的分支。
  • git checkout -b <branchName>：创建并切换到一个新分支。
  • git checkout <branchName>：切换到已存在的分支。
  • git merge <branchName>：将指定分支的更改合并到当前分支。
  • 通常项目有一个 main 或 master 分支，代表项目的“当前状态”。新功能在特性分支上开发，完成后合并回主分支。
  • Tags (标签)：
  • 用于标记历史中的特定点（提交），例如版本发布或重要里程碑。
  • git tag <tagname> <commitId>：为一个特定的提交打上标签。
  • Remote repositories (远程仓库)：
  • 与你交互的其他仓库副本称为remotes。
  • 克隆仓库时，默认会添加一个名为 origin 的远程仓库，指向你克隆的源。
  • git remote add <remoteName> <remoteURL>：添加一个新的远程仓库。
  • git push <remoteName> <branchName>：将本地分支的更改推送到远程仓库的指定分支。
  • git pull <remoteName>：从远程仓库拉取指定分支的更改并合并到本地当前分支。

Merge conflicts and why they occur

  • 发生原因：当在不同分支上开发的特性需要修改同一文件的相同代码行时，Git 在合并这两个分支时无法自动决定保留哪个版本的更改，从而产生合并冲突。
  • 解决过程：
  • Git 会在冲突的文件中标记出冲突的部分。
  • 开发者必须手动编辑这些文件，解决冲突，决定最终要保留的代码。
  • 解决冲突后，使用 git add <filename> 将修改后的文件标记为已解决冲突。
  • 所有冲突文件都解决并添加后，运行 git merge --continue (或 git commit 在较新版本 Git 中) 来完成合并。
  • 避免与注意：
  • 保持提交的粒度适当（例如，限定于单个特性或bug修复）并经常合并，有助于减少严重冲突的发生。
  • Git 只能检测到语法冲突（同一行代码被修改）。它无法检测到语义冲突（例如，一个分支改变了函数的工作方式，而另一个分支依赖于其旧的行为）。语义冲突需要通过测试来发现。

The purpose of GitHub

  • GitHub 是一个托管 Git 仓库的服务平台。
  • 目的：
  • 代码托管：为 Git 仓库提供在线存储。
  • 协作开发：团队成员可以通过 GitHub 作为项目的“主”仓库进行协作，推送和拉取代码。
  • 项目管理：提供一系列工具来支持敏捷项目管理，如问题跟踪和代码审查。
  • 代码共享与开源：GitHub 仓库可以是公开的，任何人都可以查看代码，使其成为开源项目的重要平台。
  • 许多其他类似服务也存在，如 Bitbucket。

The different way of interacting with a Git project via GitHub in an Agile way

GitHub 提供了多种功能，使得团队可以更高效地以敏捷方式进行协作：

  • 共同的远程仓库：所有团队成员通过从 GitHub 仓库 pull 和向其 push 代码来同步工作。
  • Issues (议题)：
  • 用于跟踪和讨论功能列表 (用户故事)、bug 报告、任务和改进建议。
  • 在开发新功能前，应创建一个 Issue 来规划和记录它，内容包括其目的和建议的实现方式。
  • 对于 bug 报告，Issue 应包含预期行为、实际行为、重现步骤以及可能的原因。
  • Issue 应包含足够细节，以便团队中任何人都能理解并处理。
  • Issue 也作为团队讨论的论坛。
  • Pull requests (PRs / 拉取请求)：
  • 一种更佳的工作流程是，将特性分支推送到 GitHub 仓库（不先在本地合并到 main），然后创建一个拉取请求。
  • 拉取请求允许其他团队成员在代码合并到主分支之前对其进行代码审查 (Code Review)，提出改进建议。
  • GitHub 会显示 PR 中的所有更改，其他人可以添加评论和建议。开发者可以根据反馈更新 PR（通过向其特性分支添加新的提交并推送）。
  • 当所有人都满意后，PR 可以被合并到主分支。
  • README.md 文件：
  • 按照惯例，GitHub 仓库会包含一个用 Markdown 编写的 README.md 文件，其中包含如何构建/运行项目的说明。
  • GitHub 会自动在仓库的登陆页面渲染这个文件。