您好,登錄后才能下訂單哦!
如何在SQL Server開發中融入極限編程技術,很多新手對此不是很清楚,為了幫助大家解決這個難題,下面小編將為大家詳細講解,有這方面需求的人可以來學習下,希望你能有所收獲。
極限潛在的中心前提就是兩種思想比一種要好。兩個程序員并排坐在一起,一個編程,另一個逐塊逐行地挑刺。這樣做的原因很明顯,如果在鍵盤上操作的人是司機的話,那么他旁邊的人就是領航員。當中沒有誰是上司——他們的地位是平等的,角色是相輔相成的。極限編程讓人震驚的地方就是實際起作用的技術。
由于有回報,極限編程已經在前端開發圈里站穩了腳跟。把兩個身價不菲的開發者安排在一臺機器上,似乎看起來是很荒謬的,但是事實證明并非如此。在極限編程中,大部分的程序缺陷在產生之前就被扼殺了;在編寫低速代碼時,最優化就出現了;知識相互交流;并且團隊關系也就產生了。
依我的經驗,這種現象還沒有滲透到層的開發中。我注意到在有的團隊中,一個人編寫存儲過程,第二個人編寫數據傳輸系統(DTS),第三個做體系機構,而第四個人為中間設備界面做評注。每個人都孤立地創作所需的對象,而且幾乎不會對代碼進行檢查。也許設計師規定Sproc98765接受特定的參數,并返回某個結果;然后團隊中的其他成員就與之相對應。在任何一個嚴謹的開發組織中,檢查代碼和再因子分解是一個項目不可或缺的部分,但是由于某些奇怪的原因,它們并沒有延伸到數據庫中。
我無法理解這點。也許我們共同蒙蔽了管理者,讓他們認為我們對數據庫已經無所不知了。或者我們服務的定價太高,以至于會計人員都因為核算每個星期再因子分解和極限編程的花銷而氣喘如牛了。
舉個例子來說,在一個包含了400個表格和1,600個存儲過程的數據庫中,我得到的每一個結果都是正確的幾率是多大呢?即使有時候會出現那樣的情況,那么下一次一個部門或客戶需要知道某個表中的新加的列,我就必須重新訪問不計其數的程序、用戶自定義函數(UDF)和查看——而且這只說明了表格結構的變化。
如果可能的話,我鼓勵您嘗試用極限編程方法去解決當前面臨的SQLServer中的問題。對于這種方法,可供選擇的包括一個復雜存儲過程的最新進展,對一個低速程序再次進行因子分解和使一個查看最優化。至少嘗試一下,然后讓我知道它是怎么為您所用的。
看完上述內容是否對您有幫助呢?如果還想對相關知識有進一步的了解或閱讀更多相關文章,請關注億速云行業資訊頻道,感謝您對億速云的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。