軟件測試之數據庫設計中的敏捷方法[3]

關鍵字：數據庫設計 敏捷方法

　　3.7自動地更新所有開發人員的數據庫

　　人們變化和更新主數據庫，但是如何發現主數據庫已經發生變化?在傳統的持續集成有源代碼的環境中，開發人員在提交變化之前先更新主數據庫。這樣他們就可以在提交變化給共享主數據庫之前，解決他們自己的機器上的問題。

　　每次主數據庫發生改變時，我們都要更新開發人員的數據庫。當主數據庫發生變化時，我們自動化更新所有項目成員的數據庫。相同的重構代碼更新主數據庫上的同時，自動更新成員數據庫。也許有人認為在開發人員不知情的情況下，更新開發人員數據庫會產生很多問題，但在實踐中我們沒發現什么問題。當然，這只在人們聯網時管用。所以當開發人員離線時，必須盡快與主數據庫重新保持同步。

　　3.8清晰地分離所有的數據庫獲取代碼

　　為了理解數據庫重構的結果，了解應用程序如何使用數據庫也非常重要。如果SQL語句分布在代碼基礎周圍，則很難這樣去做。因此一個清晰的數據庫獲取層很重要，它用來顯示數據庫如何被使用，在哪里被使用。

　　清晰的數據庫層有很多好處。它減少了開發人員操縱數據庫時需要使用SQL知識的地方，這樣使對SQL語句不太熟悉的開發人員更易開發。對于DBA來說，給他提供了清晰的代碼，可以清楚地了解數據庫將如何使用。這也幫助準備索引、數據庫優化，優化SQL語句，使DBA更好地理解數據庫如何被使用。

　　4變化法則

　　如同任何實踐一樣，這些原則必須根據你特殊的環境變化。沒有一成不變的項目，我們必須要應對變化。

　　4.1保持多個數據庫在一個系統中

　　簡單項目也許只需要一個主數據庫。但是復雜項目需要有多個數據庫，即數據庫系。如果在投入生產之前數據庫必須分支，那么我們可以創建新的數據庫系。數據庫系類似于代碼的分支，需要不同測試數據集來進行測試。

　　當開發人員從主數據庫中獲取了一份拷貝，必須注冊他們在修改哪個數據庫系。當DBA更新主數據庫某個數據庫系時，同時更新了所有注冊這個數據庫系的開發人員的數據庫。

　　4.2不需要專職的DBA

　　所有這些聽上去好像需要大量的工作，但它并不需要大量的人力資源。在最大的項目中，我們有30個開發人員，項目組規模100人(包括質量評價、分析人員和管理人員)，我們大概有100多個不同系列的產品分布在各工作站上。但所有這些工作只需要一個專職DBA，只有兩個編程人員業余幫忙。

　　在小項目中甚至不需要專職DBA。當我們將這些技巧用于更小的項目—12人左右的小項目時，發現該項目不需要一個專職的DBA。與此相反，我們依靠兩個對數據庫感興趣的開發人員業余處理DBA任務。

　　這是自動化的功勞。如果對每項任務進行自動化處理，就可以用更少的人來完成更多的工作。

　　5輔助工具

　　數據庫進化需要大量的重復性工作，我們可以開發一些簡單工具來幫助我們解決大量的重復性工作。

　　自動化的最有價值的地方就是有一個通用數據庫任務簡單代碼集。自動化的任務包括：

　　*** 用戶資料與現在管理員的資料一致

原文轉自：http://www.anti-gravitydesign.com