A few years ago I learned about the CodeIgniter framework and after a while I became quite proficient with it. I built a bunch of applications during that time. They were relatively small applications, but after a while I started to notice a pattern.
I always had a very good start on a new project. But after a while progress slowed down noticeably and it seemed to take forever to finish a project. I heard the same from other developers, so I assumed that this is just a part of development and something that we have to deal with as developers.
The other thing I noticed is that my old code was always horrible. If I had to change something in an application that I wrote just six months ago, I always thought that my old code was pretty bad. I did not realize that the code that I was writing at the time was not that different from the one six months ago.
It took me a few years to learn better. I was trapped in the CodeIgniter ecosystem for a long time. I had a look at other frameworks during that time, but they all seemed so complicated. And I wouldn't even try to develop anything with a framework. It was common knowledge in that community that only beginners write code without a framework.
The turning point came when I came across Room 11 on Stack Overflow. I noticed that people there were quite knowledgeable. I was pointed towards some resources to learn more about object oriented programming and I made it a point to go through everything and learn it until I understand everything.
But even with that help, it took me about a year to get somewhat proficient. It was a lot of new theory and only after implementing things I got a grasp of them. I was lucky because I was able to implement a lot of the new things that I learned at my job. The other things I tried out on some side projects.
The more I applied the theory that I learned, the more I noticed that development speed increased. Things took a little bit longer at the start, but say after a month working on a project I did not slow down noticeably. Suddenly I was able to change things in existing applications without having to go around to change a lot of things and accidentally breaking unrelated code.
It took effort to break away from all the bad habits that I developed while working exclusively with CodeIgniter. But it was more than worth it in the end. These days I can look back on code that I wrote six months ago and I am not disgusted with myself. Changing things in old code is easy now. Of course you always keep learning and maybe you would have done things a little differently. But if you write clean code, maintaining it won't be the hassle that it used to be.
The goal of this book is to bring you up the point where I was after a year. This is not the end of the road. There is much more to learn. But if you write better code after reading this book, it has achieved it's goal.
So let's finish the story quickly. I had a hard time to learn all this stuff and most of the material was written for other programming languages. So I tried to pay it forward and started a little tutorial on Github. The goal was that other people in the same situation will have it easier than me. The tutorial was received pretty well and some people told me that I should turn it into a book. So here we are.
When you come across code that you wrote a while ago or code that someone else wrote, the first thought that comes to mind is often that you have to rewrite everything from scratch.
This can be done if it is just a side project. But if that code is making money for someone, it is often not a good idea to rewrite things from scratch. While the new code is being written, the old code will still have to be maintained. Of course if requirements changed, the same thing will have to be done to the new code. So you are now doing twice the work all while doing a complete rewrite.
And often, in the end you will end up with code that you want to rewrite again as soon or even before you are finished.
There are some exceptions though. If you are locked into a bad framework for example, you are often limited in how you can write your code and often not in a good way. There is a refactoring chapter where I show you how you can rewrite your application part by part without having to break everything at once.
So if rewriting is out of the picture, refactoring becomes our only option.
Very often code in a team becomes worse over time. For every few changes, some bad code is introduced into the code base. When there is a deadline lingering or an urgent bug that has to be fixed, things get worse.
The boy scouts have a rule: "Always leave the campground cleaner than you found it". So every time you find some trash, you clean it up. Even if it was left there by someone else.
As a developer you should follow the same rule. If you and your team only check in code that is cleaner than it was before, then the overall code quality will increase and not decrease over time.
So even when you don't have the time or option of a larger refactoring, you can still improve your code method by method. It might not seem like much, but if you follow the boy scout rule strictly then your code quality will improve over time.