· Reply “IT” in the public account and send you an imagination chart

This article is from the author’s former pawn on GitChat, “read the original” to see what people have done with the author.

primers

Met a stranger, only to see his muddy shoes.

On the subway in summer, I smell the sweat of people around me.

A party with friends. Looks like some people didn’t wipe their eyes.

We’ve been talking about him ever since we first met.

Why has no one thanked you for pointing out the shortcomings of others?

Not only is there no thanks, there seems to be abuse and some people will beat you for it.

Did you do something wrong?

———— The Fable of a Pawn in a tent

As a coding social activity, Code Review has been criticized. Everyone seems to know that Code Review is good, but there are various difficulties in promoting it. The “programming with an IDE” thing doesn’t seem to need promotion at all. Why is that? Because Code Review inevitably points out that other people’s Code is inadequate. We also often come across:

  • After comments/suggestions, coders do not modify;

  • It’s always the same mistake over and over again;

  • Resist your comments and seek Review.

We review other people’s code, we don’t just like it, that’s what encouragers do. We’re basically pointing out where other people’s code is bad. I’m sure even the kindest, most rational programmer would hate those comments.

Even so, we have to comment and make others accept our point of view. But in order for others to be receptive, there must be the right encouragement.

Also, before commenting on someone else’s code, it’s a good idea to know who wrote it. If it is anonymous, of course, can be unscrupulous comments.

But Code Review is a non-anonymous social event: we all know who the coders are, and the coders know who the reviewers are. It’s the same with speaking skills: “Say something to someone.” So we need to know the coders first.

1. Read the code

More terrible than ghosts and gods, is the heart.

———— The Lost Tomb

It’s so hard to read people. It’s even harder to read people in code. If you spend a lot of time with your coders, you can get a sense of your personality preferences. If you’ve never met a coder, what can you learn from just looking at the code? We can’t tell a person’s blood type, star sign, hobbies from the code;

Nor courage, optimism, tenacity, depression, or sadness; It’s hard to tell if he’s expressive, analytical or doer. Of course, none of these traits are useful for evaluating code. To understand the human mind from code, focus on three things:

  • Do you code carefully

  • Are you passionate about technology

  • How good is your coding?

Why only focus on these three areas? Serious coders pay extra attention to details, point out the flaws in the details of their code, and their skill level will surely improve.

Passionate coders can’t wait to use new technologies, new syntax, and new components. Tell them if the new techniques, syntax, and components are being used properly in the code.

High level coders are happy to improve their programming skills and break existing rules, focusing only on logic errors and runtime problems.

When reviewing, do what they want you to do so that the coder trusts you and then accepts your suggestions. What if the coders aren’t serious, passionate or good at coding? We’ll talk about that later.

Serious coder

Did the coders think about the details you thought about, and the points you didn’t think about? Is every detail of the Code Style specification followed? Is the boundary case taken into account? Are detailed notes written where special treatment is required? When he sees your comments, does he respond to every one of them, with or without agreement?

Passionate coders

Are coders trying new technologies: new components, new syntactic sugar? Are you willing to solve problems that others don’t? Is not-so-beautiful code redolent of trial and error? Are problematic third-party components circumvented? Have you tried to write common components? Do you have new ideas for old problems?

A high level coder

There are pros and cons to coding, but most of them are in your head. Sometimes you look at someone else’s code and you think to yourself, “This code could be simpler, easier to write.”

So pros and cons are mostly compared with their own: the technology is better than their own, or worse than their own. If you are familiar with the team, then you can get a sense of where that person’s coding might be on the team.

However, the amount of code submitted by the coders is too small, or mostly log/print/bean, to understand the characteristics of these three aspects, so use comments to communicate more times.

2. Write reviews

For the first time, you’d better give more likes and suggest how to code. If the person is new to the job, it is best to point out any changes to the program at once. One was that he had time to revise; Second, new employees need to understand the coding specifications of the company; The third is to improve his coding level.

In the process of review, new technology should not be denied, nor should it be easily affirmed. The application is the basis for evaluation. Why use these new technologies? Is it old and difficult to write, old and inadequate, or just a taste? For research teams, we encourage the use of new technologies.

