我已经在应用程序上工作了两年多,并开发了许多有用的帮助程序,实用程序,功能,设置约定等。
我想开始构建一个类似的应用程序,并认为我可以使用新的应用程序重用现有应用程序中内置的许多功能。
我一直听说最好从应用程序中提取一个框架,但没有听说过关于它的最佳实践。更好的是,了解框架的更改可能会使我将要构建的所有类似应用程序受益(可能有十几个)。
我从哪里开始?任何最佳做法?是否有任何陷阱或需要注意的方面?
编辑:我应该澄清一下,除了我自己,我不会为任何人这样做。我正在为不同行业开发类似的应用程序,因此核心是90%相同,不同之处在于细节。答案 0 :(得分:1)
请参阅Extracting Rails from Basecamp,了解David Heinemeier Hansson对Rails如何形成的看法,从它作为Basecamp中使用的框架的起源。鉴于Rails的普及,你可以从DHH如何解决这个问题中学到一两件事。 : - )
(好吧,也许不是那么多,为什么。但仍然很有趣。: - ))
答案 1 :(得分:1)
以下是我们Starling Software从QAM和QWeb这样做中学到的东西。
我们的方法是将此视为使用框架或原型框架分布在所有项目中的重构工作。我们将每个项目中的框架代码分成单独构建的内容,以便例如src / myapp包含特定于应用程序的代码,而src / qam包含框架本身。每个项目都有自己的特定于应用程序的代码副本,还有一个单独的项目,它只包含框架本身的最新版本。当我们在特定项目中识别想要在框架中的某些内容时,我们:
这需要相当多的纪律来快速推动变革。如果您刚刚完成了一项新功能的开发并立即将其引入其他项目,那么集成很容易。一段时间内未更新的项目变得更难以更新以使用最新版本的框架。如果您没有快速地将更改带入主副本,则最终可能会在两个项目中的框架副本中发生不同(更糟的是,相互冲突的)更改,并且合并可能会变得非常痛苦。在开始更改框架之前,您肯定希望将任何特定项目更新到最新版本的框架。
这样做需要在工具等方面提供一定的实际支持。您需要一种方法,可以轻松快速地在框架的各个副本之间来回移动更改。我们有一个自定义工具来执行此操作(qu
),但我想也可以使用修订控制系统,特别是通过移动补丁来实现的分布式控制系统,以帮助实现此目的。
为每个应用程序提供全面的测试套件有很大帮助;我不确定如果没有它我会想要这样做。
为了保持理智,保持变化很小很重要。再一次,合并和移动更新的难易程度。如果它总是很快,而且你最近一直在做的事情,事情就变得容易了。这些变化越大,自从你对框架的这一部分开始工作以来的时间越长,就会越难。
答案 2 :(得分:0)
将所有代码放在桌子旁边。从空白页开始,编写您希望使用所需框架编写的代码。然后使用现有的代码组件,编写可以让您使用所需代码的框架。
答案 3 :(得分:0)
我以前做过这个,虽然这是一个有趣而有益的经验我不得不说我不会再做了。这是我的理由......
1)人们希望你支持这个框架。这是我面临的第一个挑战。人们来找我提出改进,问题和错误修复。这真的很难,因为我已经转移到其他项目,没有时间来支持它们。因此,请确保您有明确的未来支持计划。如何维护应用程序?谁来维护它?维持它需要多长时间?最重要的是......谁来支付这笔费用?
2)开发人员不愿被告知要做什么或受限制。我为VB开发人员编写了简化数据访问层的框架。它创建了一组易于使用的例程,无论MS如何更改数据库访问例程,它都能正常工作。好吧,某些开发人员不喜欢被告知使用框架,所以他们会婊子和呻吟。坦率地说,我厌倦了听到它,这给同事带来了一些恶意。
因此,请确保您有一些厚厚的皮肤,并且可以推销为什么人们应该使用您的框架。