Developers: as your skills improve, you start to realize that there are an endless number of ways to code up an application and an endless number of areas that can trip you up. When working on a development it’s expected that you will run into many time consuming problems. While it can be stressful and frustrating, experience will help you decrease the amount of time it takes you to get from start to finish. Or you can also learn from the experience of others.
Here are a few tips to help keep you on track and keep you from getting too frustrated.
Clean code, dirty code
When you are just learning how to program, any time you get something to work how you want is a victory. Even the simplest “Hello World” script can be very rewarding. It doesn't matter how the code is written, what matters is that you got it to work.
As you continue to develop and your skills improve your personal development style begins to emerge. It's typically at this point that you start to see the difference between "dirty code" and "clean code."
The definition of what constitutes dirty code and clean code is different for each developer. Generally speaking, dirty code is any line of code that you look at and immediately do not like. It just doesn't feel right. It might work, but you don't like how it is implemented for one reason or another. Perhaps it's too long or it might be extremely confusing, but for some reason, you don't like it.
Clean code on the other hand is the exact opposite of dirty code. It's short, simple, easy to read, and when you look at it you think to yourself, "Yes, I am that awesome."
Once you begin to distinguish clean code from dirty code, you are now subject to a never-ending process of trying to make your code cleaner and better. This isn't actually a bad thing. You really should always strive to build applications with clean and efficient code. In the long run, it will make maintenance, debugging, and future development much easier and more enjoyable.
The re-factoring trap
While keeping your code as clean as possible is not a bad thing by any means, it is important to keep an eye on it, especially when you are doing the initial build. It’s not at all uncommon for developers to work through their application and wind up getting wrapped up in cleaning up dirty code before the full system is even built.
“If you are not careful when doing this, what you will find is that you are spending more time cleaning up code than you are actually building the system.”
If you are not careful when doing this, what you will find is that you are spending more time cleaning up code than you are actually building the system. Unfortunately, one of the biggest lessons in development is that, until the whole system is put together in its entirety, most of the code you write is subject to change.
Imagine spending five hours just to get a specific part of your application to work, and then spending another 3-5 hours re-factoring the code you initially wrote only to realize tomorrow that everything needs to be rewritten because it doesn't account for this feature or that feature. As you can imagine, this can cause serious delays and a lot of stress, especially if you are working on a project with deadlines.
So how do you avoid the re-factoring trap? One of the best ways to avoid this problem is to accept your dirty code how it is right now, and continue on with the project. That's not to say you're going to leave it dirty forever; that would be wrong for yourself and for the client. But, for the sake of progress, you are going to leave it how it is for right now, and come back to it later.
Leave comments, leave it for later
In situations like this, code comments are your best friend. In the initial development phase, I like to comment on anything and everything. In some cases, my comments are longer than the code itself. Why you may ask? Because comments allow me to save time by explaining the code so I don't have to walk through it line by line to understand what's going on. I also use comments to make it known that certain sections will need to be re-factored. Ultimately, this allows me to stay on track and keep moving.
Of course, once your application is in working order, re-factoring can begin.
So how about it? What do you do to stay on track while developing?
Photo Credit: Gizo