Pair Programming implementation

Pair programming is a very simple and intuitive concept: the two programmers sit side by side in front of the same computer to complete the same design. The same algorithm, the same code, or the same group of tests are compared to the independent work of the two programmers. pair programming usually takes about half of the time to compile code with higher quality. However, collaboration between people is not a simple task-especially when people are used to working alone, implementing Pair programming technology will bring benefits to the development of software projects. these benefits can only be truly reflected through careful thinking and planning. On the other hand, two experienced people may find that there is no skill transfer in Pair programming, but asking them to solve the same problem at different abstraction levels will allow them to find a solution faster, and fewer errors.

Pair programming has the following advantages:

1. direct and continuous code review.

2. Work with others will increase responsibility and discipline.

3. understand a problem at the same time.

4. It is much harder to get lazy when someone is staring at it!

The two programmers have very little possibility of having the same disadvantages and blind spots, so we will get a powerful solution when we adopt Pair programming. This solution is precisely not available in other software engineering methodologies.

In our usual programming, if you encounter a very difficult problem (difficult to get bored with the project), you will certainly want to seek help, whether it's from an Internet network with a large amount of information or from the technical masters around you, you will fight for it (on the premise that you have a strong passion for computer knowledge ). In this case, you may want to use Pair programming. If you don't say anything else, you may feel different.

Advantages of Pair Programming

In fact, Pair programming is very simple and interesting to sit up, find a programmer with a low level of difference and match with yourself. Only one computer is used. You can choose one person to sit in front of the keyboard for input, and the other person to sit behind and dictate. The frequency of communication between two people should not be less than once a minute. The whole design idea is dominated by people who only need to speak and do not do it, but by people who operate on the keyboard. Because human thinking is faster than entering code. Then, viewers can have free time to think about the code and check whether the code is written or the structure is correct.

If the programmer's experience is sufficient, it is easy to see the code that has potential problems, that is, the functional implementation is actually a bad practice. This is known as the bad taste of code in xp. It is detailed in Martin Fowler's refactoring book. When two experienced programmers work together, it seems like a waste of time: but in fact, the results have indeed completed higher quality code. Programming is less prone to bugs, and the code page is more elegant and compact.

Some new benefits have been found in Pair programming. First of all, it can promote the improvement of the programmers involved in the project. When a programmer works, the low-level party will be influenced by the slightly higher-level programmers and learn something new. The high-level party has also sorted out their own ideas by constantly speaking out their own ideas.

Second, a certain period of time to disrupt the matching, so that participants in the project switch their positions, making the maintenance of complex documents less important. After group disruption, verbal communication easily familiarized everyone with each module. This is also good for the company. If someone leaves the project, it will not affect the entire project. Finally, the development process becomes more interesting. There is a lot of communication between anyone, and the relationship between everyone is more harmonious.

In addition, I would like to add that I have not mentioned any books on XP, But there is actually one point: Pair Programming forces programmers to improve their work efficiency. If you work independently, when you encounter difficulties, not everyone will immediately actively solve the problem. In this case, you may be able to chat with netizens online and check out irrelevant websites. The interruption of work may result in a waste of time. It seems that programmers work overtime every day, and the actual working hours are usually less than six hours. Pair programming has a mutual supervision function. The fatigue status on one side is not good, and the other side will encourage and inspire fighting spirit.

In addition, when two people share a computer, chat activities of a slightly private nature will consciously not proceed. As a result, programmers in the new experiment paired with programming would be tired, and it would be strange to have been nervous for 8 hours without tired work.

From this perspective, it is reasonable to strictly restrict Pair Programming programmers from working overtime. In fact, they do not have to work 8 hours a day at first, working for six hours every day is also very efficient.

　　When two people change roles constantly, no one can remember which line of code is typed. The cyclic grouping in the team makes it hard to tell who is responsible for the module; on the contrary, everyone feels good. The code of the entire project is shared by the Team, rather than individual works.

Variant

　　Remote Pair Programming

Remote Pair programming, also known as virtual Pair programming or distributed Pair programming, means that two programmers are not in the same location and share the desktop through the Collaborative editor, or remote Pair Programming ide plug-in Pair programming. Remote programming introduces some difficulties that do not exist in face-to-face Pair programming, such as extra latency of collaboration and more dependent on "heavyweight" Task tracking tools, instead of "lightweight" index cards, as well as chaos and conflicts with questions like who "controls the keyboard" that are not caused by verbal communication.

Many tools, such as Eclipse, have plug-ins that support remote pairing. Some teams try to use VNC and RealVNC, and each programmer uses their own computer. Others use the text-based GNU screen multi-display mode. Apple's Mac OS X contains built-in screen sharing applications.

　　Ping-pong Pair Programming

In ping-pong Pair programming, the observer writes failed test cases, the driver modifies the code to use the cases, the observer writes new unit test cases, and so on. This loop continues until the observer cannot write a failed test case. However, this method takes more time than the estimated plan.