一種可升級的方法來設計一個Web應用系統

Question

許多人在他們的頭上有可能吸引數以百萬計的在線創業公司，但大多數時候你只有最少的預算（時間和資源）開始，所以你想擁有它在一年內交付。啓動後不久，您必須執行一個或一系列升級，可能包括：對新基礎進行代碼重構，在軟件體系結構中添加層次結構或重新構建數據庫。升級/重構的這個循環繼續如下：

• 在您使用的最新版本的語言/框架中可用的新功能。
• 可能有可能改進產品的新組件/框架/插件。
• 要求已經改變了方向，現有的產品並沒有設計來應對新的需求。

通過以上的前提下，我想借此討論嚴肅和確定爲Web應用程序可升級的解決方案的精髓。在討論中，您可以討論任何開發階段（初始，提前升級，增量upgardes），並涵蓋以下其中一項或多項：

• Web應用程序的語言選擇。
• 決定是否使用框架？ （考慮開銷）
• DBMS的選擇及其設計
• 硬件和設置的選擇？
• 戰略中的要求不斷變化（，它可以是Web應用程序的自然）
• 戰略/決策走向完全重新設計

Answer 1

我們公司的網絡解決方案在其第四代主要世代，在過去的8年中有了相當大的發展。最近一代推出了各種各樣的結構來幫助完成這項任務，因爲根據新的客戶需求更新上一代產品變得非常笨拙。因此，我在2009年花了不少時間思考這個問題。

您可以做的最有價值的事情是採用敏捷方法來構建軟件。特別是，您應該維護一個新的構建可以（並且）每天創建的環境。雖然日常構建只是敏捷的一個方面，但這是解決您的問題時最重要的做法。儘管這與升級本身並不是一回事，但它本身也引入了一個有助於減少代碼庫變得笨拙（或將成爲Architect Astronaut）的機會。

只要框架和語言去，有兩個主要要求：該框架是長壽命和穩定的，並且環境支持Separation of Concerns。在這方面，ASP.NET對我來說效果很好：它已經以合理的方式發展，並且沒有使舊代碼無效的不連續性。我使用單獨的業務邏輯層來管理SoC，但ASP.NET現在也支持MVC開發。相比之下，在幾個月的工作後，我開始討厭PHP，因爲它似乎鼓勵混亂的做法，這會危及未來的升級。

關於DBMS選擇，任何現代的RDMS（SQL Server，MySQL，Oracle）都可以很好地爲您服務。以下是關鍵：雖然將需要維護用於管理升級的DDL腳本。這只是生活中的一個事實。那麼，你如何使這個過程容易處理？來自任何第三方開發人員的最有價值的工具是我的Red Gate的SQL Compare的副本。這個過程曾經是一個完整的噩夢，並且在我發現這個工具之前，對我的代碼進化能力產生了巨大的阻礙。因此，通用建議是使用存在工具的數據庫來比較數據庫結構。 SQL Server在這方面非常幸運。

硬件幾乎是一個不在乎。只要您的開發流程包含合理的發佈構建流程，您就可以隨時使用新硬件。

需求不斷變化的策略。再次看到敏捷。我鼓勵你們不要再把它們當作「需求」 - 以傳統意義上的充滿規範的大型文檔。敏捷以重要的方式改變。除了在爲外部付費客戶提供合同時，我不保留需求文檔，以便我可以確保適當的結算並防止功能蠕變。在這一點上，我們的內部流程非常迅速和流暢，以至於在記錄新的市場營銷版本時，我們的功能請求/錯誤管理軟件（如果您想知道的話，FogBugz）的報告將作爲我們的文檔。

整體重新設計策略/決策是：不。如果你對流程採取合理程度的思考，你會使用，選擇主流工具，並強制實施一個關注點分離，那麼任何一個完全放棄HTTP和RDBMSs都不應該導致重新設計。

如果你有足夠的敏捷是什麼可以變化，你不可能永遠在一個位置，一切必須變化。

Answer 2

爲了讓球滾動，我還以爲語言/框架支持依賴注入的概念（或者近期似乎被稱爲控制反轉的概念）將在列表中位居前列。

Answer 3

你會發現RDBMS技術不容易擴展。所有的供應商都會告訴你，但是當你嘗試多個服務器時，負載均衡會出現固有的限制。其他任何事情都可以通過「更大的鐵」來加強，並且可能是更高效的代碼，但數據庫不能輕鬆拆分和分發。

Web應用程序將有望推動數據庫技術的創新，並幫助我們擺脫古老的關係模型思維集。這是遲早。

我建議從一開始就對這個薄弱環節給予很多關注。