Code Review from Scratch

[[156391]]

This post is not about introducing the Code Review methodology, but the first part records how our team went from having no such habit to doing reviews every day, and the last part gives some of my suggestions. I hope it can be helpful to your team.

When I first joined this newly formed team, there was no code review. My boss said, "You can do it this month."

When I first knew that I had to do a review, I actually refused! Because I thought...ah...you can't ask me to do it right away, ***, I want to give it a try, but I don't want to say...the team didn't have this habit before. After I did it, it would delay the daily work time. As a result, my colleagues would definitely scold me and add extra workload to them. I said let me give it a try first. Now...I review every day! I review every day...I have also promoted it to other teams! Come! Come! Come! Everyone give it a try!

There are many reasons why people feel it is difficult, cannot start, and want to refuse:

Team members write requirements and then leave them alone, without code review awareness

The technical atmosphere is not strong

Levels vary

Not having the right tools

…

But the general point is that there is no code review. If there is one, whether it is for real or for formality, it is not difficult to host it.

Starting from scratch is always difficult, so I started with several attempts:

*** Attempt

The original version was written by another team. When our team took over, there was nothing there. There were no spaces around commas and equal signs, the first letter of class names was lowercase, and the first letter of method names was uppercase. The dependencies were messy. Business was written in the view, and network requests were made in the view. I was devastated when I saw such code.

I first tried to review for the entire team by myself. I reviewed it sporadically for a few days and posted dozens of PPTs with problematic codes. There were too many complaints and it looked very touching. Later I gave up.

in conclusion

It is not advisable for one person to review the code of many people.

Second attempt

Pair programming can be seen as an agile code review. Direct pairing will kill you. So I thought of using a new pair programming method.

Two programmers form a new pair, each with a computer, sitting at adjacent workstations, and work together to complete the design and code implementation of a set of functions (which can be two or more independent modules). However, for a certain module, the design and code are separated, one person is responsible for design, and the other is responsible for writing code, and vice versa for other modules.

When I was looking for a partner to pair up with in the team, I found that there was no partner who could design modules and whose project progress was similar and who could pair up with me.

in conclusion

Code Review needs to be down-to-earth.

Third attempt

For the third attempt, I wanted to use a game approach to conduct the review.

The review moderator will take turns each time, and the student who has found the least bugs will be the moderator.

At the beginning of each round, the code is posted first, and the students below will point out the problems. (At this time, everyone should pay attention to which students have not found any problems every time)

***The host student will list all the questions.

Enter the next round

If the students below often speak more than the host, the host will continue the next day.

The host student should prepare at least 6 PPT questions every day.

The host will designate a classmate to revise the pointed out problems.

The host of the second day is responsible for entering the bugs of the day into Jira and tracking these fixes.

It's too idealistic and can't be implemented.

in conclusion

Don’t just think that something is good. Code review is a team effort. Once a plan is finalized, it needs to be put out for review.

Fourth attempt

In desperation, I asked my boss how to start this process. My boss gave me two words: force.

So my friends conducted the first code review under my tyranny. I used the PPT I compiled the first time. The effect was surprisingly good. My friends complained to each other about the poor code I pointed out, and the atmosphere was very joyful.

However, the key problem is that there is still no unified standard to change. So we immediately arranged a sharing session on code standards. In the next review, the points of complaints from the experts were relatively concentrated.

in conclusion

There needs to be standards in the early stages of code review. Let your colleagues know how to review.

Fifth attempt

Since the atmosphere was good before, a friend A suggested to bring out the module he was responsible for for collective review. Of course, I couldn't refuse someone who took the initiative. The next few days were all arranged to review his module. By the way, I also shared the design of his module.

During a review one day, a friend B said that this kind of on-site reconstruction is not his forte. We: What are you good at? Friend B: I am good at xxx. Me: Then you can share it with the big guys next week. Friend B: OK, I will prepare.

As a result, friend B kept it a secret and shared a whole series of posts.

in conclusion

There is a sequence in learning, and there is specialization in skills. Don't underestimate your friends.

Sixth attempt

I was assigned the task of code review, so I would occasionally look at my friends' code. One day, I suddenly found that a friend C was refactoring and optimizing the code. I took the opportunity to tell him some programming ideas and techniques, and told him that he could also refactor in this way, using table lookup to replace conditional statements, using polymorphism to replace conditional statements, using runtime to generate method names, and using runtime to execute methods. So he also came out to share his technology. Unfortunately, the discussion about sharing programming ideas was not so intense, so I had to do it slowly. But when I finished my meal and returned to the company at around 8 o'clock, I found that two friends DE were writing demos and discussing C's previous technology sharing.

in conclusion

The idea of ​​programming needs to be gradually understood, and cannot be forced into your head all at once.

Seventh attempt

During one review, I had something to do and left early. However, everyone felt that the half-hour sharing session was not enough, so it was extended for another 20 minutes. I was not the host of several sharing sessions before. In subsequent reviews, I will try to further downplay my hosting role so that our review can proceed in a self-organized manner.

in conclusion

Code Review needs to reach an ideal state - it can run smoothly without me, otherwise it will become a political task.

postscript

As the number of people in the team increases, the collective review method will also be adjusted. We will introduce some code review methodologies and tools. All things are difficult at the beginning. Now that we have started, I believe that subsequent adjustments will not be difficult.

suggestion

How to do a code review from scratch? My suggestions are:

The tech leader forces everyone to start code review, which is the most important step

Arrange a technical sharing session on coding standards

Review frequently in the early stages to see how the code review went and what can be improved

Encourage active students and support on-site code refactoring

Not only can you review the code every day, you can also arrange a whole technical sharing session