在SQL Server开发中融入极限编程技术

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

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

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

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

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

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