高效团队开发

第1章 什么是团队开发

1.团队开发

​ 如果软件的规模超过一定程度,仅由一个人把控产品的所有内 容就比较困难了。不难想象,这时候就需要由多人组成团队进行开发。

​ 即:由多人开发程序的体制称为团队开发

第2章 团队开发所面临的问题

1.重要事情太多,无法确定处理的优先顺序

2.没有能用于验证的环境,即生产环境与部署环境不一致

3.部署的项目代码版本名字容易混淆,没有用工具生产版本号

4.重新制作数据库比较困难

5.代码一整合就出问题

6.覆盖了其他组员修正的代码

7.无法自信地进行代码重构

8.不知道bug的修正日期,也不能追踪退化

9.没有灵活使用分支和标签

10.在测试环境、正式环境上无法运行,忘记安装本机上的库

11.发布太复杂,以至于要发布手册

第3章 版本管理

3.1 什么是版本管理系统

​ 版本管理系统是将什么时候、谁、对文件做了怎样的修改这样的信息以版本的形式保存并进行管理的系统。这里提到的文件当然包括代码,但不是说版本管理系统只能管理代码的版本。

3.2 为什么使用版本管理系统能带来便利

● 能够保留修改内容这一最基本的记录 ● 能够方便地查看版本之间的差异 ● 能够防止错误地覆盖别人修改的代码 ● 能够还原到任意时间点的状态 ● 能够生成多个派生(分支和标签),保留当时项目状态的截面 ● 能够保留修改内容这一最基本的记录

第4章 缺陷管理

4.1 缺陷管理系统

缺陷管理系统的优点:

1.具有任务管理所需的基本功能

●“必须要做什么”这样的任务定义 ●“谁来做”这样的职责分配 ●“什么时候完成”这样的期限管理 ●“现在正处于作业中还是已经完成了”这样的状态管理

2.直观性、检索性较强

3.能够对信息进行统一管理及共享

4.能够生成各类报表

5.能够和其他系统进行关联,具有可扩展性

4.2 主要的缺陷管理系统

4.2.1 OSS产品(Open Source Software)

Trac

​ TracC是基于 Python 的缺陷管理系统。它导入简单,印象中过去几乎所有的开源项目都使用 Trac,之后被后来的 Redmine 以及SaaS(Software as a Service)形式的 GitHub 和 PivotalTracker 等逐渐取代,最近已经很少看到了。但如果要说上手简单的话,Trac 至今依然是第一选择。

Redmine

​ Redmine是比 Trac 稍晚的基于 Ruby on Rails 框架的缺陷管理系 统。因此,使用 Ruby on Rails 的项目导入 Redmine 的门槛会比较低。

Bugzilla

​ Bugzilla是基于 Perl 的缺陷管理系统。原本是 Netscape 公司内部的系统,后来被作为 OSS 公开。现在由 Mozilla 基金会继续开发,可以说是 OSS 界最具“历史和传统”性质的缺陷管理系统。

Mantis

​ Mantis是基于 PHP 的缺陷管理系统。由日本人开发,过去在日本曾被广泛使用,但近年来几乎看不到了。新项目一般不会使用Mantis,但在参加历史较久的项目时,还是有机会看到 Mantis 的。

JIRA

​ JIRAA 是由 Atlassian有偿提供的基于 Java 的缺陷管理系统。虽说是商用的,但有 30 天的免费试用期。该产品可以以安装文件或 SaaS 的形式提供,功能丰富。如果项目预算允许的话,可以考虑使用 JIRA。

YouTRACK

​ YouTRACK是以 IntelliJ IDEA 等 IDE 出名的 JerBrains 所提供的基于 Java 的缺陷管理系统。这也是一款收费软件,但 10 个用户之内的可以免费使用。提供安装文件和 SaaS 两种形式。

Pivotal Tracke

​ Pivotal Tracker是 PivotalLab 提供的缺陷管理系统。特别适 合于敏捷开发的 Scrum 开发流程。只提供 SaaS 形式的产品。

Backlog

​ Backlog是由日本的 nulab提供的缺陷管理系统。支持SaaS 和安装文件两种形式。因为是日本公司的产品,所以对日语的支持方面完全没有问题,当然也支持多语言,包括中文 C。

GitHub

​ 作为缺陷管理系统,GitHub 同样具备不俗的功能。检索功能等可能稍微弱了些,但和代码管理的交互做得非常出色,还具备 Wiki 的功能。并且还有名为 GitHub Pages的用于建立项目网页的功能,以及类似于 Travis CI 的 CI 工具。可以毫不夸张地说,GitHub 能够提供 OSS 项目所需要的所有功能。

第5章 CI(持续集成)

5.1 什么是 CI(持续集成)

集成(integration)

​ 将各个成员的工作成果集中到一处进行集成,直到形成可以运行的 系统,各个成员的开发工作才有了意义,才能进行测试,最终才能以产 品的形式向顾客提供价值。 ​ 集成,具体来说就是像下面这样执行 build 和测试的流程。

● 将所有的代码集中到一处 ● 设置依赖程序库等的路径 ● 必要的情况下进行编译 ● 进行数据库构建和数据加载 ● 必要的情况下对中间件进行配置和启动 ● 实施单元测试、集成测试、用户验收测试等

持续地进行集成就是 CI

​ 将这些集成处理流程持续地执行,就是 CI(Continuous Integration,持续集成)。

CI的必要条件

● 版本管理系统 ● build 工具 ● 测试代码 ● CI 工具

第6章 部署的自动化(持续交付)

​ 所有部署相关的作业都应该实现自动化”。这里所说的部署是指将开发的代码以能够使用的状态放置到服务器上这一连串行为。

部署自动化方面的共识

1 要全部采用版本管理 2 所有的环境都要用同样的方式来构建 3 要实现发布工作的自动化,并事先进行验证 4 要反复多次进行测试

第7章 回归测试

7.1 什么是回归测试

​ 回归测试是以检查退化为目的的测试

​ 一般来说这类测试和使用系统的用户一样,利用浏览器进行输入或 页面迁移,并测试是否得到所期待的结果或页面。因此执行一个个测试 用例的时间往往变得很长,如果是长年运维的系统,到所有测试执行结 束为止耗费大量时间的情况并不罕见。

7.2 什么是 Selenium

​ Selenium是实现 Web 应用程序的功能测试以及集成测试自动化的 浏览器驱动测试工具群,具备以 Web 应用程序的测试自动化为特点的各 类功能。 ​ 和使用系统的用户相同,在浏览器上进行的鼠标操作、在表单中输 入文字或者打开页面时,Selenium 能够检查页面的内容是否正确显示、 检查表单的值以及验证页面内执行的 JavaScript 等。因此借助 Selenium 能够重复实施至今为止手动操作的测试。