20 Jan, 2021
Lập trình cặp đôi
Một trong những thực hành tốt nhất trong lập trình cực đoan (XP) là lập trình cặp đôi.
Khái niệm này là đơn giản: “Hai người tốt hơn một người” cho nên bằng việc có hai người phát triển tích cực xây dựng mã sẽ có kết quả phần mềm chất lượng tốt hơn. Với XP, mọi mã đều phải được thực hiện bằng lập trình cặp đôi. Tuy nhiên, không phải là một người viết mã và người kia chỉ theo dõi mà cả hai cùng đổi lượt viết mã vài lần mỗi ngày. Khi người này viết mã, người kia nghĩ về cách kiểm thử nó và cách tích hợp mã vào phần mềm đã được đưa ra trước đây để đảm bảo chất lượng tối đa và lỗi tối thiểu.
Sau khi làm việc cùng nhau như một cặp trong vài ngày, những người phát triển phải hoán chuyển sang cặp khác để cho họ có cơ hội làm việc trên các chức năng khác nhau của phần mềm. Khi họ hoán chuyển sang cặp khác, họ phải học những điều mới, cuối cùng họ sẽ hiểu toàn thể hệ thống thay vì chỉ vài chức năng. Để những người phát triển làm việc trên mọi phần của hệ thóng cũng sẽ làm phơi ra vấn đề ẩn kín cho nên nó có thể được sửa nhanh chóng và hiệu quả. Làm việc theo cặp buộc người phát triển phải viết ra mã tốt hơn, cẩn thận hơn về điều họ làm (bởi vì ai đó đang theo dõi), tuân theo qui trình chuẩn (đối tác của bạn cũng làm việc như SQA) và cuối cùng những người phát triển sẽ học về làm việc như một tổ. Dự án có thể có lợi từ việc ít phụ thuộc vào vài người phát triển then chốt và công việc sẽ lan toả nhiều hơn ngay cả giữa các thành viên tổ.
Tuy nhiên, nhiều người quản lí dự án KHÔNG thích lập trình cặp đôi. Họ tin rằng để hai người phát triển ngồi cạnh nhau là phí thời gian. Khi tôi dạy XP cho người quản lí dự án, tôi bao giờ cũng giải thích ích lợi của lập trình cặp đôi như thực hiện kiểm điểm mã liên tục. Không có nó, dự án sẽ cần có giám định mã thêm, kiểm điểm tuân thủ qui trình SQA thêm, và kiểm điểm chính thức thêm. Tất cả những hoạt động này sẽ thêm nhiều thời gian, nhiều nỗ lực và nhiều chi phí cho dự án. Xếp cặp cũng để cho người quản lí dự án tìm ra nhanh chóng ai là giỏi và ai cần đào tạo thêm, ai có hiệu năng tốt hơn và năng suất cao hơn và ai bao giờ cũng là vấn đề cho tổ.
Nhiều người phát triển KHÔNG thích lập trình cặp đôi bởi vì nó có thể làm phơi ra một số nhược điểm của họ cho người khác. Họ tin rằng lập trình cặp đôi có thể tạo ra xung đột cá nhân. Khi tôi dạy XP cho người phát triển, tôi bao giờ cũng giải thích ích lợi của lập trình cặp đôi như cách tốt để dạy cho nhân viên mới. Nếu bạn để những người lập trình không có kinh nghiệm này một mình làm việc, họ sẽ khổ vì họ phải học nhiều thứ trong thời gian ngắn. Bằng việc xếp cặp họ với người phát triển có kinh nghiệm hơn, họ có thể quan sát và học nhanh hơn nhiều. Họ càng làm việc theo cặp nhiều lần, họ càng học và đóng góp nhiều hơn.
Để đảm bảo thực hiện XP đúng đắn, công ti phải có huấn luyện viên XP để hướng dẫn mọi người theo chiều hướng đúng. Phát triển phần mềm là nỗ lực tổ và mọi tổ đều phải có huấn luyện viên (như, Scrum có thầy Scrum và đội bóng đá có huấn luyện viên). Huấn luyện viên phải là ai đó có đào tạo đúng về XP và có kinh nghiệm với các dự án XP để cho người đó có thể giám sát các hoạt động lập trình cặp đôi, chắc chắn kĩ thuật XP là được thực thi đúng, và sửa vấn đề trước khi phần mềm được đưa ra cho khách hàng.
—-English version—-
Pair Programming
One of the best practice in extreme programming (XP) is Pair programming. The concept is simple: “Two are better than one” so by having two developers actively building code will result in better quality software. With XP, all code must be done by pair programming. However, it is not one person coding and another just watching but both take turn to code several times each day. When one person code, the other is thinking about how to test it and how to integrate the code to previously released software to ensure maximum quality and minimum defects.
After working together as a pair for few days, developers must switch with another pair so they have a chance to work on different functions of the software. As they are moving to different pair, they have to learn new things, eventually they will understand the entire system rather than just few functions. Having developers working on every part of the system will also expose any hidden problem so it can be fixed quickly and efficiently. Working in pair forces developers to write better code, to be more careful on what they do (Because someone is watching), to follow standard process (Your partner is also working as SQA) and eventually developers will learn about working as ateam. The project can benefit from less depending on few key developers and the works would be spread more evenly among team members.
However, many project managers do NOT like pair programming. They believe that having two developers sit next to each other is a waste of time. When I teach XP to project managers, I always explain the benefit of pair programming as performing continuous code review. Without it, project will need to have additional code inspections, additional SQA process compliance review, and additional formal reviews. All of these activities will add more time, more efforts and more costs to the project. Pairing also lets project managers find out quickly who is good and who will need additional trainings, who has better performance and high productivity and who will always be a problem for the team.
Many developers do NOT like pair programming because it can expose some of their weakness to others. They believe that pair programming can create personal conflict. When I teach XP to developers, I always explain the benefit of pair programming as a good way to teach new employees. If you let these inexperienced developers alone to do works, they will suffer as they have to learn many things in a short time. By pairing them with a more experienced developers, they can observe and learn much faster. The more time they work in pair, the more they learn and contribute.
To ensure XP implementation correctly, company must have a XP coach to guide people in the right directions. Software development is a team effort and every team must have a coach (i.e., Scrum has Scrum master and soccer team has coach). The coach must be someone who had proper XP training and experienced with XP projects so he can monitor the pair programming activities, making sure the XP technique is executed correctly, and fixing problems before software is released to the customers.