我一直在研究一个两年多一点的应用程序，并开发了大量有用的帮助程序，实用程序，功能，安装约定等。什么是从应用程序中提取框架的最佳实践？
我想开始构建一个类似的应用程序，并认为我可以重新利用新应用程序内置于现有应用程序中的许多功能。
我一直听说最好是从应用程序中提取一个框架，但没有听说过关于它的最佳实践。更好地了解框架的变化可能会使我将要构建的所有类似应用程序受益（可能会有一打）。
我从哪里开始？任何最佳实践？任何陷阱或需要注意的地方？
编辑：我应该澄清一点，我没有为除我自己以外的任何人做这个。我正在为不同的行业开发类似的应用程序，所以核心是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