How to keep clean and organized code in the code-base? - Part 1

As developers, we’re facing a lot of challenges while implementing specific functionalities related to our tasks. The important part of the time that we spend on, is to recognize the issue – that applies to fix bugs in our software. It is the first part, and you might not know but that is really not your fault or your skillset issue if you can’t fix the bug in a proper amount of time. Around 20% of it depends on the developer, who wrote the part of the software that you are currently fixing. Another 30% depends on the technical leader, who is responsible for reviewing pull requests. The rest belongs to you, which means you can be saved – I mean, 50/50.

Do you think that you’d have a better understanding of the code that you’re reading if the previous developer delivered it in a better way? Probably.

1. How does it start?

Everything starts with the hiring process, if you’re a technical team leader, the techie who goes through the whole process, should also go through you, which means – deep technical interview. As a leader, you have to be accurate and make sure that you have made the right decision. Believe me, HR and directors trust you and if you say that this developer is the one who should work for the company – they will hire him or her because you recommended him. You have to take the responsibility for your actions.

After some time, the developer who has been chosen by you is coming to the office. Let’s say that your new hire went through all of the necessary steps to start committing the code and make pull requests. This is a really important phase – code review. Do you know one of your responsibilities as a technical leader? It is a code review, it has to be conducted in a solid way, and you can’t skip even a small piece of code because you felt tired and lazy to go through all of the lines. My advice: If you‘re feeling tired or lazy to go through all of the committed code at once, split it into two days, because it is understandable that you can receive a huge pull request, containing 500 lines of code.

It had happened to me, I know what I’m talking about. I’ve been reviewing a few smaller modules and then suddenly, I got a long one and when I saw that I told myself – I will do just a few lines and the rest I’m going to leave for tomorrow. Why did I do it? Because as a technical leader, I was feeling responsible for the codebase and obviously, this code is going to visit production environment as well.

2. Before development runs

Yes, before you start the race with the time in order to achieve the goal, which is a properly delivered project, you have to set some rules. Let’s assume that you’re a senior or lead developer, which means that you’ve got an important part in your collection of responsibilities.

Let’s kick it off from preparing set of code best practices that you’re going to use in the project. If you don’t do it, you’re going to hit the point where you can’t find yourself because of lack of organization, plus others will be committing their code freely without any kind of boundaries. That can’t happen, you have to accommodate some time to establish code patterns for the project.

That was the first step, secondly, if you’re having a technical architect at the company, you can take a sit with him and talk about the repository structures and branches. It is really important as well to be in development peace, because if I see that everyone makes their own rules and everything is different – it will not be stable.

This is what that is about – stability, without having code patterns and repository structures established, there is no stability and believe me, after the short period of time it will collapse and it will start demotivating you and your teammates.

3. Approach for the code reviews

I wanted to first touch on the subject of code reviews. As I said above – it is essential. If you’re working on your company’s project, imagine that it is your software and you’re going to polish it and take care of it as it was yours. There is a significant feeling that you need to have in your mind to proceed with code reviews. You need to have motivation and determination to do it and if you don’t have it, you’re going to fall quickly. You’re going to rapidly recognize if you have above feelings toward pull requests, when you get one, containing 500 lines of code.

2.1 I have the motivation

Great! Congratulations! But it is not enough, you need to have sufficient strength to go through the code, and don’t say whatever after reviewing 50 or 100 lines. As I mentioned above, you’re going to hit the iceberg, because your brain is getting tired. There is a way if you’re having a lot of responsibilities to handle as a lead, which is completely normal and a natural thing, you need to plan it properly. Take a sit, take a deep breath, get the notebook and start writing your plan for the day. I’ve been approaching it, by splitting my day into per cent chart. It was helping me to don’t limit myself that much and also lowering the pressure, because I wasn’t seeing hours on the paper, I was seeing percents. I knew that it is working like a progress bar and it counts hours as well, but it was stimulating my subconscious in a better way.

I’ve been spending 20% of my day to do code reviews and the best time for that was in the morning. In the morning, you’re fresh, your brain is not tired and is not going to get tired fast, which means it is the best time to review the code of your teammates. It gives you the space to make better decisions and to propose new solutions. You need to make a right timeline decision in order to perform a proper code review. Let’s say that you have planned everything, but your plan says that you will spend 20% of time afternoon, which is risky. Why? Even having enough self-motivation, you’re going to miss something or skip it on purpose, plus you will not have a fresh mind, which means fewer smart ideas on how to improve the code and loss of concentration, which makes you be in the clouds instead of the ground, thinking on a better solution.

2.2 I don’t have the motivation

In that case, there are no easy ways to figure out, how to bring your motivation to do the code review. I have had that situation several times, then I’ve been thinking that I can change something and it will matter because customers will receive a better performance in the web browser and the production code is going to be improved. Sometimes, you have to stir your ego up and say that you are the right person to do it here and no one else, but I’d bring it only if you’re really feeling demotivated.

I know that it is hard to start if you’re not seeing the purpose in it. I can tell you that I have met this feeling, and I have realized, it was because I was overwhelmed by too many tasks. I was having too many tickets assigned to my name, and the pressure is not a good medicine to start doing code reviews. You have to think, what is bothering you and try to find the best way to approach the problem, otherwise, you will not sit down to perform code review in a proper way.

2.3 The way of reviewing

Is there is a perfect way to review pull requests of your teammates? The answer is no. Believe me, there is no golden rule to do it in a way that makes everyone like it. But there is a way to make your mates, feel appreciated even if they have a lot of code to correct.

The important part is to have the right approach in writing. Yes, you’re not just a mentor, who has to have a high skill set but also be a good writer and choose proper words to describe, necessary changes. You should remember to write proper comments for each line that needs change. What do I mean by saying proper comments? It implies to be polite, because if you’re lead developer and senior, obvious is that, if you’re reviewing code written by the junior developer, you’re not on the same level. Be polite in your writing to don’t hurt feelings, demotivate or embarrass. It’s not the point, the point is to write the review of the code that motivates and gives the feeling to correct it because you can learn more, and treat it as an advantage, instead of another burden to correct.

Another important point to mention is while doing a review don’t try to add as short comments as possible to save more time and energy, because code review is not only about you and the product, it’s also about your teammates, who can learn from you and improve themselves. I mean, when you write the comments, give it more depth and colours – explain properly why this change is taking place here and give necessary resources to discover and go deeper. Also, the best approach would be to go to your mate and explain why. The eye contact will work much better and you can dive deeper into it, by explaining it by using your own words, because docs don’t explain everything beautifully all the time.

4. The way of looking at the code

I’m not going to tell you, what to do. I’m going to try to introduce to you, what you can take a look at while performing code review. I don’t have to say that it is really important for you to have a…

More in the part 2