敏捷过程在中国软件企业的实践——XP最佳实践第四部分

 

接上一篇。。。。。。

 

段誉：“这样看来XP的紧急设计在我们的项目团队也是有它的用武之地的。接下来我们谈谈代码集体所有权这个实践吧，XP中的代码集体所有权是指项目团队的所有成员都对整个项目的代码具有所有权，他们可以随时对任意的代码进行重构。该实践主要来源于XP简单的价值观，又与两个实践相关，分别是简单设计和结对编程。由于XP希望整个系统一直保持简单的结构，清晰的代码，因此代码集体所有权使得每一对程序员都能够不断对整个项目的代码进行重构；由于XP是采用结对编程并经常结对轮换的方式进行开发，只有代码集体所有权才能支撑这方面的实践。另外，值得一提的是，XP里面的代码审查是通过结对编程和代码集体所有权这两个实践来支撑的，只有结对编程并不断轮换才能在程序员之间彼此审查代码；只有代码集体所有权才能产生一对程序员看到其他程序员编写的代码并进行重构。”

 

乔峰：“关于代码集体所有权我有不同的看法，在XP中代码集体所有权是为了支持简单设计和结对编程的实践，但对我们公司的项目团队来说，只有简单设计是我们认可的，简单设计对代码集体所有权的依赖并不像结对编程那么强，并且仅仅这个实践不足以支撑我们采用代码的集体所有权。有趣的是，同样作为敏捷过程的代表FDD功能驱动开发，它与XP在这点上却是截然相反的，在《特征驱动开发方法——原理与实践》一书中作者明确指出代码集体所有权的主要问题是，在实践中它很容易会退化成无所有权，或者是所有权被团队中居主导地位的少数人拥有，导致要么没有人自始至终对系统中的所有工作负责，要么那些在团队中居主导地位的少数人力图做所有的工作，要避免这种情况结对编程是非常重要的，而恰恰我们没有结对编程。而个体类的所有权有很多的优点，主要包括以下三点：个人对所分配的代码块概念的完整性负责，当类加入新的方法时，类所有者将保证维护类的完整性，并进行恰当的修改；有专家解释一个特定的代码块是如何工作的，这对于复杂或是关键的业务类尤其重要；代码所有者能够比那些具有相同的能力但不熟悉代码块的开发人员更快的实现和增加类的功能。当然也有一些缺点，主要包括以下两点：第一个经典问题是当开发人员A需要对他的类进行一些改变但这些改变依赖于开发人员B拥有的类的改变，这时候如果开发人员B很忙，那么开发人员A就需要等很长的时间，这样将会降低项目的敏捷性；第二个问题是如果团队的某个成员离开，那么团队其他成员可能要花很多时间才能明白那个开发人员的类是如何工作的，这也会降低项目的敏捷性。但总体而言，我认为个体类的所有权更符合我们公司目前的实际情况。”

 

虚竹：“事实确实是这样，但我们也应该想办法来规避这些风险才是，XP通过结对编程及轮换，通过代码集体所有权解决了不得不等别人来修改代码的问题，并且减少了因团队某个成员的离开而带来的风险，因为在一个系统中至少有一个以上的人参与了某段代码的工作，那么我们应该通过什么方式来避免这两个由于代码个人所有制而带来的问题呢？”

 

段誉：“我觉得可以通过两个办法来解决这个问题，第一，XP中的另外一个实践编码规范，如果我们能让所有的开发人员都坚持统一的编码规范，那么一旦有团队的成员离开，另外的成员要理解那个成员的代码应该会更快；第二，代码审查，在XP中是通过结对编程来进行代码审查从而确保设计和代码的质量，我们没有结对编程，因此可以通过团队成员内部或者外部来进行代码的审查，无论如何，审查对于改进设计和编码质量的提高是很有用的，自20世纪70年代以来，审查就被推荐使用了。实际上，还有一点要说明，即审查的主要目标是检测缺陷。做得好时，审查还有两个非常有用的辅助作用：首先，知识的传递，审查是一种传播开发文化和经验的手段，缺乏经验的开发人员通过向知识丰富的开发人员学习有经验的代码，通过遍历代码并解释所使用的编码技术，可以快速学习编码技巧；其次，标准的一致，一旦开发人员得知，如果他们不能按照规定的设计和编码标准来工作，就不会通过代码审查，那么他们一定会更遵守标准，软件大师Steve McConnell在《代码大全》里面写到：‘尽管编码标准可以被写下来并予以发布，但如果没有某些形式的来自于审查的鼓励，这些标准可能不会被人所遵循，甚至连看都不看。’培养审查的氛围是很重要的，没有几个开发人员喜欢听到别人说，他的辛勤汗水换来的工作是错误的，或者应该做得更好，每个人都应该了解，审查首先是一个大的调试工具，其次也是一个与其他人相互学习的好机会。”

 

