如何在SQL Server開發(fā)中融入極限編程技術(shù)

如何在SQL Server開發(fā)中融入極限編程技術(shù)，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

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

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

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

我無法理解這點。也許我們共同蒙蔽了管理者，讓他們認(rèn)為我們對數(shù)據(jù)庫已經(jīng)無所不知了?；蛘呶覀兎?wù)的定價太高，以至于會計人員都因為核算每個星期再因子分解和極限編程的花銷而氣喘如牛了。

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

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

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。