I originally intended to write an article about Code Review, but later I found that there were many stories involved. In this article, I tried to propose a new way of Review, just for your reference.

Do you do Code Review?

I searched zhihu and found the following sentence:

Don’t go to a company that doesn’t do CodeView and beta

There are many benefits in Code Review, and more pages are not needed to explain how necessary Code Review is. The main problem is that most teams in companies, including my team, find it difficult to do a good Code Review.

There are the following factors for poor Code Review:

  • Time is tight, schedules are tight, business is tight,Code ReviewToo much time
  • Demand changes so frequently that they are overwhelmed by demand
  • Team consciousness is not in place, engineering thought is insufficient, lazy to do
  • Writing may not be good, and there is no way to give colleagues advice, technical reserve is insufficient

How do other families do Code Review?

In general, there are two approaches:

  • Regular openReviewMeetings, daily or weekly
  • andGitDevelopment flow integration, specify colleagues when submitting PR/MRReviewThe code can be merged only after the check passes

These two methods are classic, and many auxiliary tools have appeared at the same time, among which the following two are representative:

  • Phabricator: Facebook works, based on PHP, MySQL, fully functional, supports multiple code repositories, has social attributes, which match Facebook’s DNA, providesReview 和 AuditThere are two modes,ReviewModel usingpre-publish.AuditModel usingpost-publish, can refer to the articleReview vs Audit
  • Gerrit: Google’s work. It’s a very mature system
  • GitHub or GitLab supportPull Request 或 Merge RequestBasically, but the center of gravity of these two systems is notCode Review

In the above list, I have only used the last one, and the others are just introduced. It is not easy to make comments. It seems that people prefer Phabricator.

Here’s what I think.

Synchronous and asynchronous

Signing of the premise to carry on the Review, or a meeting to Review, is the process of synchronization, they only want to be online or the parties together, this way is time consuming, code reviews particle size is larger, functionality is basic testing finished, Review the problems and needs to modify the development development also don’t want to change, because what is done cannot be undone, change, There may also be risks affecting the line. PR/MR can also be less granular, but for both parties it can still be a waste of time and end up going through the motions.

If the use of asynchronous review, review once a day, each granularity will not be too large, the review will not take too much time, scrolling moments of time, the code is finished, most of the code is no problem, the occasional problem, timely put forward, can be corrected on the same day.

Remember, synchronous mutation step is a process that has always existed in the real world:

  • It used to be all phone calls. Now it’s wechat
  • Used to shop at the mall, now online
  • It used to be the hour, but now it’s anytime
  • Taxis used to have to stand on the street, but now they use didi
  • Before must get up early to go to the hospital registration, now 114 make an appointment, self-help machine takes number

It seems like the whole world is moving in an asynchronous direction, so can code review be asynchronous?

Culture making

Speaking of the formation of culture, this should be the topic of some culture guru, I just briefly give my opinion, paving the way for the following content.

Here’s what I think:

Culture must have corresponding environment, carrier and audience

Such as:

  • After having the Internet, appear buy online culture, come up is a: close ~
  • With micro-blog, circle of friends, there is a “like” culture, not a “like” meet embarrassing
  • With Douyin and Kuaishou, there is a culture of short videos, live streaming, and Laotidoudou666
  • Traditional Peking Opera, without its environment, stage and audience, must be packaged with modern music, such as Chinese-style music, in order to become popular again

There should be many more examples above, but I am not in the culture, not to say more

What I want to say is that we need a vehicle to drive culture based on our environment.

What is our environment?

Product iteration is rapid. It takes only two or three months for a new product to be launched from the idea to the first version, and the operation lasts for half a year

The age of the Internet, this kind of phenomenon is very common, very much big company annual failure products, for the company to try new products, model is a good thing, but for programmers, the toes, nobody CARES about your technical growth, complete Code Review, is a good habit of team technology growth, but in such an environment, How to do Code Review?

For example, Microsoft, IBM, Google,Facebook and other companies have high requirements on software quality, security, performance and so on, because their products have a wide audience and a complex operating environment, which requires pre-submission review and single test.

In the middle stage of large Internet companies, stable products provide guarantee for the business team. They have high requirements on quality and stability, and can do single test and pre-code Review well.

