The Most Neglected Practice in Extreme Programming

In the article "Why Do We Have to Do Extreme Programming?", I talked to you about the importance of extreme programming. Today, I want to talk to you about the simplest but often most overlooked practice in extreme programming - coding specifications.

When it comes to coding specifications, every developer is very familiar with them, and every team has its coding specifications. But what about the actual implementation? It is estimated that most teams have no coding specification; the coding specification is just a document stored in the document library.

Why is it difficult to implement coding specifications? I think everyone has neglected the importance of coding specifications. Coding specifications are the basis of a series of practices in extreme programming. Conscientious implementation of coding specifications can be said to be the practice with the highest return on investment in extreme programming.

First of all, the coding specification is the basis of the collective ownership of the code. As you can imagine, during the Spring and Autumn and Warring States period, each vassal state had its script, and the cost of communication was relatively high, while Qin Shi Huang unified the six states and quickly unified the script, which was conducive to the dissemination and development of decrees and culture. When it comes to programming, it is the same thing. If everyone inside a team has a different coding style and feels uncomfortable about looking at someone else's code, there is no way to achieve collective ownership of the code. Only with a unified coding specification is it possible to achieve true collective ownership of the code.

Secondly, only by achieving a unified coding specification can pair programming be implemented. Pair programming is a good extreme programming practice. Through two-person pair programming, high-quality code can be efficiently produced. But a prerequisite for pair programming is that at least two people write code in the same style. If one person writes code according to the hump specification, and one person writes code according to the underscore specification, it is estimated that they will fight when they write.

To sum up, coding specifications are the premise of collective code ownership and pair programming. Code collective ownership and pair programming can better help implement subsequent practices, such as continuous integration, test-driven development, etc. And only when collective ownership is truly achieved is it possible to promote the inheritance of knowledge in the team, reduce the risk of the team, and create conditions for the rotation of posts within the team.

Since coding specifications are so important, why are they often ignored in implementation? I think it can be analyzed from both the team and individual perspectives.

From a team perspective, many teams assign work according to modules. For example, among the clients of Zen Tao project management software I have contacted, many are assigned this way. For example, Zhang San is responsible for module A, and Li Si is responsible for module B.

There is no cross-communication between Zhang San and Li Si. If you do not carefully abide by the coding specifications shared by the team, each will inevitably have its style. Then this allocation by module also violates this practice of collective ownership. It will cause problems such as rebuilding wheels, code redundancy, single point of risk, etc. This distribution by a module should be broken down so that everyone can participate in the development of each module.

From another perspective of the team, there is often a lack of a strong facilitator. Executing coding specifications requires correcting other people's code, which will inevitably offend others. Therefore, whether there is a strong facilitator in the team plays a crucial role in the implementation of coding specifications. It is recommended that a backbone R & D personnel with a strong sense of responsibility be selected in the team to promote coding standards and lead by example. The effect will be better.

From a personal point of view, many developers feel that they have strong abilities, as long as they can ensure that the code they write can be executed, which is very personalized. This is not professional enough. You can look at the code of Google or Microsoft programmers circulating on the Internet. They all strictly follow the unified coding specification and write code seriously. The code is written for others to see, so we must find a way to write the code.

So whether from a team or an individual perspective, following coding specifications carefully can bring many benefits. Finally, we would like to share our team's coding specification practice.

The first is to simplify the rules when developing coding specifications. The more rules there are, the less easy it is to remember and the more likely it is that accidents will occur. We only have a camel-case naming format. All naming formats follow the camel-case as a rule from the database to the program to the page. I understand that some teams will have more naming formats, such as class names will be capitalized, and database field names will be spaced with underscores, which is unnecessary, simpler, and easier to follow.

Secondly, we will pay more attention to coming up with a good name. From the database name to the table name, to the field name, to the class name, attribute name, method name, parameter, return value in the program, to the input and output parameters in the interface, and then to the elements and styles in the page, we must spend more time thinking about a name that can be explained by ourselves. Some friends may say, and there are notes. But instead of writing notes to explain what the name means, why not make some effort to let it explain itself?

In addition, we also emphasize the management of code fragments**. For today's languages, the smallest management unit is the method-function level. Implementing functions and methods is composed of lines of code, which can be flexibly organized into code fragments using comments, blank lines, alignment, etc. This way, when reading the code, it is easy to figure out the macrostructure and logic of the function and method, and it can be easier to locate the problem. We can imagine how painful it would be to read a function with 50 lines of code without any blank lines.

We also align everyone's coding practices through regular group code reviews. Every two weeks, we take time to get everyone together and look at the code in a unified way. File by file, we review the specification issues, naming issues, logic issues, layout issues, implementation issues, efficiency issues, security issues, etc. In this way, we can effectively ensure the implementation of the specification in the team.

Finally, in addition to referring to the coding specifications of our Zen Tao team, I recommend the book " The Art of Readable Code." There are many specifications and skills about programming in the book. For teams, you can refer to the specifications to formulate team coding specifications, improve team code quality, and implement extreme programming practices; for individuals, it is conducive to improving code legibility and achieving internal and external cultivation. Become an excellent programmer. Both teams and individuals can benefit greatly from it, which is highly recommended!