[TEAP早期試讀]資料庫和敏捷開發

圖靈社群按：
TEAP是什麼？TEAP是Turingbook Early Access Program的簡稱，即早期試讀，它公佈的是圖靈在途新書未經編輯的內容。一本書的翻譯週期約為3到6個月，如果在翻譯過程中，譯者就能與讀者進行溝通和交流，對整本書的翻譯品質是有幫助的。通過TEAP，讀者可以提前閱讀將來才能出版的內容，譯者也能收穫寶貴的反饋意見，改進翻譯，提高質量。

本書原名為Expert PLSQL Practices，中文暫定名為《Oracle PL/SQL實戰》，本篇選自第12章 漸進式資料建模

我的社群ID 、部落格

無論你是在建造飛機還是在構建軟體，變化總會發生。你別無選擇：你必須管理變化，要不你就會措手不及。

從二十年的系統開發中總結的經驗

每個專案都被寄予期望滿足快速的設計和實施計劃。儘管有些差異，但系統開發的一些基本的現實一直都是相同的。

■客戶在看到應用程式之前不知道他們想要的到底是什麼。只有當他們看到他們的資料有什麼可以做的時，他們才開始瞭解一個新的應用程式的真實的可能性。也是從這個時間點起，他們將會開始提出專案變更請求。如果你想構建一個優秀的產品，最後你想要做的事情是通過拒絕變更來關閉他們（使用者）的想法。

■客戶也會撒謊，就像對美劇“豪斯醫生”的詮釋。（譯者注：查了一下，似乎該劇中這個醫生十分強硬，導致病人不敢和他說真話）如果讓一個客戶來描述他們的處理流程，大部分時候他們會用該處理流程的文件中記錄的版本來回答。客戶不打算誤導我們，但ISO認證流程已經教他們用描述目前文件中記錄的步驟來回答有關處理流程的問題。然而，很多流程是有缺陷的，很可能還有一些沒有被包括在書面文件中的額外步驟。通過觀看客戶做什麼，你會看到真正的處理流程。如果你看到文件中沒有的步驟，那就表明你會找到最好的機會，以建立一個創新的產品。

■如果你構建了一個使使用者的工作更容易的系統，他們將使用它，並提出更多要求：更多的選擇，更多的功能，更高的效能。如果你構建的應用程式所建立的工作，沒有為使用者提供足夠的利益，那麼使用者會通過他們從未打算或想要完全避免的方式，變通使用該應用程式。對他們而言，這是一個完全合理的反應方式：我們作為應用程式的創造者，應用程式和程式碼對我們而言是非常重要的；但使用者有工作做，我們創作的應用程式可能只是使用者日常工作的一小部分。當使用者為完成他們的工作，而不得不變通使用一個應用程式時，它們將會產生更多的錯誤，而資料將隨著時間的推移變得不準確。作為資料庫和軟體開發者，你需要牢記你的客戶不會像你一樣對技術的細節著迷。使用者需要工作保持一致且不出所料的工具。

■如果你不能迅速提供工具或產品，別人會。這既適用於最終產品也適用於內建的開發環境。如果產品上市晚了，潛在客戶會找到另一種解決方案以及另一家供應商。如果資料庫不能為應用程式開發人員提供支援，他們會找到另一種解決方案，以完成他們的工作。即使那個解決方案不如利用資料庫的方案, 以後也很難刪除或優化它。通常情況下，這種解決方案對應用程式的功能，效能，或兩者都有長期的影響。

資料庫管理系統擅長儲存，搜尋和轉換資料。當DBMS和一個精心設計的資料模型相結合，它們執行這些任務的速度比任何應用程式的方法都要快。這裡是一個挑戰：一個資料庫系統必須要精心設計，才能執行，並在它被置於日益增長的對更多使用者或更多資料的需求時繼續執行。需要花費時間來設計一個支援這些要求的可擴充套件的資料庫系統。如果在設計過程中走了捷徑，那麼資料庫系統將不能滿足效能要求，這通常會導致一個重大的重新設計或硬體開支。這兩個選項都表示浪費和低效率：重新設計需要額外的時間和精力，即使硬體能夠使系統達到可接受的效能水平，想象一下如果有一個良好的設計和強大的硬體，系統的能力可以強大多少。

這一切聽起來很使人沮喪：如果客戶不知道他們想要什麼，不準確描述他們的流程，並濫用工具以減少他們的工作量，軟體開發人員和他們構建的應用程式似乎註定是要失敗的。因為你沒有一個應用程式和資料最終會變成什麼樣的完整畫面，所以你不能預先建立一個良好的設計，而即使你確實在專案開始時就有關於最終需求的完整和準確的資訊，當你和競爭對手的目標是相同的客戶群時，你也沒有時間進行資料建模和系統設計。然而，如果資料庫設計是有缺陷的，那麼你的使用者將對系統響應時間不滿，而你的專案也將被緩慢的響應時間和系統崩潰所困擾。

