我一直在研究一個兩年多一點的應用程序，並開發了大量有用的幫助程序，實用程序，功能，安裝約定等。什麼是從應用程序中提取框架的最佳實踐？
我想開始構建一個類似的應用程序，並認爲我可以重新利用新應用程序內置於現有應用程序中的許多功能。
我一直聽說最好是從應用程序中提取一個框架，但沒有聽說過關於它的最佳實踐。更好地瞭解框架的變化可能會使我將要構建的所有類似應用程序受益（可能會有一打）。
我從哪裏開始？任何最佳實踐？任何陷阱或需要注意的地方？
編輯：我應該澄清一點，我沒有爲除我自己以外的任何人做這個。我正在爲不同的行業開發類似的應用程序，所以核心是90％相同，差異在於細節。
下面是我們在德裕軟件已經從做這個QAM和QWeb教訓。
我們的方法是將此視爲使用框架或原型框架跨所有項目的重構工作。我們將每個項目中的框架代碼分離成單獨構建的東西，例如，src/myapp包含特定於應用程序的代碼，src/qam包含框架本身。每個項目都有自己的應用程序專用代碼副本，還有一個單獨的項目，其中只包含框架本身的最新版本。當我們說要在構架一個特定項目中確定的東西，我們：該項目推廣代碼中
這需要相當數量的紀律來快速調整變化。如果您剛完成開發新功能並立即將其引入其他項目，則集成非常簡單。一段時間未更新的項目變得更難以使用最新版本的框架。如果您沒有迅速將更改帶入主副本，那麼最終可能會在兩個項目中的框架副本中產生不同的（並且更糟糕的是，相互衝突的）更改，並且合併可能會變得非常痛苦。在開始更改框架之前，您一定要將任何特定項目更新到最新版本的框架。
這樣做需要一定量的工具等實際支持。您需要一種方式輕鬆快速地在框架的各種副本之間來回移動更改。我們有一個自定義工具來執行此操作（qu），但是我想可以使用修訂控制系統，特別是通過移動補丁工作的分佈式控制系統來幫助完成此操作。
對每個應用程序有一個全面的測試套件有很大幫助;我不確定我會不想嘗試這樣做。
爲了理智，保持變化很小是很重要的。再次，這都是合併和移動更新的難度。如果它總是很快，而且你最近一直在做的事情，那麼事情很簡單。這些變化是巨大的，而且自從你在這個框架中工作以來就變得越久，變得越困難。
把你所有的代碼放在你的桌子旁邊。從空白頁面開始，編寫代碼希望您可以使用所需的框架編寫代碼。然後使用你現有的組件代碼，並編寫可以讓你使用你想要的代碼的框架。
我以前做過這個，雖然這是一個有趣和有益的體驗，我不得不說我不會再做。這是我的理由...
1）人們期望你支持該框架。這是我遇到的頭號挑戰。 Poeple來找我進行增強，問題和錯誤修復。那麼這真的很難，因爲我已經轉到其他項目，沒有時間來支持他們。
因此，請確保您有明確的未來支持計劃。應用程序將如何維護？誰來維護它？需要多少時間來維護它？最重要的是......誰來支付這種維護費用？ 2）開發人員討厭被告知要做什麼或受到限制。我爲VB開發人員編寫了簡化的數據訪問層框架。它創建了一套簡單易用的例程，無論MS如何更改DB訪問例程，該例程都可以工作。那麼某些開發人員不喜歡被告知使用框架，所以他們會婊子和呻吟。坦率地說，我厭倦了聽到它，並對同事造成了一些惡意。
所以確保你有一些厚厚的皮膚，並可以推出爲什麼人們應該使用你的框架。
請參閱Extracting Rails from Basecamp對於David Heinemeier Hansson關於Rails如何成爲Basecamp架構的原因。鑑於Rails的流行，你可能會從DHH如何拉開這一步學到一些東西。 :-)
（好吧，也許與其說是如何，作爲一個爲什麼。但還是娛樂性。:-)）
我應該澄清一點，我不會爲除我自己以外的任何人做這件事。我正在爲不同的行業開發類似的應用程序，所以核心是90％相同，差異在於細節。 – 2009-05-18 01:39:50