Home/ Questions/Q 206697
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T17:40:09+00:00

I’ve been working on an application for a little over two years and have

  • 0

I’ve been working on an application for a little over two years and have developed a lot of useful helpers, utilities, features, setup conventions, etc.

I want to start building a similar application and think I could reuse a lot of the functionality built into the existing application with the new application.

I’ve always heard is it best to extract a framework from an application but not heard much about best practices on going about it. It’s even better knowing changes to the framework could benefit all the similar applications I will be building (there could be a dozen).

Where do I start? Any best practices? Any pitfalls or areas to watch out for?

EDIT: I should clarify a bit, I’m not doing this for anyone but myself. I’m developing similar applications for different industries so the core is 90% the same, the differences are in the details.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Here’s what we at Starling Software have learned from doing this for QAM and QWeb.

    Our approach is to treat this as a refactoring job spread across all the projects using the framework or proto-framework. We separate the framework code within each project into something that’s built separately, so that, e.g., src/myapp contains the application-specific code, and src/qam contains the framework itself. Each project has its own copy of the application-specific code, and there’s also a separate project that contains just the latest version of the framework itself. When we identify something within a specific project that wants to be in the framework, we:

    1. refactor within the project to generalize the code (based on our understanding of both this application and all the others using the framework);
    2. refactor within the project to move the genealized code from the application-specific part to the framework part;
    3. apply this update to the project that contains the “master copy” of the framework;
    4. merge the changes from that master copy into other projects that are also using the framework; and then
    5. refactor within the other projects to use that part of the framework rather than their similar application-specific code.

    This requires a fair amount of discipline to move the changes around quickly. If you’ve just finished developing a new feature and are immediately bringing it into other projects, the integration is easy. Projects that don’t get updated for some time become much more difficult to update to use the latest version of the framework. If you don’t bring changes into the master copy quickly, you may end up with different (and worse yet, conflicting) changes in the framework copies within two projects, and the merge can become quite a pain. You definitely want to update any particular project to the latest version of the framework before you start changing the framework.

    Doing this needs a certain amount of practical support in terms of tools and so on. You’ll want a way to move changes back and forth between the various copies of the framework easily and quickly. We have a custom tool to do this (qu), but I would imagine that one could also use a revision control system, particularly a distributed one that works by moving patches around, to help with this.

    Having a comprehensive test suite for each application helps greatly; I’m not sure I’d want to attempt this without that.

    For sanity, it’s important to keep the changes small. Again, it’s all a matter of how hard it is to merge and move updates. If it’s always quick, and something you’ve been working on very recently, things stay easy. The large the changes are, and the longer it’s been since you worked on that bit of the framework, the harder things become.

    • 0