Embracing quality: Draft Plan to Improve the team's code Quality

Recently, we are committed to ensuring and improving product quality. The first thing we hope to solve is the code quality problem. The unrestricted program code is like a Pandora box. It will surprise people to connect after it is opened. Of course, what I feel is far better than happiness.

To improve code quality, we must first establish quality awareness.
Quality, functionality, and progress are three pillars of a software project/product, but in real projects, when quality conflicts with the other two, quality is often sacrificed. The team's attitude towards quality is mainly focused on verbal attention, which does not seem to have risen to the level of team consciousness and lacks necessary safeguard measures. But there is no quality function. From the first day of its release, it will start to be continuously repaired, and eventually go to the fate of being rewritten. Without quality progress, it can only be a hypocritical commitment, because the following comes, is the additional overhead of another round, and the effective progress is greatly delayed.

Training is required to cultivate the quality awareness of the team.
Make every code contributor understand what is good, what is poor, and how to make it better. We are going to use four forms of Irregular meetings for team training.

1. knowledge training
.
Select a range of teaching materials for the team. The teaching materials can be books, articles, and reading plans. After completing a phase of reading, specify some team members to organize training materials and exchange their reading experiences. This is theoretical education.

2. Code exchange meeting.

Some people call it the "Mountain View sword" in the team ". Team members can volunteer to give their own written or poorly written code for public explanation to share their experiences or ask others for improvement suggestions. It must be noted that the conclusion of this meeting should not be linked to employee evaluation, so as to create a good and open atmosphere for communication.

3. Personal press conference.

Before a module is developed and submitted to the testing department, the module owner will host an internal press conference and invite colleagues from other groups to participate. The functions of this meeting are diverse:
To ensure the quality of the module release, the owner will be more cautious about testing his work in order not to make an ugly appearance at the press conference.
Enhance the relationship between team members.
This helps members form an overall understanding of the product, reduce the feeling of blind people, and enhance the sense of belonging of the team.
Improve the coordination organization and public expression of the publisher.

4. Problem Analysis meeting.

The problem analysis has a certain degree of pertinence and warning effect, and the atmosphere is relatively serious. Find a frequently occurring issue in the Code, or have a greater impact, or have a typical quality issue for in-depth analysis.

With training, we also need to quantify the improvement of code quality. The following measures should be adopted in this regard:

1. unified tools.

Taking the CVS client as an example, the Team has three usage modes: Eclipse, eclipse + cvsnt, and cvsnt. There have been many version chaos or conflicts caused by copying files in different environments. The tools and usage modes in the team should be unified and best practice training should be given.

2. Use a better project to build the platform.

Replace the existing ant with Maven. This has been carefully researched and compared, and I have the opportunity to detail it in subsequent articles. Maven has the biggest advantage over ant. It looks at the problem from the management point of view with Maven, while ant is mainly used to automate repetitive work. So, I said, Maven is a platform and a set of specifications, while ant is just a tool.

3. Adopting the sonar code Quality Management Platform

To put it simply, sonar inherits from many well-known open-source static code analysis tools such as findingbugs, PMD, and checkstyle, and can generate detailed code analysis quality reports, and displayed on the web interface.
We hope to use the sonar platform to focus on the changes of major quality indicators, such as repeated code volume, comment ratio, Code complexity, and test coverage. My usage experience in this area will be detailed in my subsequent articles.

4. adhere to the Code review.

Code Review, which is the most common quality control method, I will not say more.

It looks good, but I know there is a long way to go. Quality problems require continuous improvement.