Live XP: (8) miscellaneous
Lin Xing (reprinted from www-900.ibm.com) October 27, 2003
XP also has other excellent practices. This article discusses the other three practices of XP and study how to use them flexibly in the project. Code collective ownership
XP advocates that the code home collective, this reason is that everyone can modify the code, not waiting for others to modify the code. This approach can effectively avoid the gap between code. But the collective code ownership is also its problem.
We tried the practice of sharing code by multiplayers, with the purpose of strengthening communication, avoiding a case of only one code to know. This method is working very well, but soon we found a lot of problems, the definition of the class became unclear, some classes became bloated, we smelled the taste of "Large Class". It is even more bad that these classes and reconstruction are quite difficult because they have too much customers. It is because these classes are widely used, so everyone has modified and expanded, resulting in chaos of the code. So, we have increased the effort to review and reconstruct these classes, but new problems have emerged, it is difficult to find a balance point, which can keep the team's agility and guarantee the height of the class. Availability. Worse, different people have different understandings and expectations in these classes, resulting in these types of design styles.
In this article, we are not only emphasized, and all practices in XP are used in conjunction. The ownership of the collective code in the project is not not good, but there is a premise. In the above example, we made at least a few mistakes:
There is no tacit understanding between team members. Only the level of knowledge between team members is similar, or have similar thinking, for example familiar with object-oriented, familiar with design patterns. This can only assume the quality of the code together. In the project, we tried a new approach to narrowing the range of collective ownership to group, which consists of three to four senior developers, called a core group, responsible for building a foundation framework. This group uses an efficient shared code mechanism. Other developers use the results of the core group to work, they do not modify the core code, but can provide amendments. Ignore the quality of code. Different people modifying the code is more likely to decline in code quality than single modification code. This cost must be considered and find out the quality of recovery code quality. The review is a very effective means that the FDD (Feature Driven Development feature driver development) method emphasizes the role of review in the project. As long as the cost can accept, more review is not too much. Code standardization. The code standardization mentioned here is not only code specification. It also includes code whether or not the code is readable, whether the structure of the code is sufficiently clear. These can lead to form a chaotic when the team is collectively owned by the code. In addition, it should also be noted that the collective code requires frequent integrated code. The code must be quickly synchronized and integrated, and shared code often means that the same package, the same class may be modified simultaneously. This greatly increases the possibility of introducing bugs. It is necessary to make a synchronous code as soon as possible.
If a software organization does not solve these problems, it is dangerous to use collective code ownership. Instead, consider using personal code ownership or micro team code ownership. The former said that the individual is responsible for the individual's code, the latter is said that two to four people are responsible for some of the code.
Whether it is ownership of personal code or the micro team code ownership, its foothold is a clear developer responsible for the code, he guarantees the unified design idea and style of the code, responsible for the client interface, responsible for maintaining and improving the code, responsible for code Related documents, responsible for explaining the operational mechanism of the code. Personal code ownership is the clearest approach, but its disadvantages and collective ownership is just the opposite. A person's code may cause the bottleneck of progress, and anyone will leave the team will cause loss. Personal code ownership is easy to understand, but the micro team code ownership needs special explanation. His organizational ideas are very similar to our organization's organizational style advocated in programming:
Different people are responsible for different codes, and there is a cross between personnel. Such organizers are flexible, and the programming is the same as the work of the programming.
Continuous integration
In the document of the continuous integration of Martin Fowler (the Chinese translation of this article can be found on the Agilechina website), there is such a description of the continuous inheritance:
There are a variety of "best practices" in the field of software development, and they are often talked, but there seems to be rarely realized. These practices are the most basic, most valuable is: all have a fully automated creation, testing process, allowing the development team to create their software multiple times a day? Quot; Day creation "is also a view that people often discuss, McConnell in him "Fast Software Development" will be created as a best practice, and it is also a developing method that Microsoft is famous. However, we support XP community view: Day creation is just the lowest requirements. A complete requirement. The process of automation allows you to do multiple creation multiple times a day, which can be done and it is entirely worth it.
As with other practices mentioned herein, the main idea of continuous integration is to inherit the software of the software process to the entire process of software. Although there is no way to judge the cost of two duration, continuous integration can get a lot of additional benefits. The most integrated place for a single integration is the process of bugs, especially those hidden, and people feel that there is no bug. If the write code is a kind of enjoyment, the process of repairing the bug is definitely a torment. Time spent in this process is sometimes amazing, worse, this part of the time is not estimated, which makes the project manager headache. The response to the encoder inquiry will always be "a little bit".
Continuous integration avoids this embarrassing situation, due to the short time, the problems in the integration can be easily discovered. Even if you don't locate an error, the worst case can also be integrated into the software. In this way, the quality of the software will be relatively high. In addition, another important task of continuous integration is to run automation tests, ensuring that all code is tested, and there is no problem. The test here is derived from unit testing, in this article, you can find a more detailed discussion. For some teams that have not continuously integrated experience, the continuous integration is a very high cake of a hanging, but it can't see it. It is not easy to do continuous inheritance, but we can use the continuous integration of ideas to approach the continuous integration goals.
The best practice for continuous integration is the construction and testing of automation. This requires that the software organization has a good configuration management mechanism, as well as the rich test script to write experience. For a corporate application (sorry, I only have this experience), software design includes many factors, and it is not an easy thing to take these factors in the process of continuous integration. Therefore, many organizations may lack these two factors, but there is no relationship, we can use semi-manual way to complete continuous integration, then slowly integrate process automation. Here is a semi-automatic continuous integration idea and improvement process. The first is to define duties. If you use code non-collective ownership, then specify each class or package (for process language is a function and module), responsible team (or individual). Similarly, you also need the person in charge of the specified database mode. There may be a crossed place between these codes, but there is no relationship, just guarantee communication, a small amount of cross-duty is not particular. It is best to specify a person who is responsible for continuous integration, allowing the different people in the project to alternately serve as the responsibility. Secondly, the automation code is defined. All tests must be written in the form of test code and can run. All database mode definitions must also be written as DDL, not using database tools. Don't steal this lazy. The general principle is that you can write a code, only the code is available. I admit that the workload is very big, but this is necessary.
Once again, it is defined in the integrated frequency. Frequency development depends on the mass and communication quality of the team. For a small team, an integration of an hour is also possible. For large projects, you can divide the sub-teams, and the sub-teams are frequently integrated (one hour), and the sub-team is integrated (once every day). With the integration guarantee of the sub-team, the integration of the entire team generally does not have any problems.
Next is the use of tools. The most needed is that version control tools can be used, such as ClearCase. You can also choose from, for example, SourceSafe, you can also use free (CVS). There is no relationship, the key is whether it is suitable. The integration of code and documentation passes this tool, and the database is integrated through the database administrator (that is, the first step specified by the person responsible for database mode). The integrated person in charge is responsible for coordinating the integrated process to ensure the success of integration.
Finally, there is a problem, this is just a beginning, you will have a variety of problems in the process of integration. For example, integrated time, data correlation, design coupling degree, and changes in test code. There is no relationship, there is an adaptive process here. At the beginning, the continuous integration process must be wrong, slowly will stabilize, this is an improvement time, the main goal of improvement is always automation. Sometimes, in order to ensure the quality of integration, we ask for a wrong person, please eat ice cream, don't laugh, this is part of the process, this is a very effective, everyone will seriously guarantee the test before submitting the code. .
Code standard
The code standard is a very basic management common sense. But we don't intend to add a problem with the code standard. We will focus on discussing the development standards. Development standards include a wide variety of standards. For example, the logo of the process, the standard, standard model of design model, code style standard, variable naming standard, case case standard, etc. In XP, it is actually not very emphasized, because XP advocates simple practices, but sometimes standards are often violating this norm because it will bring additional standardization costs. The reason why the weight level method is cumbersome, and it is a major reason.
But in the actual process, I think I would rather invest more resources in the implementation of the standard. This is related to the actual situation in China's current software development. After the lightweight method of abroad, most of the programmers have experienced mandatory standardization. But China is different, although the lightweight method is very good, but understands or improper execution, it often leads to the consequences of the painting tiger. The development process of many software organizations in China is still in a state of disorder, and developers also have a fresh experience in the standard process. In such cases, blind advocacy is practical, in fact, in fact, there is still a chaotic state. Therefore, standard development and implementation is always worthwhile, although there will be a certain cost, but this cost is also the benefit of the improvement to promote accumulation, etc.
But the standard development is definitely not to specify the time of the toilet on the toilet, how to maintain the standard balance is the focus of agile methods. XP believes that the code specification is enough. But I think there are at least several criteria that need to be paid:
Document Standard: This is a big topic, the best document standard is UML. A picture is better than a thousand words. UML will become more and more powerful after UML2.0. Therefore, it is necessary to use UML instead of the document. There are a lot of information about UML, and there is not much discussion here, but there is an advice about UML is that do not try to use the UML all types of diagrams at the beginning, do not use UML all features. This approach, and the characteristics of the words processor, there is no difference with the practice of non-writing documents.
Design standard: It is also a big topic. Design standards include how to design, how to represent design, how to design architectures, how to design all levels, etc. Implementing the design standard in an organization is a long-term process. But it is still that sentence, it is always better than not doing.
Code Standard: XP is very readily readable, and the code readability represents the level of programmers, and the designer's efforts. Best practices in improving code readability are reconstruction and review, and these two practices have detailed discussions in other locations herein.
Interface standard: Interface standard is sometimes only a small problem, but for modern software, the interface is playing more and more important roles. In the field of soft workers, the key to excellent interface is consistency. The same buttons must have the same size, position, and font. It is very important to develop a interface standard. How to develop standards: The standard development does not require a lot of explanation documentation, these documents are difficult to understand, and how many people will see, even if they see it, they may not understand. It can only be wasted. The best way is examples and training. Description of the documentation is written in a document example and a short description. Re-adjusted with face-to-face explanation, its effect is far more than the documentation.
