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.