虚竹：“你说得很有道理，接下来还剩下几个实践？”

 

段誉：“接下来还有四个实践，有三个前面已经略略提到，这四个实践分别是编码标准、测试驱动开发、重构和持续集成。编码标准在任何的编程项目中都是非常重要的，在XP中更是如此，因为任何一对结对程序员都能够在任何时候改变代码中的任何部分，在这种情况下如果没有统一的编码标准是无法想象的，编码标准能够对保持代码结构更为清晰，更容易阅读和解释大有帮助。”

 

虚竹：“毫无疑问，要保证代码的清晰性和可维护性，编码标准是我们应该坚持的。”

 

段誉：“测试驱动开发来源于XP反馈的价值观，它共包括两层的意思，一层意思是指在编写功能代码之前先写测试代码，从而保证代码的测试覆盖率，减少代码缺陷，从这点上来讲它与先写功能代码后写测试之间的区别仅在测试驱动开发继承了XP一贯的特点，要求每次测试都采用很小的步伐，这样保证了更高的测试覆盖率；第二层意思才是测试驱动的最主要优点，在这里它可以称为测试驱动设计，因为它要求我们在写测试类的时候更多的考虑到接口的设计，站在客户端调用的角度去考虑问题，从而提高了代码的内聚性和降低了代码的耦合性，这点在我们团队以前开发院线系统的时候还是深有体会的。”

 

虚竹：“这里我要提出一个疑问，根据我对测试驱动开发的实践，它也有一些问题。比如，在我以前编写后台业务逻辑代码的时候，项目开发时间是非常紧张的，而且由于我的编码能力已经比较强了，因此我编写出来的代码就算完全不进行单元测试，在后来与编写页面层同事的代码进行集成测试的时候错误率还是比较低的，也就是说，如果我像测试驱动开发所要求的一样每前进一小步都要编写单元测试，那么我的开发时间会比完全不编写单元测试长很多，在项目开发时间如此紧张的情况下，我觉得测试驱动是有一些问题的。”

 

段誉：“尽管测试驱动在前期会带来开发时间的增加，但在后期它会带来更大的益处：第一、在XP中我们能够把单元测试代码作为系统需求的其中一个保存场所；第二、利用详细的测试驱动代码能够为系统构建一个安全网，通过回归测试来减少系统的bug数量，从而从长期来讲反而会减少系统的开发时间；第三，XP之所以会强调安全网的作用，因为XP更注重把bug消灭在更早的状态，通过全面的回归测试、自动化测试来把关，正如在《代码大全》中讲到的一样，越早发现bug解决成本就越低；第四、通过测试驱动来进行设计。”

 

虚竹：“对此我有不同的意见，首先，我们前面已经提到我们公司由于没有现场客户的存在，我们不可能像XP一样不进行预先详细的需求分析与设计，当然我们会采用较为敏捷的方法去做这些事情，在这种情况下我们保存系统需求的地方在需求分析文档里面已经存在，因此我们也不需要靠单元测试代码去保存系统需求了；其次，要真正做到能够利用详细的测试代码为系统构建一个安全网并经常进行回归测试，这需要单元测试的代码写得非常细，而且随着需求的变更还要不断维护这些测试代码，并且最主要的比如在我们公司采用Java技术的项目中，为了保证回归测试的时候测试数据的完整性，每个开发人员自己的测试数据还需要采用类似DBUnit之类的工具在XML文件去填写，所有的这些都是非常繁琐的，需要大量的时间去维护单元测试代码，甚至所花的时间不比业务代码少多少，因此这里面的代价我们不得不仔细去考虑；再次，我们公司拥有专业的测试团队来对系统进行测试，这在某种程度已经代替了回归测试和自动化测试的作用，当然，我们也应该承认测试团队的测试属于后期测试，当然bug的解决成本会更高一些；最后，测试驱动设计我承认是一个好的实践，但在我们的项目中还是以预先的设计为主，测试驱动设计只是起到一个辅助、补充的作用。从上面我们可以看出尽管测试驱动开发总体上来讲是一个比较好的实践，但对于非XP的开发团队，是否要以付出大量时间为代价去维护单元测试的代码，这是一个值得深思的问题。段誉，你再往下说吧。”

 

未完待续。。。