从应用程序中提取框架的最佳实践是什么?

这是我们在Starling软件公司从这方面学到的 QAM 还有QWeb。

我们的方法是将其视为一项重构工作,该工作分布在使用框架或原型框架的所有项目中。我们将每个项目中的框架代码分离成单独构建的代码,这样,例如,src/myapp包含特定于应用程序的代码,而src/qam包含框架本身。每个项目都有自己的特定于应用程序的代码副本,还有一个单独的项目,其中只包含框架本身的最新版本。当我们在一个特定的项目中确定一些想要在框架中的东西时,我们:

1. 在项目中重构以概括代码(基于我们对这个应用程序以及使用框架的所有其他应用程序的理解);
2. 在项目中重构,将通用代码从特定于应用程序的部分移动到框架部分;
3. 将此更新应用于包含框架“主副本”的项目;
4. 将该主副本中的更改合并到其他同时使用该框架的项目中;然后
5. 在其他项目中重构以使用框架的这一部分,而不是它们类似的特定于应用程序的代码。

这需要相当多的纪律来快速地改变。如果您刚刚完成了一个新特性的开发,并立即将其引入到其他项目中,那么集成就很容易了。一段时间内没有更新的项目在使用最新版本的框架时变得更加难以更新。如果您不快速地将更改引入主副本,可能会在两个项目中的框架副本中产生不同的(更糟的是,冲突)更改,合并可能会变得非常痛苦。在开始更改框架之前,您肯定希望将任何特定项目更新为框架的最新版本。

这样做需要一定数量的工具等方面的实际支持。您需要一种在框架的不同副本之间轻松快速地来回移动更改的方法。我们有一个定制的工具来做这个( qu 但是我可以想象,我们也可以使用一个修订控制系统,特别是一个通过移动补丁来工作的分布式系统来帮助实现这一点。

为每个应用程序提供一个全面的测试套件会有很大帮助;我不确定是否要尝试不使用它。

为了保持清醒,保持微小的变化是很重要的。同样,所有的问题都在于合并和移动更新有多困难。如果它总是很快的,而且你最近一直在做一些事情,事情就很容易。变化是很大的,而且你在这个框架上工作的时间越长,事情就越困难。

见 Extracting Rails from Basecamp 对于DavidHeinemeier-Hansson来说,从它作为basecamp中使用的框架的起源来看,它是如何形成Rails的。考虑到Rails的普及程度,您可以从DHH如何实现这一点中学到一两件事。:-)

(好吧,也许不是怎么说,而是为什么说。但仍然很有趣。-)

把你所有的代码放在桌子旁边的一堆。从空白页开始,编写代码 希望 您可以使用所需的框架进行编写。然后将现有的代码用于组件,并编写框架,以便使用所需的代码。

我以前做过这个,虽然这是一次有趣而有益的经历,但我不得不说我不会再做了。这是我的理由…

1)人们希望您支持该框架。这是我面对的第一个挑战。Poeple来找我是为了帮助我,解决问题和错误。嗯,这真的很难,因为我搬到了其他项目,没有时间支持它们。

因此,确保你有一个清晰的未来支持计划。 如何维护应用程序?谁来维护它?维护它需要多少时间?最重要的是…谁来付维修费?

2)开发人员不喜欢被告知该做什么或受到限制。我为VB开发人员编写的简化数据访问层框架。它创建了一组很好的易于使用的例程,无论MS如何更改DB访问例程,这些例程都可以工作。好吧,有些开发人员不喜欢被告知使用框架,所以他们会抱怨和抱怨。坦率地说,我听腻了,这对同事造成了一些不好的意愿。

所以要确保你有一些厚皮,并且能够推销人们为什么要使用你的框架。