Using your framework for real applications - things to consider

Posted on 21 January 2009 in Web development

There are lots of great frameworks out there ready to satisfy our needs when writing web applications. We can be quite flexible and use a different framework for each project type. And in fact one of the ways to expand our programming knowledge is to know the internals of the framework we are using. Sometimes after gaining this knowledge we find that there is a better way to get things done and we create our own libraries. And when our libraries gain critical mass, we often combine them to build a new framework.

The most important thing at this point: Don't reinvent the wheel. If a library works as expected, suits your needs and is actively developed, then there's no reason to insist on developing your own one.

Documentation

All great frameworks have great documentation. You may think you know everything about your framework and that is probably true. But it is always a better idea to have a detailed user guide instead of going to a specific class or file and read it. Some programmers will only need the automatic generated API documentation, but if you intend to introduce your framework to newcomers, then you must take some time to write an explicit human understandable user guide.

Work with stable releases

If you have features that are not fully implemented and tested, use a version of the framework without these features. Otherwise there's a risk of critical security holes and unexpected bugs that will cost you time and probably money. If you need a special library for the project and you are sure, that it suits this project only - you can implement it right away.

In case you need a specific library for a future project, then write and test it in the version controlled framework and then migrate the application. Keep in mind that once a library has been implemented into the project, it is very difficult to extract it.

Use version control

Using version control allows you to create backups instantly. You can also add comments for every major revision and you will clearly see the features contained in every revision. If you are using Git you can create branches - this will help you in profiling the framework for different projects and goals.

Define realistic deadlines

Your framework is never perfect: you can always find a bug or wish to improve the code base. But if you are working under pressure and the deadline is approaching, it is a better idea to just fix the bugs and continue working on the exsisting code base. Avoid rewriting: you can do so in the controlled version, after the project is completed. The main difference between using already developed framework and your own one is that you must take time to write most libraries before using them - keep that in mind, when defining project deadlines.

Look around

Look around and try not to use your framework for every project. For a specific project, it is sometimes better to use another framework, or even another language. If your way of getting things done is really powerful, efficient and different, release your framework as an open source project and build a community of passionate programmers. If you gain enough attention, your framework can be one of the next generation web frameworks, the next Ruby on Rails or Django.