還有另一種選擇。你可以做一些革命性的東西：你可以承認，變化是不可避免的，準備迎接並管理變化。如果你期望變化，或做得更好，鼓勵變化，並從中吸取教訓，你就開啟了建立客戶正好需要的應用程式的可能性。如果你觀察終端使用者如何執行他們的工作，而不是讓他們來描述它，你會發現當前流程中的缺點，你也許能輕鬆去除這些缺點。這給你一個真正的創新機會，你建立了使用者需要的，但誰也沒有想到的工具。如果你讓客戶參與建立你的應用程式，在這個過程中更早把新功能交到他們手中，並要求客戶反饋，然後使用該反饋，以在開發過程的早期階段改善應用程式，其結果是一個協作的過程和更好的產品。如果你觀察客戶使用你構建的工具，你會發現更多的方法來提高你的產品。這被稱為迭代設計，我相信這種方式會導致更好的產品，更高的客戶滿意度，以及為軟體開發人員創造更令人滿意的工作環境。

資料庫和敏捷開發

迭代開發是不是一個新概念：有眾多的書籍和專家涉及軟體開發和迭代設計。然而，當涉及到資料庫時，幾乎沒有有關如何管理資料庫迭代設計的有用資訊。同時，越來越多的應用資料庫在缺乏充分設計的情況下被匆匆建立。無論是概念設計，邏輯設計或物理設計，一個共同點是，在太多的情況下缺少有目的的設計。這將導致極其常見的最終結果：資料庫和應用程式不能如預期那樣執行。應用程式可能通過了功能測試要求，但一旦它被置於預期的使用者負載下，效能可能要比可接受的差很遠。雖然有可能使一個設計不良的應用程式有更好的表現，來建立一個資料庫，在不斷增長的資料量和併發使用者越來越多下將繼續如預期那麼執行，你必須有一個精心設計的模式。你也許能夠通過增加更多的硬體資源來提高效能，但仔細想想。這些硬體資源的哪些部分只是用來補償一個不好的設計？以及如果不存在設計缺陷，你還可以從你的硬體投資中得到多少好處？當模式有缺陷時，應用程式返工所需的程式碼量會增加。這產生了一個很大的問題，因為隨著時間推移資料庫模式保持凍結，而應用程式的功能不斷擴大。由於變更請求繼續流入而額外的欄位被附加到已經有問題的模式設計中，效能問題變得越來越難以修復。

這類問題的最終結果是，架構師和開發人員已經得出結論，解決方案是將盡可能少的功能放到資料庫。也許，這是可以理解的：因為他們已經學會把資料庫變化視為痛苦的，他們試圖通過避免資料庫來避免痛苦。他們甚至在資料庫中做得最好的任務中避免使用資料庫，因為他們害怕他們可能有一天必須去改變它。編寫“資料庫無關”的程式的願望增加了問題，因為DBMS中某些最好的特性和功能被閒置了。不幸的且有些諷刺的結果是一個非常昂貴的DBMS被閒置，而很多支工人的隊伍正努力重新建立資料庫中已有的功能，而那些功能是他們根據其資料庫現有許可已購買了的。選擇購買一個強大的產品授權，但在設計應用程式時，卻彷彿你購買的是最小公分母（譯者注：指資料庫中最基本的功能），這是開發團隊可能犯的代價最高的錯誤之一。真實的情況是，無論DBMS是Oracle，MySQL，Postgres，或SQL Server，良好的開發人員都很難找到。為什麼要花費時間去重建另一家公司已構建好並已購買的功能？如果我們的目標是建立一個具有競爭力的產品，這個產品會滿足客戶的需要，同時最大限度地提高我們的投資回報，那麼就應該充分利用購買的DBMS平臺已有的每一個有用的功能。

到目前為止，我已經列舉了軟體開發專案眾多矛盾的目標：你需要快速構建，你需要在有足夠的知識之前繼續，你需要設計以支援長期的效能目標，以及這些效能目標可能是未知的。如果你還沒有一個產品，你怎麼能知道有一天，你會吸引多少使用者？如果你創造驚人的，創新的東西，你將在一個比你預期短很多的時間內有比你可能想到的更多的使用者。然後你的熱心使用者及時將使系統超負荷，從而導致最新的軟體產品在經歷一個非常公開的失敗的頭版故事之一。你需要把穩定性作為目標並通過一個迭代的設計過程鼓勵變化。你希望你的系統是透明和使用簡單的，使使用者能夠在每次連線時無需重新學習的步驟而做他們的工作。但你必須承認，你對使用者工作的理解可能不準確。考慮到所有潛在的可能使得一個專案無法應付這些挑戰的因素，軟體專案怎麼可能取得成功？你不可能讓時光倒流到開發變動不這麼快的時代。相反，你必須預想到設計將改變，裝備資料庫管理員，資料庫開發人員和應用程式開發人員，以管理到今天的變化並仍然關注這些變化作為一個整體對系統的長遠的影響。