2.3　案例分析（第 1 天）中的问题点

看了死亡行军项目中的 1 天，感觉怎么样？“项目一直都是这样的，已经习惯了”是不是也有人这么想呢？

反思第 1 天中发生的事情，让我们一起来确认下到底哪里有问题， 哪里做得不够好。

2.3.1　问题 1 ：重要的邮件太多，无法确定处理的优先顺序

这个项目中没有对课题进行管理的机制（缺陷管理系统），所以只能通过邮件来发送有关 bug 或故障的报告。加上邮件的主题中写有【重要】【加急】【需要处理】这样的标题头，所有的邮件都变得很重要，不知道应该从何处开始着手处理。这样的邮件满天飞的开发现场你有没有待过呢？“遇到过遇到过”似乎还能听到这样的回答。

不使用缺陷管理系统，而通过邮件进行交流会有哪些问题？下面就 来列举一些。

● …… 邮件的数量太多，导致重要的邮件被埋没

大家在开发现场 1 天之中所收发的邮件数量大概有多少呢？当然数量会根据公司的规模和职位有所不同。以笔者为例，笔者之前所在的公司中，与自己所参与的项目相关的邮件以及其他邮件加起来，1 天之中大约要收到 300 ～ 400 封邮件。该公司的规模未满 100 人，参与项目开发的人员在 10 人左右。笔者当时还兼任部门主管，所以会有人事相关的邮件以及其他的一些被抄送的邮件，这也是邮件比较多的原因之一。

也就是说，参加项目的人员不可能都专门进行这一个项目，其中很多都还有其他的日常业务，或者兼任着其他项目的工作。因此必然会产生大量的邮件，造成重要的邮件被埋没，容易被漏看。

为了让自己的邮件不被漏掉，很多人都会在邮件的主题前加上之前列举的那些标题头。但是因为没有统一的规则，究竟哪些是重要的无从知晓。结果还是被埋没在了成堆的邮件中，添加的标题头也完全失去了意义。

●…… 无法进行状态管理

因为邮件并非是用来管理课题或任务的软件，所以不能对其状态进行管理。哪个课题已经结束了，哪个课题还在进行中，或者是验证不通过被退回来了，这些都无法简单地获知。如果不耐心地一封一封地阅读同一主题的往来邮件，就不知道究竟是怎样的问题。有时就算读到了最后，因为来来回回的交互过于错综复杂，究竟结局怎样也还是不清楚。这也是常有的事。

●…… 直观性、检索性较弱

这一问题同上一个问题是相关的，那就是用邮件进行管理在直观性和检索性方面也比较弱势。邮件中包含了很多和项目没有直接关系的内容，想看只包括课题的列表，这样的要求估计无法实现。检索也是这样。也可以使用像 Gmail 这样的邮件应用程序，但像这样用全文检索来查找课题可以说实在是效率太低了。

●…… 用邮件来管理项目的课题

总结一下上述内容就是：邮件的可视性不佳，难以进行优先度或重要度的判断，并且无法进行状态管理，不支持显示课题列表、检索等，所以作为管理项目状况的工具来说，功能上是不足的。

项目混乱是由于某些问题造成的，其中一个比较严重的问题就是这里列举的没有共享信息及有效管理课题的机制。

上述问题可以考虑通过导入缺陷管理系统来解决。本书的第 4 章将讲解在使用了缺陷管理系统的项目中任务管理和 bug 管理的方法。

2.3.2　问题 2 ：没有能用于验证的环境

没有能用于验证的环境可以说是一个大问题。在收到项目正式环境中发生的故障报告后，下载代码并搭建开发环境的做法每次都要花费较长时间。

只要不影响新功能开发的任务不就没事了？但现实往往没这么简单。除了发布后的正式环境之外，一般还有为下一次发布做准备的，还在验证中的 staging 环境 7 ，甚至还有为下下次发布准备的环境。

