Review of offline Salon of coding Devops 1: Devops code quality

Time:2021-2-18

November 22, sponsored by codingDevops technology salon series “quality” special sessionIt ended successfully in Shanghai. At the event, four technology celebrities from Tencent and other well-known enterprises shared their practical experience in R & D quality and efficiency, and discussed with the audience how to take effective measures to ensure and improve software quality.

This salon review brings you a topic from Yang Zhou, a preacher of Tencent cloud coding——Devops code quality practice

Problem: more and more people, more and more chaotic code

With the increase of team members, everyone has different habits in indentation, newline, space and case, which leads to more and more chaotic code. The problem of code style is not fatal

  • Hard code: write various environment configurations, links and keys in the code, resulting in security risks
  • Magic Number: hard to understand and maintain
  • Too many lines of code: difficult to maintain, contrary to the object-oriented solid principle

Many large manufacturers in the industry have published code specifications and recommended that they adopt them directly, because their own invention specifications are often not comprehensive enough to convince the public.

Code specification is not just a matter of indentation and newline. By constraining cycle complexity, number of file lines and number of method lines, we can design in an object-oriented way.

How to enforce code specifications

With the code specification, how to implement it? It’s a problem for many teams. Lint program is used to check code specifications. 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 it needs to be configured by everyone. Some ides may not support it
  • Git commit hook: when submitting, the command line tool will be called to force the check. The advantage is that it is very timely, but there is a risk that it can be deleted
  • Server: after git push, it is very reliable to check on the server, but the disadvantage is that it is not real-time enough
    Therefore, it is recommended to use these three methods at the same time.

How to deal with it after code checking? There are thousands of nonstandard parts in the old project, which obviously can’t be cleaned up at one time. It’s unrealistic to let everyone stop the old project to clean up the old code, and the risk of changing too many files at one time is also very high. Therefore, it is recommended to use incremental checking, especially the Java incremental checking scheme, which is more complex and detailedIdentify the QR code in the figure below and read coding document

Server side inspection: continuous integration is recommended (continuously integrating code into the backbone to achieve built-in quality). The process is: lock the GIT trunk, everyone develops the function to pull the small branch, after the small branch is submitted, trigger the continuous integration to check the code specification, and then notify colleagues to review the code, so as to improve the code quality through this process. Coding continuous integration is compatible with Jenkins, and the graphical interface is easy to use. If the project is already in use, Jenkins can migrate smoothly.

The code is neat, but is the result correct?

Many projects end up in a dilemma – no one dares to change the old code. For example, developers will copy and modify existing functions such as get () to GET1 (), get2 (), which leads to the gradual decay of the project. The root cause is that no one knows if modifying the old code will lead to errors in other places.

In the team architecture of separation of development and testing, a responsible developer should test himself after writing the code, and then submit the test to the tester. However, in the later stage, people will gradually become impatient, from 10 situations to 5 situations, then to only one situation, and finally to no self-test at all. All the pressure is gradually transferred to the testers. Responsible development has gradually become irresponsible development, and the problem lies in the mechanism.

Foreign countries began this program more than ten years ago: testers transferred to programming development, and only a small part of manual testing was retained. Developers write their own test code, and merging is prohibited if the test coverage is not up to standard (such as 80%).

How do developers have confidence in their code? It doesn’t depend on intelligence, because people are always close to each other. Even top programmers may commit the most elementary problems. Therefore, writing test code by themselves is the most reliable solution. Test code covers a variety of boundary situations. Even if other people rewrite the code, they don’t need to worry about dying.

What is the latest time to start automated testing?

Automated testing is good, but it also faces difficulties: the business is too busy to write test code.

From the perspective of personal career development, the time of manual operation of postman self-test is used to write automatic test code. In this way, the level of self-test is improved, and the retest time is also saved when the code is changed later. It is no longer Piling business code all the time, and it is difficult to grow.

In the past, the quality of projects of large companies in China was generally very poor, because the first 20 years were the dividend period of 2C, and everyone was rapidly seizing the market. But now it’s time to defend the territory. In the past two years, large companies began to pay attention to the quality of code. It is suggested that everyone prepare for this opportunity.

From the perspective of the company, it mainly depends on the timing. For example, 2C project gradually matures, the number of users becomes larger, the online fault loss has been greater than the cost of recruiting developers, or with the gradual increase of project functions, the regression test time is getting longer and longer. If a website goes online many times a day, it is not practical to test all the functions of the whole website one day, so automatic testing can guarantee the continuous high online frequency. In the early stage of Tob project, serious bugs may have to compensate customers, so automated testing is needed.

Code quality rating standard: as can be seen from the figure below, the maximum circle complexity of “excellent” code quality standard is 5, the number of class lines cannot exceed 50, the number of function lines cannot exceed 10, and the test coverage rate needs to reach 90%. The partner of coding, UPF, provides CSD certification training, which can help developers reach the corresponding standards, recognize the QR code and learn more.

So that’s all for this sharing. You can share itGo to station BWatch the speech video and get the full PPT, orGo to codingLearn more.

Recommended Today

Libp2p RS version 0.3.0 introduction

V0.3.0 released on 4.23, usingAsyncRead & AsyncWriteTo replace ourReadEx & WriteEx & SplitEx; SimplifiedKad/DHTImplementation logic. modify ReadEx & WriteEx & SplitEx: At first we tried to useasync-traitTo define their own IO operationsTraitFor more pure useasync/awaitTo write code. withReadExFor example, it is roughly as follows: #[async_trait] pub trait ReadEx { async fn read(&mut self, buf: &mut […]