Lập trình cặp vs. Code Reviews

Bài viết được dịch từ blog Coding Horror

Tom Dommett đã viết ra những kinh nghiệm tích cực của anh về phương pháp lập trình cặp như sau:

Ý tưởng lập trình cặp là hai lập trình viên làm việc trên cùng một cái máy tính. Cả hai đều có bàn phím và chuột. Tại mỗi thời điểm thì một người đảm nhiệm vai trò driver (code chính) và người kia đóng vai trò navigator (hoa tiêu). Vai trò của họ chuyển đổi qua lại cho nhau mỗi giờ, hoặc bất cứ khi nào thực sự thấy cần thiết. Người driver đảm nhiệm việc code, người navigator thì ngồi đọc, kiểm tra và sửa lỗi chính tả và rà soát code, trong lúc đó anh này sẽ nghĩ xuyên suốt về các vấn đề và nên làm gì tiếp theo. Nếu người driver gặp phải một vấn đề, thì sẽ có hai người để tìm ra một giải pháp, và một trong hai người thường có một ý tưởng rất hay.

Những thuận lợi khác bao gồm một thực tế rằng ở đây hai người có những chuyên môn khác nhau, vì vậy những kỹ năng này được trao đổi cho nhau. Lợi ích rất nhiều khi người này chỉ cho người kia một số mẹo, những giải pháp khắc phục tốt, v.v…

Kết quả cuối cùng là cả hai lập trình viên đều hiểu rõ code một cách hoàn toàn, code đó làm việc ra sao, và tại sao nó lại được thực thi theo cách đó. Và phương pháp này mang lại kết quả tốt hơn là khi lập trình viên làm việc một mình. Nó ít bug và những sai sót cùng nhiều thứ linh tinh khác mà sẽ là nguyên nhân của những vấn đề trong quá trình hoạt động sau này.

Trong một nhóm lớn hơn, thì các cặp có thể thay đổi mỗi tuần để cho mỗi một thành viên trong nhóm được làm bạn code với một ai đó hoàn toàn khác. Điều này mang lại lợi ích rất lớn, vì nó tạo điều kiện cho các lập trình viên có thể nói chuyện và trao đổi những ý tưởng trong một ngôn ngữ chung là code.

Chúng tôi nhận thấy cách này có kết quả nhanh như là hình thức làm việc độc lập. Code được viết ra nhanh hơn và không yêu cầu phải rà soát lại. Và khi mà phần code đã viết cần phải thay đổi, thì có nhiều hơn một người nắm rõ phần code đó.

Lập trình cặp đang là một phương pháp mới mẻ hiện đại trong dạy và học lập trình?Lập trình cặp đang là một phương pháp mới mẻ hiện đại trong dạy và học lập trình?


Đó là một kết quả rất đáng khích lệ. Tôi ủng hộ bất cứ điều gì mà giúp cho các thành viên trong nhóm có thể giao tiếp với nhau tốt hơn.

Tôi cảm thấy thích thú với ý tưởng lập trình cặp đó, nhưng cá nhân tôi chưa bao giờ sống với phong cách lập trình cặp cả. Tuy nhiên, tôi thích làm việc bên cạnh những lập trình viên khác. Bất cứ khi nào ngồi xuống làm việc bên cạnh một lập trình viên đồng nghiệp, thì tôi luôn học hỏi được một vài bí quyết và kỹ thuật của họ. Đó là một trải nghiệm học tập rất hiệu quả cho cả hai người tham gia. Nhưng tôi chỉ thích áp dụng cách này trong những công việc nhỏ. Tôi có một chút thận trọng trong việc dành ra cả 8 tiếng để làm việc theo cách này, vì nghi ngờ rằng điều đó có thể dẫn đến mệt mỏi trong những công việc lớn hơn, trừ khi bạn rất may mắn để lựa chọn được một bạn code tuyệt vời.

Tôi đã từng viết về tính hiệu quả của code reviews trước đó. Phương pháp code reviews thì tôi đã có những trải nghiệm cá nhân; và có thể dẫn chứng giá trị của nó mà không cần phải dè dặt. Điều đó không thể giúp tôi thắc mắc rằng liệu lập trình cặp thì có gì hơn là code review xét về mặt nào đó hay không. Không phải là cái này có thể thay thế cho cái kia– bạn có thể chắc chắn làm cả hai– nhưng tôi nghi ngờ rằng nhiều lợi ích của lập trình cặp có thể được nhận ra thông qua việc áp dụng review code bởi đồng nghiệp của bạn.

Nhưng code reviews không phải là một phương thuốc chữa bách bệnh, như Marty Fried đã chỉ ra rằng:

Theo kinh nghiệm của tôi thì code reviews đã trở thành một cái gì đó khá lộn xộn. Một trong những vấn đề dường như rõ ràng đó là không ai lại muốn dành thời gian của mình để thực sự tìm hiểu phần code mới của ai đó mà thực thi một cái gì đó quá phức tạp, vì vậy những phản hồi thường là rất chung chung. Nhưng sau khi một ai đó đang làm việc trên code đó bổ sung thêm chức năng hoặc sửa các bug, thì họ thường có rất nhiều feedback (đôi khi bao gồm những feedback rất quan trọng), nhưng có thể đã trở nên quá trễ để mang lại hiệu quả; lập trình viên đó có thể thậm chí không còn ở đó nữa. Tôi nghĩ rằng cách này có thể hữu ích, nhưng rất khó để cho một lập trình viên đồng nghiệp nói với ông chủ của anh ta rằng một đồng nghiệp khác có chất lượng làm việc rất tồi.

