不要陷入极限编程的陷阱

 

 

国内的程序员仍然有不少人是习惯于在编码的时候，一同去考虑诸如业务、需求、设计等不同性质的问题。而他们在解释这么做的原因时，有的是归诸于项目工期太紧，没有充足的时间去分开来考虑；有的则认为分出来这么多的中间工件，是一种胆怯的文牍主义保守做法，严重降低了开发的效率；还有的干脆就觉得软件开发就是编写程序代码，哪有那么多复杂的考虑。

软件开发中出现较多的中间工件，确实会带来负面的影响。一方面，其绝对的工作量肯定会比只编写代码要大；另一方面，在发生变更的时候，维持需求、设计、与代码之间的一致性将是一件痛苦的差事。而业界当前非常热门的极限编程等敏捷开发方法，似乎也给程序员们提供了一种批驳较重量级开发过程的有力武器。然而，情绪化地去争论两类不同性质开发方法之间的优劣，往往很容易让人陷入一种误区甚至是陷阱。

我们探讨过中间工件的划分，是为了隔离不同性质问题的关注面。而之所以要隔离关注面，是因为7±2原则所揭示的人类思维极限的存在。实际上，如果软件所要解决的业务问题足够简单，开发人员有能力同时将业务、需求、设计、与代码等想清楚，那么不划分中间工件也许是一种不错的选择。但是软件总是复杂的，而且并不仅仅只是程序员们自己的事情。需求必须要有用户的参与，而用户是看不懂代码的；规模较大的软件需要多个程序员来协作开发，这必须有架构师从整体上去把握各种部分的接口和协同，而架构师通过阅读细节的代码来思考其背后所蕴含的那些架构级的关系，显然也是不可思议的。

而从实践来看，对于较复杂的软件，程序员其实并不能在同一时刻将业务、需求、设计与代码结构等都考虑清楚。即使是高手也不可避免地会留下很多漏洞，只是这些漏洞可能在项目后期才暴露出来。这样就只能依靠反复地测试—发现问题—修改—再测试，即所谓的bug-fix-bug周期，来帮助程序员最终将所有问题搞清楚。也就是说，如果软件问题本身就复杂，人们是无论如何也绕不过那个槛的；因此借口工期压力而不做中间工件，其结果往往就是将大量时间浪费在修复bug的返工上。

至于中间工件划分所带来的负面开销，这其实是解决复杂问题时无法避免的代价。实际上，软件开发中会大量地存在着付出某种代价来换取某种利益的情形。我们能做的就是尽量去降低这种代价。业界目前主流的UML语言和MDA模型驱动架构方法，使得开发组能够尽可能少地编写文档，而且自动化地同步模型与代码，已经在很大程度上消解了上述的负面开销。

从另一角度看，面向对象的编程语言，与问题域的距离更为接近；特别是自说明的命名和代码，使得人们通过直接阅读代码来理解较为简单的业务或设计思路，开始变得较为容易。因此，极限编程自有其发展的生命力。不过，我们一定要注意，极限编程只适用于较小规模，并且业务相对简单的应用软件；或者是那种与业务无关的，类似IDE等的系统类软件。