7 这里的 staging 环境是指介于开发环境和正式环境之间的测试环境，即正式环境发布前用于验证的环境。本书中将 staging 环境用于再现和验证在正式环境中发生的故障。根据环境的体系不同，也有和正式环境保持完全一致，仅在发布前用于动作确认的 staging 环境。在这样的情况下，除了 staging 环境之外，还会另行准备测试环境。环境搭建包括运维在内是一笔不小的开销，所以在体系以及项目预算允许的范围内，最合理地构建环境是很重要的。

新功能开发过程中有时不得不调查正式环境中发生的一些故障。如果有一直和正式环境保持一致的 staging 环境那就最好了，但因为环境的搭建实在是件非常麻烦的事情。要怎样做才能提高效率呢？

有方法能够搭建持续、自动地向验证环境、staging 环境以及正式环境进行发布，并一直保持正常运行的环境，本书的第 6 章中将进行这方面的讲解。

2.3.3　问题 3 ：用别名目录管理分支

这个项目虽然使用了版本管理系统，但不能说对其进行了有效的利用。以前连版本管理系统都不使用的开发现场随处可见，现在使用版本管理系统的开发现场比较多了。但是如同这个项目一样，版本管理系统没有得到充分利用的情况却意外地多。

使用版本管理系统是为了管理什么时候、谁、做了怎样的修改（提交记录的管理），以及能恢复到过去某个时间点的状态（分支、标签的管理）。这个项目中没有很好地使用版本管理系统的重要功能——分支和标签，所以无法从新功能开发的版本顺利地切换到有故障报告的已经发布的版本。只能临时将本地机器上的目录重命名。也就是说，本来应该交由版本管理系统负责的分支管理，现在由人在本地机器上手动地进行了。

读过前文的读者想必都知道了，用给目录重命名的方法修改完 bug 后回到新功能的开发，之后再一次回到 bug 修改，在这样反复地进行重命名的过程中，很容易出现问题。

那么到底该如何使用版本管理系统呢？版本管理系统的分支、标签这样的功能如何使用才是有效果的呢？

这个问题还关系到今后程序以怎样的周期、怎样的方式进行发布，本书将在第 3 章进行这方面的讲解。

2.3.4　问题 4 ：重新制作数据库比较困难

在构建 staging 环境或正式环境时比较容易出问题的是数据库的处理。虽然没有对数据库的修改进行管理的项目比较常见，但这个项目还是使用版本管理系统对 SQL 文件进行了管理的。

这样就会经常出问题。比如不知道在什么环境中该使用哪些 SQL，从而导致没有察觉到遗漏了某些 SQL。还有在多个人修改数据库的情况下，不知道该如何管理才能避免修改冲突。

那么这个项目到底会怎么样呢？

首先，版本管理系统上，有如下的 SQL 被提交。

对应上述 SQL，本地开发环境和正式环境的模式如图 2.3 所示。

图 2.3　本地开发环境和正式环境的模式

ikeike443 的本地环境中遗漏了 Rev（Revision）2 的 add_column.sql，只执行了 create_user.sql 和 user_add_address.sql。但因为没有注意到这点并继续执行了之后的 tel_add.sql，所以就和正式环境产生了差异。

上述例子中是用眼睛看出数据库模式上的差异后，手工制作了相当于 add_column.sql 的文件并执行的。但结果还是出现了原因不明的运行时错误。于是只好放弃，转而从正式环境复制所有的数据重新构建环境。

这个谜一般的运行时错误的原因是什么呢？

这是因为本地开发环境和正式环境中 ALTER 语句的执行顺序不同，造成了列的定义顺序和最新代码不匹配（图 2.4）。根据代码的写法以及对象关系映射（O/R mapping）的实现的不同，有时会出问题，有时也可能没有问题。但关键问题在于因为没有制定构建数据库的方法，所以

图 2.4　执行的顺序不同

无法构建出能够保证正常运行的环境。

要怎么做才能解决这样的问题呢？

第 3 章中将讲解用版本管理系统管理 SQL 的方法以及处理数据库变更管理的工具。