PHP developers - wake up!

The beginning

Let's say that you have to start a new project and let's assume that you have a clear idea of what you have to build. My experience shows me that one of the biggest problems in the software development is the definition of the problems that should be solved. If you do this, then you are lucky and it is time to choose the tool/s, which you are going to use. There are several possible directions: A) pick up some of the frameworks, which you know and start developing with it B) pick up some framework that you don't know in details, but read that it is better than yours C) start building a custom solution by writing custom modules Most of the people choose A), because they are already familiar with the framework and of course are able to deliver results for a short time. On the other hand, by choosing B) you will learn something new and probably will have a better instrument in your hands. Of course you will have to invest some time in learning process and probably read things that you will not use directly. Option C) will probably bring you a lot of fun. For me, the most interesting part in programming is the architecturing. You know, all those moments when you choose the name of the classes, make the relation between them and think about abstractions and patterns. However, if you want to have a well written application, this approach requires some experience and of course - time. It is good to follow the DRY(don't repeat yourself) principle and sometimes is much cleverer to use code written by more experienced people, which is tested and has no bugs.

The answer

So, which one of the options above is the correct one? I'll say - neither one. The perfect solution combines elements of all three options. That's why I believe that the future is in micro-frameworks. In the next few years we will be writing less primitive code, but code that binds different modules into one application.

Why the big ready solutions are not such a good idea

Big part of the development process is managing complexity. The more problems you try to cover the more complex application you will have. The truth is that the big frameworks are complex. And that's because they try to solve a lot of problems. Their codebase is huge and you need more time to understand how they actually work. Very often when you want to do something you have to dig deeper and deeper in the architecture and probably make changes in many places. Step by step the focus of the real problem is changed and you are not working to solve it, but making preparations for the final solution. There are many predefined things that restrict you to be creative and guide you to think like the creator of the framework. Another problem is that you will probably have dozen of things in your codebase which you will never use. There is a term "speculative generality" and in a few words it means you think that you will need something and you add it, but you actually never use it. This is a common problem for the most of the frameworks /at least for me it is/ which leads to unnecessary complexity.

Why the custom solutions are not that good idea

As I already mentioned, some experience is required to write everything by yourself. The time, which you will spend, is also probably beyond the budget and the result will not be the perfect one. Also, if you plan to work in a team, your colleagues will have to spend time exploring your solution. If you don't have any good specification this could be not the easiest task.

The concept

First of all, there should be any system for distributing modules. With tools like Composer and Laravel PHP gets really close to this idea. I think that the package(dependency) management is very important part of the development process. Not only, because it speeds up our work or delivers what we need, but because it encourages modular programming. Not many people think about what they are writing as an independent module. Things will change if you know that your code will be used by other developers - you will produce better libraries. You plan your code, you think about your API, you write documentation and tests - you actually design something. Not just writing code. The programming becomes more interesting and with services like GitHub you are able to create something really valuable. Once we have a better dependency management the community will produce better modules. And that's because the people will be interested to have the things done in a better way. I hope that one day we will have a giant toolbox and will be able to grab whatever instrument we need. Just think what you are using now - a router, template engine, some kind of response class, a mailer. Imagine if all those things are absolutely independent and you are able to decide whether to use them or not. Even better - you can try them and if don't like the result just replace the module with another one. Once you have such trivial things setup, you will focus on the real problem.

Conclusion

Start using Composer or some other package manager and if you need something just build it as an independent module. Try to minimize the dependencies in your project. Ask yourself all the time "How this should look like so I can use it in my next project". Avoid clever design, because in most of the cases such design is difficult to understand. It is much better to write simple one-task modules than complex network of classes. Start writing tests and documentation for your code. Share it, no matter how good you think it is. There is always someone, who could find your code useful. If you still don't use GitHub, create an account there and take part in the libraries that you use.