Practical experience of pair programming

Pair programming （ English ：Pair programming） Is an agile software development approach , Two programmers work together on a computer . One person enters the code , And the other person reviews every line of code he enters . The person who enters the code is called the driver , The person who reviews the code is called an observer （ Or navigator ）. Two programmers often switch roles .—— Derived from Pair programming - Baidu Encyclopedia

Practical background

Most of them are for research and development to improve efficiency , Put forward a package of work plan , Recently, pair programming is going to be implemented , It is applicable to all front and rear students in the Department .

I have heard of this way before , Experienced companies have no specific practice , Now let's practice .

The benefits of pair programming

1、 Project perspective , The mass shifts to the left

From the perspective of the project , Improve the product quality . Two people interact check. Usually, personal ideas inevitably have limitations , Looking at the code you write, you always feel that everything is right . And by pairing , The code has been reviewed by at least one programmer , This allows the design to 、 Testing and coding are more friendly , Reduced defects , So as to improve the product quality .

2、 Personal perspective , Personal ability improvement

review Can learn from each other , The blind spots of knowledge complement each other , There is also mutual learning of logical thinking

3、 Team perspective , People interact buckup, The relationship between members is more harmonious

Personnel backup each other , Increase communication and trust among members

Pairing

1、 Pairing in the team

Fixed personnel , Irregular rotation later

2、 Fixed time, fixed frequency , Do the following 4 thing ：

①、 Story description
②、 Design thinking
③、CodeReview
④、 Review of test problems

3、 During the above implementation , All the problems arising , Record in a fixed position 【 Pairing documentation 】

Pairing is recorded , There is a summary

Time and frequency

1、 specific time ：

We are now implementing agile development , The specific time is for each sprint 【 Tuesday of the first week — Thursday of the last week 】

2、 The frequency of ：

Every afternoon 5:00

Others and precautions

1、 Suggested time for the whole process ：15-30 minute
2、 In the whole process of pairing, everyone upholds mutual respect 、 The mentality of learning from each other
3、 Pairing discussions must revolve around the story itself , Don't spread the discussion

---

The above is the plan and vision of the leaders when they publicize and implement , It can be seen that , We did not highlight the concept of pilots and pilots , Or it can be understood that every R & D is for the driver + pilot , Or simply understand , We are actually two code review + Review of problems

At present, we have implemented it for nearly a month , Simply do a practice review

Our specific practice

• Landing execution
  The back-end students of our project are paired , Because our front-end team is 3 personal , So we are programming in pairs with three people

• Specific implementation
  We spend every afternoon 5 spot , Next to a colleague's computer , Show the stories you did today one by one 、 Code , And some problems encountered by myself + reflection , Then the other two people come review

See other groups , It's almost pairing in this form

Pairing documentation

In pairs	Pairing time	Sprint story	Question type	Problem description	Optimization measures / Matters to be followed up
Zhang San 、 Li Si	2022.07.04	https://jira.net/123	demand / Design / code / standard	Promise.reject Deal with logical redundancy	Optimize Promise.reject Logical processing
Zhang San 、 Li Si	2022.07.05	https://jira.net/123	Design	The parameter logic of the general pop-up component is unclear , Interface request confusion	Pull the interface request from the pop-up interface , Component reception Promise Request as a parameter , The specific interface request is controlled by the outer business component
Zhang San 、 Li Si	2022.07.06	https://jira.net/123	code	No problems found	nothing
……

Some problems or special situations encountered

• There will be some delay coding Time for
  After all, do it at a fixed time every day review, And we are three people , Usually we will finish pairing in about half an hour , In this case , Half an hour less coding, And the interruption of thinking in time

• Complex modules backup, It is difficult to do it in a short time
  Some very complex modules , Now I'm doing patchwork , In this case , Close to daily pair programming , To understand the overall module , It's not enough.

• Not that day review What if something goes wrong ？
  That doesn't need to be dealt with , We write code every day , Sometimes I write less , Or the logic is clear , In this case, there is no need to review have a problem , But the pairing record is still recorded , As in the last row of the table above

Experience receipt

Before, we have done several internal code review, Because there are many people involved , The meeting is relatively long , And the students who are going to talk , You need to prepare the content in advance

Now this way of pair programming , It's a code review Routine 、 Fragmented , You don't need to be prepared to devote a whole block of time to doing code review

Now the biggest gain for us , yes Technical point + The collision of programming thinking , It's not necessarily who persuaded who , We took this opportunity to exchange more technology

What matters is persistence , Pair programming is a matter of long-term persistence to see results , We will review it after we persist in specific practice for a period of time , The harvest will be more