On November 22nd, the “Quality” special event of DevOps Technology Salon series hosted by Coding was successfully concluded in Shanghai. At the event, four technology gurus from Tencent and other well-known enterprises shared their practical experience of R&D quality and efficiency, and discussed with the audience how to take effective measures to ensure and improve the quality of software.

This Salon Review brings you a topic from Tencent Cloud Coding Evangelist Zhou Yang – “DevOps Code Quality Practics”.

Problem: More people, more messy code

As the team grew in size, each person had different habits for indentation, newlines, whitespace, and capitalization, causing the code to get messier. While the code style issues are not fatal, they are more serious:

  • Hard code: Writing various environment configurations, links, and keys in the code creates a security risk
  • Magic Number: Difficult to understand and maintain
  • Excessive lines of code: Difficult to maintain and a violation of the object-oriented SOLID principles

Many industry giants announced the code specification, recommend everyone to use directly, because their own invention specification is often not comprehensive, it is difficult to serve the public.

Code specifications are more than just a matter of indentation and newlines. By enforcing constraints on cyclomatic complexity, the number of lines in a file, and the number of lines in a method, they force people to design in an object-oriented fashion.

How do I enforce code specifications

We have code specifications, but how do we get there? Is a problem that many teams face. The Lint program is used to check code specifications, and each language (such as Kotlin, Java, PHP) has its own specifications and Lint.

There are three opportunities to automatically check code specifications:

  • IDE: The most real-time and convenient, but requires configuration by all and may not be supported by some IDEs
  • Git Commit Hook: When committing, the command line tool is called to force the check. The advantage is that it is very timely, but there is a risk that it can be deleted
  • Server: Checking on the server after Git push is very reliable, but the disadvantage is that it is not real time

Therefore, it is recommended to use all three methods together.

What happens after the code review? There are thousands of irregularities in an old project that obviously can’t be cleaned up all at once, it’s not realistic for everyone to stop the old project to clean up the old code, and the risk of changing too many files at once is high. Therefore, it is recommended to use incremental check, especially the Java incremental check scheme is more complex. For details, you can identify the following two-dimensional code and read the CODING document.

Server-side review: Continuous integration (continuous integration of code into the trunk, quality built in) is recommended. The process is as follows: lock the Git trunk, everyone develops the function to pull the small branch, trigger the continuous integration to check the code specification after the small branch is submitted, and inform colleagues to review the code after passing the branch, so as to improve the code quality through this process. Coding Continuous Integration is compatible with Jenkins, the graphical interface is easy to get started, and smooth migration if the project is already using Jenkins.

The code is clean, but is the result correct?

The dilemma many projects face in the end is that no one dares to change the old code. For example, developers would copy existing functions such as get() and change them to get1() and get2(), which caused the project to fester over time. The root cause is that no one knows if modifying the old code will cause a call to fail somewhere else.

In a team architecture where development and testing are separate, a responsible developer writes code and then tests it himself, and then tests it back to testers. However, in the later stage, people gradually become impatient. From self-testing in 10 situations to 5 situations, to only testing in one situation, and finally to directly testing without self-testing at all, all the pressure is gradually transferred to the testers. The responsible development gradually becomes the irresponsible development, the problem still lies in the mechanism.

Foreign countries started this program more than ten years ago: test personnel transfer to learn programming development, only a small part of manual testing. Developers write their own test code, and if test coverage is not up to the mark (say, 80%), merges are prohibited.

How can developers feel confident about their code? Even the best programmers can make the most rudimentary problems, so writing your own test code is the most reliable solution. The test code covers a variety of boundary cases, and even if someone else rewrites the code, they won’t have to worry about failing.

When is the latest time to start automated testing?

Automating tests is great, but there is a dilemma: you are too busy to write test code.

From a career point of view, I can use the time spent on manual PostMan self-testing to write automated test code. This will improve my skills and save me time on retesting the code later on, instead of the business code, which is hard to grow.

In the past, the project quality of large companies in China was generally very poor, because in the first 20 years, it was the dividend period of 2C, and they were rapidly seizing the market. But now it is time to defend their territory. In the past two years, large companies began to pay attention to code quality issues, and I suggest that everyone should make early preparations for this opportunity.

From the company’s perspective, it’s all about timing. 2 c project gradually mature, for example, user quantity is large, the loss of fault line is greater than the cost of hire more developers, or as the project functions increase gradually, regression testing time longer and longer, if a website online several times a day, one day the whole site all function test is not practical, so automated tests to ensure continued high frequency of online. Serious bugs in the early stages of a TOB project may require compensation to the customer, so automated testing is needed early on.

Code quality rating criteria: As you can see from the figure below, code quality criteria for the “excellent” level allow a cyclomatic complexity of up to 5, no more than 50 lines of classes, no more than 10 lines of functions, and 90% test coverage. Coding partner Youpufeng provides CSD certification training to help developers achieve the corresponding standards, can identify the QR code to understand the details.

So that’s the end of this sharing, you can go to B station to watch the speech video and get the full PPT, or go to CODING to learn more.