Thoughts on pairing programming

Pair programming technology is a very simple and intuitive concept, can achieve a multiplier effect of the work. But people-to-people cooperation is not a simple thing-especially when people are accustomed to working alone. The implementation of pair programming technology will bring benefits to the development of software projects, but these benefits must be carefully considered and planned to truly reflect. On the other hand, two experienced people may find that there is no skill transfer in pairing programming, but letting them solve the same problem at different levels of abstraction will allow them to find a solution faster and with fewer errors. Pair programming technology means that two programmers sit side-by-shoulder in front of the same computer to work on the same design, the same algorithm, the same piece of code, or the same set of tests. One person acts as an executive role and is programmed only. The other is responsible for the observer (or navigation), detecting bugs and controlling the overall design. Pair programming often takes about half the time to write higher-quality code compared to the two-bit programmers working independently of each other.

1. Before starting the task, maintain a good mindset that can be completed in two hours. For example/code to add "Operation History" to the truck database, which will be useful for you to work with later.

2. Do not aim too big each time: for example, can be done in a few minutes. Start by encouraging each other to be focused and make sure you are clear about the task at all times

3. Interdependence and support if you are a performer, when you complete a program as quickly as you can, you tend to overlook some problems, at which point the partner is the guarantee. If you are an observer, review each other's code carefully, consider possible errors, and how to simplify and improve the design. In the inability to read the time to find the bug, but do not immediately ask for deletion, but wait until the other party focused on programming, to a degree of overall control will be effective. For example, if you see that the current code does not consider an empty input, write on a sheet of paper, "Add 0 input to the unit test." "Observers and performers are flexible, rather than mechanically completing tasks. Observers do not need to study small details, but consider a higher level. For example, "looks good, but how do I handle a situation where a null pointer is encountered?" "It sounds better than," now enter ' if (S = = NULL) {return ... "" much better. "

4. Indeed, much has been said, and the most important thing to do is to study better ways to solve problems and improve efficiency. Including the code may not involve key input, make the displayed variables and subroutines clearer, reduce the complexity of implementing code, and always remind the other API, of course, listening is also necessary. When the two partners are very tacit, they will discuss it quickly and again. Here are some common conversations: "Do you think this is a valid test?" "Does this look right?" "What's the next step?" "Believe Me" (how easy it is to negotiate).

5. Keep the unison of the two sides and work together inevitably, it is unavoidable that there is no certainty as to the extent to which the other party is going. When the above phenomenon occurs, the positive response is possible. The best way to do this is to coordinate with each other for a short time to determine if it's synchronized, and if it takes 5 minutes or more, it's no different than working alone. It is best to work clearly before you do. For example, ask the other side, "want us to write tests for empty cases" of course, it will also be passive work, then can explain for example: "Need to input, but do not know whether it is feasible", etc., it is best to maintain such a long period of exploration spirit. Everyone knows that one-time recognition is easier than constant interpretation, but in order to ensure the quality of work, code rework is actually quite normal.       No matter who master the macro direction, who is responsible for the details, the most important thing is to cooperate with the efficient completion of work. 6. Take the time to celebrate the difficulties and complete the task.       For example, a high-fives test passed, when the new test failed to still high-fives Mingzhi, is to enter the realm of collaborative programming and test-driven design. 7. Convert roles at least every half-hour, and fully invest and adapt to different levels of work. In addition, because the performer's work is complicated and needs to be wary of conversion roles, it is not possible to perform the job, so switching roles helps improve capabilities.

My pair programming small partner is Wang Rui, she has a sense of humor, for programming, coding, she will not be impatient, will not say is very boring, will be happy in coding, when the code encountered problems, she will be very assertive, will not conflict, most importantly, she is particularly willing to listen to the views of the people, Two individuals will have the amount of business to carry out.

Thoughts on pairing programming