After using Codeigniter, CakePHP and Zend Framework for a while I decided to build my own framework.

I wanted to include some features that I couldn’t find the way I like them in none of the projects I tested.

These are some lessons I learned the hard way. I hope you’d find some useful tips for your software projects.

1. Framework planning

Before writing any actual code, define your goals. Find out what is missing or what you are not happy with in your favorite frameworks and try to achieve it in your project. I found that if you can’t define each goal within a few words, that will affect your framework direction and your motivation, and you could end up with something bloated and messy. Also, keep an eye on your class dependencies and hierarchy. For me, the best way to do that is to draw a mind map of the project using tools like Freemind or Xmind.

2.Third party libraries

You will probably find that for general tasks like caching, image manipulation, PDF generation, templates etc., a 3rd party library is a better option for your framework. Most of these libraries have a well established and active community that can help you. This gives you the flexibility to adapt your framework to different types of projects easily. It is always better to create something with a small and independent core and plug in specific classes and libraries when needed, instead of rewriting all general purpose plugins again and again. One of the most important things when using a 3rd party library is to watch closely for incompatibility changes. In orded to avoid them, try to keep your “framework-library” interaction as abstract as you can.

3. Syntax planning

At first you may think that the purpose of your application is more important than its syntax. But in the future you will probably work with your framework every day and if the syntax bothers you at this point, you will need to rewrite some things. Combining the goal with the syntax type we want to achieve in the beginning saves a lot of time afterwards. So write the code the way you like it and think about all the possible ways your preferred language can offer in order to achieve your goal. For example:

$db->get('mytable')
->find_by(array('id'=> '1'))
->result('row');
return $this->db->execute($query);
?>

4. Debugging

If you plan to release your framework to the public or you just want to use it with your colleagues, first test it in different environments and operating systems. For example: some of the functions you are using could be only available in the latest version of PHP (or any language your are using). Or maybe, different operating systems could treat your files or I/O operations differently etc. The easiest way to test your framework is to use a virtual machine, because it allows you to debug and test the problematic areas instantly.

5. Benchmarking

It is very important to test your framework performance every time you make some changes in it. I found two good ways to test my framework performance. Here they are:

Apache – ab: it allows you to put your application on stress and see how many requests per second it can achieve. Download several other frameworks and compare their performance with the performance of yours. The basic “Hello World” example is not always the best option; include some database interaction and file manipulation tests.

Webgrind: Using a profiling tool for testing the application speed is something I personally think is underestimated. To speed up your application, you need to know where your program is spending most of the execution time. You can also easily find out when you are trying to do something not native to the language. For example, if you try to use OOP in PHP, the language uses alternative ways to do it, sacrificing execution time in the process.

6. Conclusion

Writing a framework is time consuming at the beginning. But you will eventually find that using your own software gives you more control, allowing you to achieve some things you considered hard or even unthinkable.