Live XP: (6) Strengthen communication
Lin Xing (reprinted from www-900.ibm.com) October 27, 2003
Conclusion Programming is the last topic discussed in this series and a subject of controversial. Why is a person's work to be completed, this is a crime for the boss. Similar to the topic of the previous, we have to learn and apply a practice, and the key is to grasp the substance. Communication is one of the most important factors for the success of a project. A project may not have a formal software process, but as long as team members can conduct effective communication, the probability of success is very large, but if there is a lack of effective communication channels in the project, it is excellent, and the rigorous software process is not use. Excellent software methodology, always in the establishment of communication channels, driving a lot of effort to effectively communicate. We analyze RUP, XP, etc., and we will see a lot of such practices. Communication is important for a project, more important for a software organization. In the long run, there is a good development that can be developed in an effective communication, but in turn, there will be a lot of problems in the internal communication.
A big problem in the software development process is the problem of communication. In fact, this problem is not only existed in a development process, and the long-term existence of the entire software organization and has become a major obstacle to hindering software organization development. This kind of saying may be too theoretical, but we only want to think that if a main programmer leaves, if a main programmer leaves, it will understand the meaning of this paragraph, and even organize a significant impact. The main problem caused by this phenomenon is that the program is dispersed in various programmers. Each code block is like a private property of programmers, and sacred cannot infringe.
More bad, any programmer is unwilling to read the code of others, compared to understanding the code of others, the programmer would rather rewrite the code, which leads to another serious problem - most of the work in the software organization They are repeated, so that programmers are busy with development code every day, but it is difficult to put energy in more valuable places (about what is more valuable, we will explain in detail below).
In some projects, we often see such a development environment: Each programmer has a personal separation space, and there is no communication between each other, and sometimes it doesn't say a word all day. After communicating with a main programmer in the project, we found their true thoughts:
The project is very nervous, the relationship between team members is very subtle, the main programmer must maintain its own main position, for them, we must work hard to write outstanding code, and you also need to take the pressure of the project, and Beware of other programmers. Master the program is the source of your own safety in your hand. The pressure is so big, they have to work more than 12 hours a day. Program development is like a nightmare.
Although not necessarily all teams are so bad, there are more or less have some bad environmental factors. It is certain that there is not much person to work in such a development environment. These environmental factors affect the formation of communication problems.
One of the four major values of XP is communication. The communication range in XP has a wide range of communication between developers and customers (we also mention communication issues in the chapter of the needs and story), communication between programmers and designers, programmers and testers Communication between. However, this paper focuses on the internal development team, namely, how to improve the communication quality of the development team.
Improved Practice - Ending the programming XP methodology highly emphasizes to create a relaxed development atmosphere, and emphasizes the value of the value of the people. Communication is a major value of XP. A large number of practices in XP is designed around this values. For example, user story, on-site customer, code collective ownership, etc., but we must emphasize here, it is a pair of programming. This article does not introduce the programming, there are many information in this area, and there is no need to waste the pen ink here. This article is discussed, which is how we consider the programming in the perspective of the project. Ending programming is a very effective way to improve communication. A pair of programmers is the most basic communication unit in the collaboration process. In a classic XP method, the programming is the two programmers at the same time, before, the same machine, active common solutions. Perhaps the first reaction of the manager heard this sentence is: "This is impossible, I spent twice the money, but I only make a person's thing!" The efficiency is not only reflected in progress, but also in code quality, as well as project risk.
Individual programming individual programming often encounters a variety of problems. In software development, writing code often only accounts for a small part of the construction process, and many time spent in debugging code, improving the code structure, and modifying the code for demand or design. Many people have to have such experiences, in some key technical issues, and single-person research not only cost time, but it is easy to lead to morale.
At othertions, programmers often need to trade out between different design seals, and a person who has made technical decisions often causes the inner disappointment. At this time, I hope that there is another companion to support you to make a decision.
It is said that the code is the most stringent workpiece is wrong. Any minor mistake, such as lack of semicolons, will cause an error in the program. Although the compiler can check most of the mistakes, there will still be some small mistakes that are hidden, when they come out. A person's eyes are often easier to miss some errors, but two people are coding at the same time, and this error will be greatly reduced.
In order to correct the debugging of code defects, the debugging work tend to occupy a lot of people. If the code defects have been found in the hands of the test team, the cost of modifying the defect will be high, and if the code defect has continued until the customer has been discovered, This price is even more amazing. The number of defects can be reduced by pairing developers. According to some data, the pairing programming can reduce the number of defects by 15%. It is also worthwhile to adopt a pairing program relative to the high cost of correcting defects in the software process.
The above discussion is some of the problems encountered in personal programming, which is a small problem, but will affect the mood of developers. In a team environment, these issues will expand and upgrade to team issues.
Team Programming Although software organizations specify software coding specifications, coding specifications are impossible to agre, excessive coding specifications do not have operability. Therefore, the code written by the different people is still very different, the excellent code and the poor code exist at the same time. Everyone is familiar with their code, but it is not willing to touch the code of others. A variety of style code gradually produces the chaos of the code. This will have a lot of problems. First, the goal of the internal multiplexing of the software organization is difficult to implement. If everyone is not willing to see someone else's code, how do you build an internal multiplexed framework? The existing code cannot be controlled, the maintenance cost of the old project is constantly rising, and the team accumulation has also become an empty talk.
Second, the difficulty of code review is increased. The code review is a very important job, but the chaos of the code will increase the difficulty of code review, because the members of the review team have to spend time to understand the style of the code, and make guidance. Worse, members of the code review team are often important members in software organizations, and their time represents high cost. Perhaps no one has carefully calculated such a cost, but these costs accumulate, and it will be a surprising number. Again, project risks and organizational risks increase. This is especially preferred in software development organizations in project development as a settlement unit, and the project source code is difficult to maintain due to the leaving of the project developers. For projects that have been completed, this has increased project maintenance costs. For projects that have not been completed, this will disrupt existing project progress, leading to the delay of project progress.
Finally, it is also a fatal problem, and internal communication is difficult to carry out. Software development is not a separate activity. The team of excellent programmers is not necessarily a good team. For the reason, most of them are caused by non-communication. The knowledge inside the organization is difficult to form flow, and there is difficult to share knowledge between developers, and new members cannot learn from experienced old employees.
Communication is ultimately increasingly increasing the problem of forming the organization software design average. Software design is mentally labor, but personal knowledge coverage is limited, and personal design is often defective, and the cost of employed masters developers is quite high, not all software organizations can Have a lot of outstanding talents like IBM or Microsoft. Therefore, in the face of limited human resources (quantity and quality), the key issue is how to make the greatest role in limited resources.
After the software process participated in the code review of a software organization, I joined the content of this section. Since it is a process, it is of course some very subtle links, such as browsing a collection of writing, classes, and methods of classes, rules of comments, and more. These are part of the programmer's own cultivation, but many organizations are just problems in this link. The arbitrariness of encoding has led to a decline in code understandability, setting an obstacle for team sharing code, and no one will take the initiative to see other people's code. In the front, we say that the chaos of the code will lead to the difficulties of review, and another impact of code confusion is simultaneously, that is, the average software process level of the software organization cannot be improved. Although each programmer wants to write a beautiful code, it requires certain perseverance and time to write a beautiful code, especially when the project time is high, the quality of the code is often ignored. However, forced code of code is not easy to achieve, and the cost of supervising is difficult to satisfactorily.
Conclusion Programming can ease this problem from the structure structure. Most of the programmer is proud. If there is a companion, the programmer can can't pull the face to write ugly code. This is very interesting, but it is quite effective. The programmer can promote each other and improve the level of programming process. Although software processes are solved by some tiny problems, it is these problems that eventually affect the quality of the software. From the perspective of code management, the basic tasks of management are these "small problems".
Process guarantees that the programming can ensure that the cost is minimal while effective, this is the reason why the programming is programmed rather than the three-person programming. The best solution for single-point failure is dual backup during the operation of the hardware device. This idea uses the foundation of the programming. We have seen a software organization to implement the title of programming is to ensure the safety of the product, and at least two heads are equipped on all important components of the product. At first they didn't realize that they took the first step towards the program, and then they found this method very effective and expanded to this method, forming a complete pairing programming system.
In traditional software development, several check points are generally created during software. At this point, all parts of the software need to check, design whether or not, whether to meet the requirements, whether there is existence in the program defect. But the time spent on each Check Point is often terrible. Each CP costs are covered by: familiar with others' design ideas and code style to integrate different systems to improve defects, and practical practices in programming are actually spreading this part of the cost to everyone. Through two and two mutual match, let all people in the organization can be familiar with the various parts of the software. This cost is indeed higher at the beginning, but with the deeper's dedication, this cost will slowly decrease. According to the information, the relationship between the program is not like most people, it will increase 100% cost, which depends on the specific implementation form, but will never be 100%.