Điểm thuận lợi của lập trình cặp là sự hiểu rõ ngay tức khắc: bạn không thể lờ đi người review khi anh ta hoặc cô ta đang ngồi ngay kế bên bạn. Hầu hết mọi người sẽ thụ động không tham gia nếu được lựa chọn. Với lập trình cặp thì điều đó là không thể. Mỗi nửa của cặp đều phải hiểu phần code đó, ngay và luôn, khi nó được viết ra. Làm việc theo cặp có thể bị xâm phạm tính riêng tư, nhưng nó cũng giúp nâng lên một cấp độ giao tiếp mà bạn sẽ chẳng bao giờ có được theo cách khác.

Mặt khác, việc review ngang cấp tốt hơn rất nhiều so với việc ngồi tụm lại một nhóm trong cùng một phòng. Bạn hãy xem những kinh nghiệm của Macadamian trong phương pháp code review khi ông ta đang làm việc trên dự án WINE như sau:

Có hai quy trình trong dự án WINE mà chúng tôi đã sử dụng: public review bởi đồng nghiệp, nơi mà code và những bản vá mới được phân phát trong một danh sách email tới tất cả mọi người liên quan trong dự án đó; và khi có một người commit code lên thì người leader của dự án đó sẽ có tiếng nói quyết định xem phần code đó có được chấp nhận vào source tree hay không.

Chúng tôi sớm nhận thấy rằng Alexandre Julliard, là người bảo trì dự án WINE và là một trong những lập trình viên nòng cốt từ năm 1994, thường rất khắt khe trong việc chấp nhận cho code của ai đó được vào source tree. Những bản vá của nhóm chúng tôi thường bị săm soi rất kỹ, và khi mà một số bị từ chối, thì đã có rất nhiều lời càu nhàu vang lên. “Code của tôi chạy ổn, vậy mà gã đó không chấp nhận. Hắn nghĩ mình là ai cơ chứ? Chúng ta gần đến deadline rồi mà hắn vẫn không chịu buông tha!”.

Nhưng dự án đó vẫn tiến triển, và chúng tôi nhận ra rằng chúng tôi đã viết ra những phần code của mình tốt nhất từ trước đến nay. Sản phẩm sạch sẽ, code được thiết kế tốt và được chấp nhận vào source tree ngay lần đầu tiên thì trở thành một cái gì đó là niềm tự hào. Chúng tôi cũng nhận thấy rằng, mặc dù thực tế đó là một dự án đồ sộ và các thành viên rải rác khắp nơi trên thế giới, nhưng chúng tôi biết chính xác toàn bộ dự án đó tiến triển như thế nào khi chúng tôi thấy mỗi phần code của nhau trên danh sách mail (mailing list). Giờ đây chúng tôi tiến hành code reviews trên tất cả các dự án, và đối với những dự án lớn thì chúng tôi thiết lập một mailing list nội bộ và chỉ định một committer riêng. Nó có thể khá đau khổ khi thiết lập một quy trình code review tại công ty của bạn, và sẽ có nhiều lời càu nhàu ca thán, nhưng bạn sẽ nhìn thấy sự tiến bộ rất lớn trong chất lượng và khả năng bảo trì code của bạn.

Tôi nghĩ rằng cả hai kỹ thuật trên rõ ràng đều là cách rất tốt, mặc dù mỗi cái trong chúng đều có những mặt ưu và nhược điểm khác nhau. Tôi khuyến khích mọi người đã trải nghiệm với cả hai loại lập trình cặp và code reviews hãy chia sẻ những kinh nghiệm của bạn trong phần bình luận phía dưới. Liệu cái này có hiệu quả hơn cái kia hay không? Hay chúng ta nên làm cả hai?

Lợi ích của lập trình cặp.Cuối cùng, tôi không nghĩ rằng việc nhờ một ai đó xem qua code của bạn thì cũng chắc chắn như là bạn có thêm một cặp mắt nữa quan sát vào những dòng code mà bạn đang viết, tuy nhiên bạn nên lựa chọn làm điều đó. Khi code của bạn được review bởi một người khác — bất kể là người đó đang ngồi ngay kế bên bạn hay đang ở cách xa hàng ngàn dặm — thì bạn sẽ vẫn tạo ra những phần mềm tốt hơn. Đó là một điều tôi có thể đảm bảo chắc chắn.

Các bài viết liên quan:

Về tác giả bài viết:

Jeff_atwood_coding_horrorJeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack ExchangeDiscourse.

Advertisements

6 comments on “Lập trình cặp vs. Code Reviews

  1. Em thấy cách này rất hay vì người code tập trung vào code còn hoa tiêu sẽ tập trung hơn về ý tưởng, bao quát vấn đề hơn.
    Không biết làm ở các công ty họ có cho làm theo kiểu code”thiếu máy” này không 😀

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s