軟件測試開發技術數據庫設計中的敏捷方法

關鍵字：數據庫設計 敏捷方法 進化設計 0 引言

在過去幾年中，我們將敏捷方法應用于數據庫設計中。我們總結出一些技巧，使得當應用程序發展時，數據庫也能夠進化，這是敏捷方法的一個重要屬性。我們的方法是通過持續集成以及自動重構，通過數據庫管理人員（DBA）和應用開發人員的緊密合作。這些技巧在應用開發的各個時期都有效。

1敏捷方法學

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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