极限编程潜在的中心前提就是两种思想比一种要好。两个程序员并排坐在一同，一个编程，另一个逐块逐行地挑刺。这样做的缘由很明显，如果在键盘上操作的人是司机的话，那么他旁边的人就是领航员。当中没有谁是上司——他们的地位是平等的，角色是相反相成的。极限编程让人震惊的地方就是实际起作用的技术。

由于有报答，极限编程曾经在前端开发圈里站稳了脚跟。把两个身价不菲的开发者安排在一台机器上，似乎看起来是很荒谬的，但是理想证明并非如此。在极限编程中，大部分的程序缺陷在产生之前就被扼杀了;在编写低速代码时，最优化就出现了;知识互相交流;并且团队关系也就产生了。

依我的经验，这种景象还没有渗透到数据库层的开发中。我留意到在有的团队中，一团体编写存储过程，第二团体编写数据传输系统(DTS)，第三个做体系机构，而第四团体为两头设备界面做评注。每团体都孤立地创作所需的对象，而且几乎不会对代码进行检查。也许设计师规定Sproc98765接受特定的参数，并前往某个结果;然后团队中的其他成员就与之绝对应。在任何一个严谨的开发组织中，检查代码和再因子分解是一个项目不可或缺的部分，但是由于某些奇怪的缘由，它们并没有延伸到数据库中。

我无法理解这点。也许我们共同蒙蔽了管理者，让他们认为我们对数据库曾经无所不知了。或者我们服务的定价太高，以致于会计人员都由于核算每个星期再因子分解和极限编程的花销而气喘如牛了。

举个例子来说，在一个包含了400个表格和1,600个存储过程的数据库中，我得到的每一个结果都是正确的几率是多大呢?即便有时候会出现那样的情况，那么下一次一个部门或客户需求知道某个表中的新加的列，我就必须重新访问不计其数的程序、用户自定义函数(UDF)和查看——而且这只说明了表格结构的变化。

如果可能的话，我鼓励您尝试用极限编程方法去处理当前面临的SQLServer中的问题。对于这种方法，可供选择的包括一个复杂存储过程的最新进展，对一个低速程序再次进行因子分解和使一个查看最优化。至少尝试一下，然后让我知道它是怎样为您所用的。