Review vs Audit recommends the Review mode

If you aren’t interested in review, just do audits. You can always change your mind later. But consider review! It’s really good, we promise!

We are different from them, in the environment is different, so if you really want to copy their practice, you will feel uncomfortable, too dogmatic, and finally from the entry to give up.

We have to think about solutions based on what we’re doing, not just what we’re doing, so we need a new vehicle to help shape our culture based on what we’re dealing with.

This new carrier is the Daily Review system.

Build the Daily Review system

I have spent a lot of space on the background of this system, mainly hoping to propose a solution in the environment we are facing. If your team has a similar environment, maybe this system is also suitable for your team. The design ideas of this system are mainly described below.

  • CommitStream, the system merges each person’s daily code into oneCommitAnd everyone can use itRebaseCommands to optimize their ownCommitFor easy browsing.
  • People as latitude displayCommitInstead of streaming to the system, users can select someone to follow and only show the people I followCommitFlow.
  • Mission driven, every single oneCommitAs a mission, clean up your own mission every day. YeahCommitSubmit a change proposal, or you can discuss the optimization plan, and then send it to the code author as an optimization task.
  • You can like it to encourage good code.
  • System based onGitBut it is not strictly required to merge into the development stream, that is, to do it asynchronously rather than synchronouslyReview.
  • Support mobile terminal, convenient bow, can also go to work.

The above is a brief description of this system. Looking back, isn’t it a Zhihu or microblog system? Yes, it is

So what are the benefits of such a system?

  • Code ReviewSpread it out over each day, take 10 minutes to review the code that everyone writes each day. If there is any problem, put it out in time, and you can fix it that dayPR/MROr openCode ReviewIt comes up in the meeting and is asked: Why didn’t you say so?
  • You can focus on whoever you want, you can focus on the big guy’s code, not necessarilyReviewHis code, you know, see what the big guy writes every day, study more, or pay attention to his colleagues’ code, seeReviewTake notes to avoid making the same mistakes.
  • Leaders can look at new employees and see what code is being written every day,Code ReviewHow’s it going? See if you’ve made any progress lately? How is the project going? Monitoring the code you write every day. Is that tough? Of course, leaders can also view your code on GitLab, but it’s a bit of a hassle
  • For developers, thinking that someone will look at their code the next day, they will think more carefully about their code, and perhaps ask their colleagues how best to implement similar requirements. I’ll also refine comments, because my code is for people to see.
  • Precipitation knowledge, targeted at the goodCode ReviewAs a best practice, new employees can browse and reduce follow-upReviewThe cost of
  • Including everything elseCode ReviewThe benefits brought about by

Ok, this is the Daily Review system I imagined. What do you think of it?

I believe that even traditional software companies that have done Code Review well may want to have such a system.

Ok, every day at work, I start to deal with Review tasks. When I am bored, I can brush the Review system. When I am queuing, I can look at the codes and communicate with each other.

However, I am still a little worried. After all, scrolling through moments and Douyin will be pleasant, while scrolling through Review system may not be so pleasant. This may be a problem, but isn’t it a pleasant thing to maintain a transparent culture and a culture conducive to growth where more people will follow you and give you good suggestions?

Other questions:

  • Use code before submissionLintTools to check,ESLint.TSLintAnd so on, check through resubmission, avoid format problems and low-level syntax errors
  • The design of theReview, it is better to describe the design before starting work, and add a relevant catalogueReadmeDocument, as aCommitsubmit
  • CommitFormat specification, easy to extract information, referencecommitizen
  • Phabricator 的 AuditPatterns can also be tried

The last

This paper tries to propose a new way of Code Review. In short, it uses systems such as Weibo and Zhihu to conduct Code Review, and tries to make Code Review into a kind of culture. The parts about synchronous asynchronism and culture formation are YY without reference to CCTV. Improper place please correct, hope we can have a harvest.

Next time, you Can say: Can I follow your code?

Reference reading:

  • How to make technology from CODE REVIEW
  • Code Review best practices
  • Has anyone tried Phabricator and Arcanist as a code review tool?
  • How does your company conduct Code Review? What problems have you encountered?
  • The department does not conduct Code Review, what remedial measures are there?
  • Phabricator : Review vs Audit