Whether digging or filling pits, it is necessary to understand the functions and characteristics, maturity, performance advantages and disadvantages and applicable conditions of a variety of new technologies through their use.

For the functional delivery team, whether it is launching or developing software for customers to use, it must be stable while meeting the needs. Otherwise later will be bug tired, tired on the run.

The same message can be written in different ways. Have fun with your work. Don’t make boring, boring comments. Here are a few styles of comment:

  • Ridicule. Target a colleague you know well or someone with a high technical level. Funny and easy to accept.

  • Gentle suggestions. For passionate people, technical pursuits should not be eliminated. More questions are given priority to and let them reflect on themselves.

  • Criticism. For newcomers who make the same mistake many times. The mistakes they make are easy to fix, such as writing too many constant definitions, using Linux newlines, printing without system.out, and so on. Sometimes use interjections to toughen up the criticism, or the new guy will make the same mistake next time.

  • Be direct. This is probably the way most comments are made. In addition to pointing out the problem, you should also suggest how to fix the code. This will reduce his rework and reduce his resistance.

  • Sarcasm. Unless it’s your best gay friend, don’t use it, don’t use it, don’t use it, say it three times, don’t make enemies.

3. Face to face

While you’re in person, listen to what the coder thinks of your comments. Instead of jumping into a rage over a disagreement, ask him how or why he doesn’t want to change it.

The starting point is the word “benefit”. But the benefits can vary: for the coder, for the team, or for the company. It’s up to you to know how to keep people happy and follow your instructions.

Programmers, rational animals, sometimes hate flattery more than anything else. We all rely on technology to make a living, although it is important to sugarcoat, but it is more important to state the pros and cons.

Some people don’t want to change their code even if you talk to them calmly, so focus on the boundaries of the problem. If it’s within the boundaries of tolerance, or ignoring the suggestion, or allowing the developer to change it later. If it is outside the border, it should be argued. So how exactly is the border drawn? Let me write it below:

  • There are bugs in the code. Bugs cause all kinds of errors, some of which result in data corruption, file corruption, and other hard-to-fix problems.

  • The code is difficult to understand and maintain in the future. Of course, if the person who wrote the code never leaves, he can maintain it himself. When people leave, it’s up to their successors to take the risk of refactoring the code.

  • Long running has problems. So how often does it go wrong? See how often you deploy again. If you deploy every day, two days is a long time.

    But in order for everyone on the team to be rested, have their own holidays, and not be interrupted while they’re away, try to think long term. If you have up to 10 days on vacation, at least consider running your software for the better part of a month.

  • When a large amount of data is accessed, the code runs slowly or breaks down. If you expect data/traffic to reach this size after a few days of deployment, make sure you change the code early.

  • The change will save others a lot of time. There are even greater benefits if code is extracted as a module or component. Especially if someone else is about to start this part of the work, be sure to extract the relevant code as soon as possible.

    If you don’t extract, one, someone else has to write the relevant code; Second, once there is modification, the same function of the code will be modified; Third, even if components are extracted later, no one is willing to refactor.

We are all dedicated technologists, and we have a line in our hearts that cannot be crossed. We also hope that all coders do not cross this line.

We communicate this bottom line to the coder, which is also the responsibility of the reviewer in Code Review.

But the proposal was written, the meeting was held, and the coder and the reviewer were at lodgings. There is no other way, only through the human relations in the company to solve:

  • If it is your subordinates, have already explained the reason, or do not carry out, that is the subordinates incompetent.

  • If it’s your supervisor, you’ve told him about the risks, and he doesn’t think your suggestion makes sense, ask him to make his point. Of course you think he is a stupid leader, just walk away; But if you go above and beyond the call of duty, that’s a no-no.

  • If it’s your peer, inform him of the risk of his superior code and leave it to his superior to deal with.

Of course, you need to know that for tradeoffs: sometimes for emergency access, sometimes for greater profit, even if you cross the line, merge your code first.

What is Code Review for? Ultimately, it’s about profit. In a company, nothing is considered, just to write perfect code, that is really stupid.

“Read the transcript” for the Chat transcript