Designing the code is more important than you thought

Personally, I always think that the design phase of a program is very important and it should be done almost immediately after I started setting up my git project. Like all other new developers, at first, when me and my cousin were working on an Android project, we thought it would be just a waste of time. Surely after a month, it started to really fall apart as we have all sort of problems like our implementations does not work well together with a lot of lengthy methods that is definitely not necessary to be that complex, and we even used some dependencies that are obsoleted just to make another piece of code compatible with the situation. We learned our lesson and from then, we developed a habit to jot down some idea and implementation to at least let each other and ourselves how we would carry out the project. I actually found this article months ago and I think it's already pretty neat, so I decided to write my blog this week based on it.

For a start, this article is written by Marcus Biel and it mostly talks about what he called "Clean code", which is basically the idea to have your code be precise and as close to perfect as possible, even though it is a small project. I really like the part where he says "If you have more code than you need, it shouldn’t be there. There shouldn’t be anything superfluous, and I go so far as to say that there shouldn’t even be superfluous whitespace. You want your code to be as efficient, readable, and maintainable as possible, and instead of only solving the problem." This is probably what everyone should expect to achieve after finishing their "first draft" of the program.

Some would ask why is it so important to spend a lot of time on this phase. He gave two simple cases that are really relatable to programming. Imagine living in a house that was built without any blueprint and when it falls apart, you would not even know where to start to fix it and eventually, the roof caves in. For instance, when you have a shopping cart, of which function is to put things that you would buy into but people keep throwing trash into it until it spills out and you don't know which one to put on the checkout counter. In these cases that he gave, it was really clear that there are no boundaries or rules to maintain your object and prevent it from long-term problems. The lazier you are at first, the more efforts you have to put in in order to have it up and running. Even if most of us are not perfectionists, this problem can't be ignored as our projects would get more complicated the more we develop it.

Now that we know that it is critical, we can look at a few ways to accomplish clean code. The simplest thing that you have to do is to not think it as a coding project, think of it as a design and planning process. Let's pretend that you are building a house. A strong foundation is what we really need and that can be seen from the coding aspect as file structure, classes, and methods without any bodies. When you have a solid foundation, it would cost fewer resources to maintain as it is already hard to fall apart and even if you want to expand, it is much easier to base on the old foundation, rather than having to build another one.

Not only a solid foundation that we need, but we also need the coherence, or should I say it is easy and makes sense to everyone who read it. The author of this article makes a point that we should follow the idea of "ubiquitous language", which is to have your variable names, class names, and package names to make sense to whoever is reading your code. This design is called Domain-driven design. In addition to this, I also think that it is important to follow the naming convention, use detail unique name for variables and practice proper indentation so that myself and the one I work with can see the structure and what words mean without having to scroll up and down a lot.

Without any further reading, I think these pieces of information that I have given are quite enough to convince you to think and start to develop the habit to have a design phase before carrying out the project.


Popular posts from this blog

Software Quality Assurance Introduction

Reflect as you work

Static testing and Dynamic testing