Reprinted-[viewpoint] Code review in the 21st Century

Guidance:CodeReview has been widely recognized as a very good practice. Many large companies such as Google are also doing code review. Code review not only helps your work, but also shares knowledge. The original Article is code reviews in the 21st century. This article is now compiled.ArticleThe content is as follows:

Code review can end in the software engineering fieldProgramUnnecessary disputes between members. Developers often bicker and offend each other because of stupid things, or even get stuck with bugs before Q & A's Q & A, and disputes are always around you. OK. Do not get me wrong, because we have reason to believe that code review is definitely a good method. The reason is as follows:

1. The earlier the bug is discovered, the lower the project cost. You do not need to release a repair patch because it is in the development stage.

2. Code becomes more and more important.

3. Knowledge runs through your team, and there is no longer a large piece of code that only one person knows.

4. Developers must redouble their efforts. If the developer knows that someone else wants to evaluate his work, he will take extra efforts to do the work well. At the same time, he also prefers to comment out the objection in the document.

Today, in the 21st century, many projects do not use code review. This article provides eight criteria for developers to learn and reference.

1. Never forget TDD

Before confirming the test code, ask someone to check whether the code is correct. Check bugs and handle them as much as possible before others do. The most important rule for code review is to find problems in the code to be submitted-what you need to do is to confirm that the code is correct.

2. automation as much as possible

There are several very good Java tools, such as PMD, checkstyle, and findbugs. The question is, are people willing to spend time reviewing code after using these tools?

Before using these tools, it is very important to develop a set of rules for these tools. This ensures that you use the same code review standard to distinguish it from code review specifications that are often used in the 20th century. Ideally, these tools can run on various version control systems to review each code through hooks. If this code is not good, it will be blocked.

3. Respect Design

It was too late to review code when I started working on Java projects. Because when you check for code problems, it actually causes defects in your design. The design pattern is misunderstood. Some complicated ancillary substances are mixed in or developers are separated from the topic.

Review will confuse your views. You may refute: "This is code review, not design review ". At this time, some mess will inevitably come one after another. To avoid these problems, we have changed the original design intention. Code review involves many aspects, both design and design review. In fact, our design review is more challenging than code review. Design requires higher quality and inspiration. We should avoid complicated thinking.

4. Unified Style Guide

Even using automation tools (such as checkstyle and findbugs) should avoid unnecessary style conflicts. Your project should have style guidelines. Adhere to the Java protocol standard whenever possible. Trying to create a "Dictionary" for your project introduction means that when this code is involved, you can check whether the usage and environment of the Code are appropriate, which is easily detected.

5. Select appropriate tools

If developers are using the eclipse development tool (Eclipse IDE plug-in Jupiter ), you can view code, debug code, and even use everything on Eclipse IDE to help you review code more conveniently. However, if you do not use the same IDE (or the IDE does not bring convenience to your work), you can consider review board. It is a good choice.

6. Remember that each project is different.

You may be working in the previous project method, but remember that each project is different. Each project has a specific architecture (high concurrency or high dispersion), a specific culture (maybe many people prefer eclipse), and a specific tool (Maven or ant ). Do you want to draw images like gourd? OK. Remember that different projects have different working methods.

7. Know how to choose

Code review needs to be positive and meticulous, rather than be learned. Will you cause project failure or company cost due to some trivial matters that make you nervous? Remember, never do this. Clear your mind and think about it from another angle, instead of remembering to change others.

8. Be buddies

In my opinion, "buddy reviews" (someone else will call it "over the shoulder") is very good. A buddy review refers to informal discussions with other team members every one or two days, and quick browsing (5-10 minutes) of each other's code. This method can help you:

1. Early detection of problems

2. Always quickly know what to do

3. The Code review does not take too long, because you only need to check the new code, and the old code will soon catch up

4. This informal occasion-no tension, it's interesting!

5. exchange ideas on a regular basis

Buddy reviewing is a good way to work in the team. When someone has problems in the team, it can be found early. This not only helps everyone, but also exchanges progress and ideas.

In short, if your project is under code review, it should be fast, effective, and do not waste others' time. As mentioned in the article, these points are very important. The purpose of code review is to locate the issue before code submission.

(Note: This article is compiled by Xia mengzhu. For more information, see the source)

Original article: dzone