數據庫設計中的敏捷方法

      1 敏捷方法學

      近年來，出現了一種新的軟件開發方法學—敏捷方法學。這給數據庫設計提出了一些新的、巨大的需求。這些需求的一個中心就是進化設計。在一個敏捷項目中，需要假定我們并不能事先確定系統的需求。因此在項目的初期有一個詳細設計階段的想法是不現實的。系統的設計必須隨著軟件的變化而進化。敏捷方法，尤其是極限編程（XP），通過一些實踐使這種進化設計成為可能。在數據庫設計采用敏捷方法，反復迭代。

      許多人會懷疑敏捷方法能否用于有大型數據庫組件的系統。但我們的確使用了許多敏捷和XP技巧，用于解決基于大型數據庫的項目中的進化與迭代問題。

本文將介紹一些在數據庫設計采用敏捷方法的實踐。當然，這并不是說我們已經完全解決了數據庫進化的問題，但是我們想提供一些行之有效的方法。

      2 積極應對變化

      敏捷編程的一個顯著特點就是它面對變化的態度。對軟件過程的一般解釋是盡早理解需求，停止需求的變動，將這些需求作為設計的基礎，停止設計的變動，然后開始構筑體系。這就是瀑布方法--基于計劃的生命周期。

      這種方法通過大量的前期工作來減少變化。一旦前期工作完成，需求變化會引起很大的問題。因此當需求變化時，這樣的方法就會有很大的問題，因此需求變動是這種過程的一個很大的問題。

      而敏捷編程卻以另外一種方式來面對變化。擁抱變化，甚至允許在項目開發的后期發生變化。盡管變化會被控制，但是這種態度會允許盡可能多的變化。變化部分來自于項目需求的不穩定，部分來自于要支持變化的商業環境來面對競爭壓力。

      為了做到這樣，必須采取不同的設計態度。設計不僅僅是一個階段—-在開始建筑之前就大部分完成的一個階段；設計是一個持續的過程，與編碼、測試甚至發布相關。這是計劃設計與進化設計的不同之處。敏捷方法的一個重要貢獻是提出了在可控制方式下的進化設計。因此不是由于設計沒有預先計劃好，產生了混亂。敏捷方法提供了控制進化設計和使其可行的技巧。

      敏捷方法的一個重要特點就是迭代式開發，即整個項目生命周期中運行多個完整的軟件生命周期循環。敏捷過程在每次迭代中都會度過一個完整的生命周期。迭代可以完成最終產品的需求子集中編碼、測試以及集成代碼。敏捷方法迭代時間較短，通常是一周到兩個月之間，而且我們更傾向于更短的迭代周期。

      當使用敏捷方法時，最大的問題就是數據庫如何進行進化設計。許多人認為數據庫設計是前期計劃的工作，而在后期改變數據庫設計計劃會引起應用軟件的崩潰；在配置以后改變數據庫設計計劃會導致數據遷移問題。

      在過去三年我們參加了一個大型的項目，其中用到了切實可行的進化設計的方法。該項目包括100人的項目組， 200多張表格，數據庫在一年半的最初開發中一直在進化，甚至在為多用戶分發的過程中也在進化。一開始我們一個月迭代一次，過了幾個月之后變為2周迭代一次。

      隨著我們將這些經驗推廣到項目中越來越多的部分，從越來越多的案例中獲得經驗。同時，我們也從其他敏捷項目中吸收了一些經驗。

      2.1限制條件
      在講述實踐方法之前，必須指出我們并沒有解決所有的數據庫進化設計問題，特別是：

      *** 我們是為單獨的應用設計一個應用數據庫，而不是試圖集成多個數據庫；

      *** 我們沒有做到24*7的數據庫更新。

      雖然很多人認為我們無法解決這個問題，但其實這些問題是可以解決的。當然這需要進一步的工作，光說是不能解決問題的。

      3 實踐
      我們有關于數據庫進化設計的方法依賴于一些重要的實踐。

      3.1數據庫管理人員與開發人員緊密合作
      敏捷方法的一個重要原則就是擁有不同技能和背景的人能夠緊密合作。正式的會議和文檔不能達到交流效果，因此他們需要一直一起工作，親密合作。所有的項目組成員都需要緊密合作：系統分析人員，項目經理，行業專家，開發人員以及數據庫管理人員（DBA）

      開發人員的每項工作可能都需要DBA的幫助。開發人員和DBA需要考慮是否需要對數據庫計劃做很大的改變。開發人員向DBA咨詢如何應對變化：開發人員知道需要什么新的功能，而DBA對應用中的數據有全局的觀念。

      為了達到親密合作的效果，DBA必須使自己易于接近。DBA需要留出幾分鐘的時間，讓開發人員來提問。必須確保DBA和開發人員坐在一起，這樣他們就很容易溝通。同時必須確保應用設計會議是公開的，這樣DBA可以隨時加入進來。在很多情況下我們發現人們在DBA和應用開發人員之間建立屏障，這些屏障必須去除，這樣進化數據庫設計才有可能。

      3.2每個項目組成員都有自己的數據庫實例
      進化設計認為人們通過嘗試來進行學習。在編程期間開發人員在如何實施某個特征，應用某個首選的方案之前做一些試驗。數據庫設計也是如此。因此，每個開發人員都有自己用來試驗的實例，而不必影響其它人，這一點很重要。這樣每個人都可以根據自己的需要進行試驗。

      許多DBA專家認為多個數據庫是一種麻煩，不易于實際應用，但我們發現操作一百個左右的數據庫是很容易的。當然其中很重要的是擁有便利的工具，使你像操作文件一樣操作數據庫。

      3.3開發人員數據庫經常集成到共享主數據庫
      盡管開發人員可以在他們自己的空間頻繁試驗，但是將不同的工作定期匯合也是很重要的。應用開發需要一個共享主數據庫，所有的工作都匯集于此。當開發人員開始工作時他們從主數據庫獲取拷貝到自己的工作空間，進行操作和修改，然后將變化反饋進入主數據庫。我們的規定是每個開發人員要每天提交匯合一次。

      假設開發人員上午10點開始一項開發任務，這項任務的一部分是改變數據庫計劃。如果這種改變很簡單，如增加一個字段，他就可以自己決定。通過數據字典的幫助，開發人員還必須確保他想增加的字段數據庫中沒有。但是如果他與DBA討論這種可能的變化，那么工作就要簡單的多。

      當他準備開始時，先從主數據庫中獲取一份拷貝，這樣就可以自由地改變數據庫計劃和代碼。因為他使用的是自己的數據庫實例，所以不會影響別人。在某個時候，如下午3點，他很清楚需要什么樣的數據庫變化，甚至此時他還沒有完全做完他的編碼工作。這時他找到DBA，告訴他想要的變化。這時DBA可以提出開發人員沒有考慮到的問題。當然大多數時候都很好，DBA同意這種變化（通過一個或多個數據庫重構）。DBA使變化馬上發生（除非他們是破壞性的變化），這樣開發人員可以繼續他的工作，在任何時候提交代碼，因為DBA已經將這些變化發送給主數據庫。

      可以將這個原則看作類似于持續集成，持續集成常用于源碼管理。實際上這就是將數據庫看作是另一種源代碼。因為配置管理系統象控制源代碼一樣控制主數據庫。只要我們構建成功，數據庫和源代碼一起被送入配置管理系統，這樣我們就有兩者完整和同步的版本歷史。

      對于源代碼來說，集成中的問題被源代碼控制系統處理。對于數據庫來說，要做的工作稍微多一些。所有數據庫的變化都需要妥善處理，如自動化數據庫重構。此外DBA需要審視任何數據庫變化，保證其符合整個數據庫的計劃。為了使這項工作做的比較平穩，在集成的過程中不應該出現大的變化--因此需要DBA與開發人員緊密合作。

      我們強調經常性的小集成，因為它比非經常性的大集成容易得多。集成的復雜度會隨著集成的規模呈幾何級度增加。因此做許多小的變化在實踐中更易于實現，當然這看上去與直覺相抵觸。

      3.4數據庫包含計劃和測試數據
      當提到數據庫的時候，我們并不僅僅指數據庫計劃，而且還包括相當規模的數據。這些數據包括應用所需的標準數據，如全國所有的省份名，以及一些樣本客戶的樣本數據。

      數據的作用：

      1、 易于測試

      使用大量的自動化測試可以幫助穩定應用的發展。這樣的測試在敏捷方法里是常用的方法。為了使這些測試有效進行，很理智的方法是在一個有樣本測試數據的基礎上工作，這樣所有的測試可以在程序正式進行之前完成。

      2、測試數據庫的遷移

      除了測試代碼之外，樣本測試數據允許我們測試數據庫的遷移，當改變了數據庫的計劃后，我們還必須保證所有的計劃變更也能夠處理樣本數據。

      在大多數項目中這些樣本數據是虛構的。然而在某些項目中人們使用實際數據作為例子。在這些情況下，數據從先前由自動化數據遷移代碼的系統中提取出來。很明顯不能馬上遷移所有的數據，因為在早期迭代中數據庫只有小部分建立起來。但是我們希望當應用和數據庫發展時，改變遷移代碼。這樣不僅能夠盡早解決遷移問題，也使行業專家易于處理這個正在開發的系統。因為有他們熟悉的數據，所以他們會指出可能給數據庫和應用設計帶來問題的地方。因此我們建議在項目的早期迭代中引入實際數據。

      3.5所有的變化應該數據庫重構
      重構技術就是應用所有可控技術來改變現有的代碼基礎。與此類似我們定義了數據庫重構也給數據庫的改變提供了類似的控制。

      數據庫重構的不同之處在于它必須將三種不同的變化同時完成：

文章來源于領測軟件測試網 http://www.kjueaiud.com/