極限編程潛在的中心前提就是兩種思想比一種要好。兩個程序員并排坐在一起，一個編程，另一個逐塊逐行地挑刺。這樣做的原因很明顯，如果在鍵盤上操作的人是司機的話，那么他旁邊的人就是領航員。當中沒有誰是上司――他們的地位是平等的，角色是相輔相成的。極限編程讓人震驚的地方就是實際起作用的技術。

由于有回報，極限編程已經在前端開發(fā)圈里站穩(wěn)了腳跟。把兩個身價不菲的開發(fā)者安排在一臺機器上，似乎看起來是很荒謬的，但是事實證明并非如此。在極限編程中，大部分的程序缺陷在產生之前就被扼殺了；在編寫低速代碼時，最優(yōu)化就出現(xiàn)了；知識相互交流；并且團隊關系也就產生了。

依我的經驗，這種現(xiàn)象還沒有滲透到數據庫層的開發(fā)中。我注意到在有的團隊中，一個人編寫存儲過程，第二個人編寫數據傳輸系統(tǒng)（DTS），第三個做體系機構，而第四個人為中間設備界面做評注。每個人都孤立地創(chuàng)作所需的對象，而且?guī)缀醪粫Υa進行檢查。也許設計師規(guī)定Sproc98765接受特定的參數，并返回某個結果；然后團隊中的其他成員就與之相對應。在任何一個嚴謹的開發(fā)組織中，檢查代碼和再因子分解是一個項目不可或缺的部分，但是由于某些奇怪的原因，它們并沒有延伸到數據庫中。

我無法理解這點。也許我們共同蒙蔽了管理者，讓他們認為我們對數據庫已經無所不知了。或者我們服務的定價太高，以至于會計人員都因為核算每個星期再因子分解和極限編程的花銷而氣喘如牛了。

舉個例子來說，在一個包含了400個表格和1,600個存儲過程的數據庫中，我得到的每一個結果都是正確的幾率是多大呢？即使有時候會出現(xiàn)那樣的情況，那么下一次一個部門或客戶需要知道某個表中的新加的列，我就必須重新訪問不計其數的程序、用戶自定義函數（UDF）和查看――而且這只說明了表格結構的變化。

如果可能的話，我鼓勵您嘗試用極限編程方法去解決當前面臨的SQL Server中的問題。對于這種方法，可供選擇的包括一個復雜存儲過程的最新進展，對一個低速程序再次進行因子分解和使一個查看最優(yōu)化。至少嘗試一下，然后讓我知道它是怎么為您所用的。

關于極限編程的其他資源

• 為極限編程員提供極限Web資源
• 以極限編程加快步伐
• 極限編程：這12條慣例就天衣無縫了嗎？
• 某開發(fā)商轉向極限編程以承擔做出變化的成本
• 極限編程的成功故事：CodeFab為Noggin做開發(fā)
• 信息主管稱：極限編程的變革作用超過其對開發(fā)進程的貢獻
• 也許極限編程對您的店會起作用