Bạn có muốn ai đó ngồi nhìn bạn làm việc suốt cả ngày? Bạn có muốn phí một nửa thời gian của mình chỉ để ngồi lặng thinh xem ai đó viết mã?
Tất nhiên là không. Chẳng có ai thích thế cả, đặc biệt là những người viết chương trình cùng với nhau.
Lập trình Cặp là một trong những điều đầu tiên mà mọi người cần lưu ý về XP. Hai người làm việc trên chỉ một bàn phím? Thật kỳ lạ. Nhưng nó thực sự đem lại hiệu quả đáng kinh ngạc, và khi bạn đã quen thì sẽ có rất nhiều điều thú vị. Hầu như tất cả lập trình viên tôi biết, chỉ sau một tháng làm quen với Lập trình cặp họ thấy thích lập trình cặp hơn là làm một mình.
Lập trình Cặp (Pair-Programming) là hai lập trình viên cùng làm việc trên chỉ một máy tính với hai vai trò rõ ràng, một người lái (driver), một người làm hoa tiêu (navigator), thú vị hơn bạn tưởng tượng nhiều. Việc hoán đổi vai trò liên tục giúp cho họ giao tiếp thông suốt, thành công việc tốt hơn và nhanh hơn khi làm một mình.
Người lái tập trung vào sách lược – viết mã nguồn sạch có thể chạy được. Hoa tiêu tập trung và chiến lược – cách mã nguồn phù hợp với thiết kế chung, trường hợp kiểm thử (test case) nào sẽ “lái” mã nguồn đi đúng hướng và tái cấu trúc nào sẽ cải thiện toàn bộ mã nguồn của chương trình.
Các cặp tự tổ chức thông qua việc chọn thành viên phù hợp nhất với nhiệm vụ hiện thời. Trong mỗi cặp, việc hoán đổi vai trò được thực hiện sau một khoảng thời gian hợp lý để các thành viên chia sẻ tầm nhìn và kiến thức.
Tại sao cần Lập trình Cặp?
Chương này được đặt tên là Tư duy, và tôi giới thiệu Lập trình Cặp là phương pháp đầu tiên. Bởi vì lập trình cặp là tất cả để gia tăng năng lực trí tuệ của bạn.
Khi bạn lập trình cặp, một người viết mã – người lái (driver). Người kia làm hoa tiêu (navigator) có nhiệm vụ là suy nghĩ. Khi làm hoa tiêu, đôi khi bạn nghĩ về điều người lái đang gõ (Nhưng đừng vội vàng chỉ trỏ những lỗi như kiểu thiếu dấu chấm phẩy, sẽ gây khó chịu). Đôi lúc bạn nghĩ về phần việc cần làm tiếp theo và đôi khi bạn nghĩ cách để phần đang được cài đặt phù hợp với thiết kế tổng thể.
Việc chia ra hai vai trò như vậy giúp cho người lái tự do đối mặt với những thử thách chiến thuật nhằm tạo ra từng dòng mã chặt chẽ, đúng cú pháp mà không phải lo về bức tranh tổng thể, và giúp hoa tiêu có thời gian cân nhắc về hướng phát triển của chương trình mà không bị chi tiết mã nguồn làm phần tâm. Cùng nhau, người lái và hoa tiêu hoàn thành công việc với chất lượng cao hơn và nhanh hơn khi từng người làm việc riêng lẻ.*
Lập trình cặp còn củng cố những thói quen lập trình tốt. XP tin rằng kiểm thử liên tục (continuous testing) và cải tiến thiết kế cần rất nhiều tính tự giác. Khi lập trình cặp, bạn sẽ có được sức ép tích cực từ bạn cặp để thực hiện những công việc khó khăn nhưng quan trọng. Bạn sẽ chia sẻ được kiến thức và thủ thuật lập trình cho toàn đội.
Bạn cũng sẽ có nhiều thời gian hơn ở trong luồng lập trình – trạng thái năng suất cao mà ở đó bạn hoàn toàn tập trung vào việc lập trình. Dù bạn làm việc cùng một người khác, nhưng luồng lập trình này vẫn bền vững và khó bị gián đoạn hơn khi lập trình một mình. Bởi đồng nghiệp sẽ ít làm phiền bạn hơn khi thấy bạn đang làm việc cùng người khác. Cho dù có bị làm gián đoạn, thì người cặp cùng bạn sẽ giúp giải quyết vấn đề trong khi bạn vẫn tiếp tục dòng suy nghĩ của mình. Hơn nữa, khi bạn tập trung chú ý vào nói chuyện với người cùng cặp thì những tiếng ồn xung quanh sẽ tự động bị biến mất.
Nếu tất cả những điều trên chưa thuyết phục được bạn thử Lập trình Cặp, hãy tin tôi, Lập trình Cặp thực sự rất thú vị. Khi có thêm một cái đầu sẽ giúp bạn vượt qua những vấn đề khó dễ dàng hơn nhiều. Nói chung, bạn sẽ luôn được làm việc với một đồng đội thông minh và cùng chí hướng. Thêm vào đó, nếu cổ tay bạn đau nhức do gõ quá nhiều, bạn có thể chuyển bàn phím cho đồng đội và tiếp tục làm việc mà không hề giảm năng suất.
Lập trình Cặp như thế nào?
Tôi khuyến nghị lập trình cặp với tất cả mã nguồn sản xuất. Rất nhiều đội thực hiện lập trình cặp thường xuyên, nhưng không triệt để, thấy rằng họ tìm thấy nhiều lỗi hơn khi lập trình một mình. Một nguyên tắc tốt là thực hiện lập trình cặp bất cứ phần nào mà bạn cần bảo trì kể cả kiểm thử và mã build ứng dụng.
Khi bạn bắt đầu làm một việc, hãy đề nghị một lập trình viên khác tham gia cùng. Nếu có ai đó đề nghị, hãy thoải mái đồng ý lập trình cặp cùng. Đừng bao giờ phân chia cố định các cặp, hãy lập cặp một cách tự nhiên, linh hoạt và luân chuyển các cặp trong ngày. Qua thời gian, một người sẽ lập trình cặp với tất cả mọi người trong đội. Điều này sẽ giúp cả đội gắn bó hơn và tất cả mọi người đều được chia sẻ kiến thức và các kĩ năng thiết kế.
Khi bạn cần một không khí tươi mới, hãy chuyển cặp. Tôi thường chuyển cặp khi cảm thấy chán nản hay bế tắc. Tuy nhiên luôn phải giữ lại một người đã theo phần việc từ đầu để có thể giúp người mới vào cặp nhanh chóng nắm bắt được vấn đề. Có nhiều lúc, chỉ cần giải thích vấn đề là gì cho người khác cũng giúp bạn giải quyết được vấn đề đó.
Làm tươi mới không khi bằng cách chuyển cặp.
Trong lập trình cặp, dù bạn không thấy nản hay bế tắc, đổi cặp vài lần một ngày cũng tốt. Điều này sẽ giúp thông tin trong đội được thông suốt và mọi người sẽ làm việc hiệu quả hơn. Tôi chuyển cặp mỗi khi hoàn thành một công việc. Nếu tôi làm một việc lớn, tôi chuyển cặp 4 tiếng một lần.
Khi ngồi theo cặp, hãy chắc chắn rằng bạn cảm thấy thoải mái, không bị mỏi. Đặt ghế cạnh nhau, đảm bảo mỗi người có đủ khoảng trống, và có thể nhìn rõ màn hình. Khi làm người lái, hãy đặt bàn phím trước mặt bạn. Chú ý: mọi người khi lập trình theo cặp thường có xu hướng với tay đến bàn phím và chuột chứ không kéo chúng về gần (trước mặt) mình.
Những người lập trình cặp làm việc thông qua đối thoại. Dù bạn là người lái hay hoa tiêu, hãy nói tất cả những điều bạn nghĩ ra. Thực hiện các bước thiết kế nhỏ, liên tục, tốt nhất là làm theo phát triển hướng kiểm thử (TDD), và nói về những giả định của bạn, các mục tiêu ngắn hạn, hướng phát triển chung, và bất kì vấn đề gì liên quan đến tương lai của tính năng hoặc dự án. Hãy hỏi khi bạn thấy mơ hồ về vấn đề gì đó. Việc thảo luận thường giúp cả bạn và người cùng cặp hiểu rõ vấn đề đó hơn.
Khi bạn thấy một cặp có vẻ trầm (ít nói, nói nhỏ, hoặc không luân chuyển với các cặp khác) thì nó thường là dấu hiệu của khó khăn kỹ thuật
Bạn luôn cảm thấy mệt mỏi vào cuối ngày? Các cặp lập trình thường cảm thấy họ đã làm việc nhiều hơn và đạt hiệu quả cao hơn khi họ làm việc một mình. Hãy thực hành “Làm việc đầy năng lượng” (Energized work) để duy trì năng lượng làm việc mỗi ngày.
Lái và điều hướng
Khi mới bắt đầu, bạn sẽ cảm thấy vụng về khi làm người lái. Bạn cũng có thể cảm thấy người hoa tiêu tinfm ra ý tưởng và vấn đề nhanh hơn bạn rất nhiều. Quả thật như vậy, hoa tiêu có nhiều thời gian để nghĩ hơn người lái. Tình thế sẽ được đảo ngược khi đổi vai trò, bạn trở thành hoa tiêu. Dần dần làm việc theo cặp sẽ trở nên tự nhiên.
Với thời gian làm việc theo cặp sẽ trở nên tự nhiên.
Khi điều hướng, bạn sẽ cảm thấy muốn nhảy vào dành lấy bàn phím từ người cặp với mình. Hãy thư giãn, người lái của bạn sẽ thường truyền tải một ý tưởng bằng cả lời nói và mã nguồn. Người đó sẽ mắc những lỗi gõ sai hay những lỗi nhỏ, nhưng hãy cho anh ý chút thời gian để tự sửa lại. Hãy dùng trí lực của bạn để nghĩ về bức tranh lớn hơn. Những kiểm thử nào khác các bạn cần phải viết? Làm thế nào để đoạn mã phù hợp với phần còn lại của hệ thống? Có sự trùng lặp nào cần loại bỏ không? Mã có thể rõ ràng hơn được không? Thiết kế tổng thể có thể tốt hơn không?
Nhiệm vụ của hoa tiêu là giúp người lái làm việc hiệu quả hơn. Hãy nghĩ về những điều xảy ra tiếp theo và chuẩn bị những đề xuất. Khi tôi điều hướng, tôi thường đặt một thẻ chỉ mục trước mặt tôi. Thay vì làm gián đoạn người bạn “cầm lái” khi tôi nghĩ về một vấn đề, tôi viết những ý tưởng của tôi lên thẻ chỉ mục và chờ đến lúc nghỉ để thảo luận. Vào cuối phiên làm việc cặp, tôi xé tấm thẻ và bỏ nó đi.
Tương tự như vậy, khi một câu hỏi phát sinh, hãy dành một chút thời gian để tìm kiếm câu trả lời trong khi người lái đang làm việc. Một số nhóm dùng thêm máy tính sách tay cho mục đích này. Nếu bạn cần nhiều hơn một vài phút, hãy cùng người lái tìm kiếm giải pháp. Đôi khi cách tốt nhất để làm là tách riêng ra, tìm kiếm song song với nhau và thường xuyên chia sẻ với nhau những gì học được. Những khung giải pháp là một cách tiếp cận hiệu quả.
Khi ghép cặp, hãy thường xuyên chuyển đổi vai trò cho nhau ít nhất sau mỗi 30 phút, có thể là sau vài phút. Khi bạn điều hướng và thấy rằng cần bảo người lái phải bấm phím nào đó, hãy yêu cầu chuyển bàn phím. Nếu khi đang “cầm lái” bạn cần nghỉ ngơi một chút, hãy chuyển bàn phím cho hoa tiêu.
Thủ thuật khi Lập trình Cặp
- Làm việc theo cặp với bất cứ thứ gì bạn cần bảo trì
- Hãy để các cặp hình thành tự nhiên hơn là bị gán cố định
- Hãy chuyển đổi cặp khi bạn cần một không khí tươi mới
- Tránh cặp với cùng một người trong hơn một ngày
- Ngồi thoải mái, cạnh nhau
- Viết mã thông qua đối thoại. Hãy hợp tác chứ đừng chỉ trích
- Người lái và hoa tiêu thường xuyên hoán đổi vai trò cho nhau
Không gian Lập trình Cặp
Không gian làm việc tốt là thiết yếu để lập trình cặp thoải mái. Bạn cần nhiều không gian để hai người ngồi cạnh nhau được thoải mái. Đặc biệt, khoang làm việc ở góc phòng sẽ không hiệu quả. Chúng không thoải mái và một người phải ngồi sau người kia, gây ra rào cản tâm lý cũng như vật lý ngăn cản sự cộng tác.
Bạn không cần đồ nội thất bóng bẩy để lập trình cặp tốt. Thứ tốt nhất tôi từng thấy chỉ là những chiếc bàn gấp đơn giản được tìm thấy tại bất kì cửa hàng đồ văn phòng tốt nào. Chúng nên dài khoảng 1,8 mét, để hai người có thể ngồi thoải mái cạnh nhau, và cao ít nhất 1,2 mét. Mỗi bàn cần một máy tính đủ mạnh chuyên dùng cho lập trình. Mỗi máy tính nên có hai bộ bàn phím và chuột để tiện cho mỗi người trong cặp.
Nên có màn hình lớn để cả 2 người có thể nhìn thấy rõ ràng. Một số nhóm hiển thị lên hai màn hình giống nhau, giúp dễ nhìn hơn một chút, nhưng có thể làm bạn chỉ sai màn hình khi thảo luận với nhau. Một số nhóm khác lại phân chia một desktop lên hai màn hình.
Những thử thách khi Lập trình Cặp
Lập trình theo cặp ban đầu có thể không được thoải mái, bởi cách làm việc này yêu cầu bạn phải có tinh thần hợp tác nhiều hơn cách mà bạn quen làm. Điều này là tự nhiên và thường sẽ mất đi sau một hoặc hai tháng, nhưng bạn phải đối mặt với một vài thử thách.
Sự thoải mái
Điều này đáng để nhắc lại: lập trình cặp không vui chút nào nếu bạn không thoải mái. Khi bạn ngồi xuống làm việc, điều chỉnh vị trí và thiết bị sao cho bạn cảm thấy thoải mái. Dọn rác trên bàn làm việc và hãy chắc chắn có đủ không gian cho chân và đầu gối của bạn.
Một vài người (như tôi) cần rất nhiều không gian riêng. Những người khác lại thích ngồi gần hơn. Khi bạn bắt đầu ghép cặp, hãy thảo luận về nhu cầu không gian cá nhân của bạn và đối tác của bạn.
Tương tự như vậy, không thể không nhắc tới vấn đề vệ sinh cá nhân. Nhớ rằng những hương vị mạnh như cà phê, tỏi, hành, thức ăn cay có thể dẫn tới hơi thở hôi. Để tránh xảy ra rắc rối, hãy cùng nhau quyết định cách góp ý về những thói quen cá nhân một cách tôn trọng.
Chênh lệch về trình độ
Lập trình theo cặp thường là sự hợp tác giữa những người có trình độ tương đương nhau, nhưng thỉnh thoảng một lập trình viên cao cấp, nhiều kinh nghiệm sẽ cặp với một người ở trình độ thấp hơn. Thay vì xem mối quan hệ này như sinh viên\giáo viên, hãy lấy lại sự cân bằng ngang hàng bằng cách tạo ra cơ hội cho cả hai người để học tập. Ví dụ, nếu biết bạn được cặp với một lập trình viên còn non kém kinh nghiệm, bạn có thể đề nghị người đó nghiên cứu về một chủ đề mà không ai khác biết, chẳng hạn các công việc bên trong của một thư viện mà nhóm phụ thuộc vào. Hãy cho tất cả mọi người một cơ hội trở thành chuyên gia.
Phong cách giao tiếp
Những người lái mới thỉnh thoảng gặp khó khăn trong giao tiếp với người hoa tiêu, họ có thể chiếm bàn phím tự gõ mã theo ý họ và làm mất đi sự giao tiếp trong cặp. Để thực hành giao tiếp và chuyển đổi vai trò trong lập trình cặp, hãy thử lập trình cặp kiểu bóng bàn (ping-pong pairing). Khi lập trình cặp kiểu bóng bàn, một người A viết một kiểm thử. Người B sẽ viết mã để vượt qua kiểm thử rồi viết một kiểm thử mới cho người A . Người A viết mã để vượt kiểm thử rồi lại viết một kiểm thử mới. Quá trình như vậy được lặp đi lặp lại như khi chơi bóng bàn.
Ngược lại của giao tiếp quá ít là giao tiếp quá nhiều, những giao tiếp không cần thiết. Những lời phê bình thẳng thắn về mã nguồn và thiết kế là rất quí báu, nhưng ban đầu ta sẽ khó mà chấp nhận được chúng. Mỗi người có một độ nhạy cảm khác nhau, vì vậy hãy chú ý tới cách đối tác của bạn tiếp nhận những lời nhận xét của bạn như thế nào. Hãy cố chuyển những câu khẳng định (ví dụ: “Phương thức này quá dài”) thành câu hỏi hay lời gợi ý (“Chúng ta có thể làm phương thức này ngắn hơn không?” hoặc “Chúng ta có nên đẩy khối mã này ra thành một phương thức mới hay không?”). Hãy giữ một thái độ hợp tác để cùng giải quyết vấn đề.
Công cụ và phím tắt
Ngay cả khi bạn không là nạn nhân trong cuộc chiến bất tận giữa trình soạn thảo vi và emacs, bạn cũng có thể thấy khó chịu với các thiết lập trong công cụ của người cùng cặp. Hãy cố gắng chuẩn hóa một thiết lập nào đó. Một vài nhóm thậm chí còn tạo cả một bản chuẩn và đặt nó trong quản lý phiên bản. Khi bạn thảo luận về các quy chuẩn lập trình, hãy thảo luận cả vấn đề này nữa.
Hỏi và đáp về Lập trình Cặp
Liệu có lãng phí không khi cần tới hai người làm công việc của một người?
Trong lập trình cặp, hai người không thực sự chỉ làm công việc của một người. Mặc dù chỉ có một bàn phím được sử dụng nhưng lập trình có nhiều công việc khác ngoài viết mã. Ward Cunningham đã nói: “Nếu bạn không nghĩ một cách cẩn thận, bạn có thể nghĩ rằng lập trình chỉ là gõ những câu lệnh của một ngôn ngữ lập trình.” Trong lập trình cặp, một người sẽ lập trình còn người kia nghĩ về những thứ xa hơn, về những vấn đề có thể phát hiện sớm, và chiến lược.
Nếu bạn cần tìm hiểu sâu hơn, [Williams] có một chương nghiên cứu về lập trình cặp. Hãy nhớ rằng những biến thể trong phát triển phần mềm làm nó rất khó để thực hiện những nghiên cứu quy mô lớn. Đôi khi cách tốt nhất để biết thứ gì đó có hoạt động tốt cho nhóm của bạn hay không là hãy thử nó.
Làm sao để thuyết phục nhóm hay công ty tôi thử lập trình cặp?
Hãy xin được thử nghiệm lập trình cặp. Dành khoảng một tháng để tất cả mọi người làm việc theo cặp trên tất cả các mã nguồn sản phẩm. Hãy cố gắng thử nghiệm đủ một tháng, cho dù lập trình cặp thường khó làm và khiến bạn không thoải mái trong vài tuần đầu tiên.
Đừng nên chỉ xin phép quản lý, hãy chắc chắn tất cả các thành viên trong nhóm của bạn cũng cảm thấy thích thú khi thử lập trình cặp nữa. Những lập trình viên duy nhất mà tôi biết không thích lập trình cặp sau khi thử trong một tháng là những người bị ép buộc phải làm.
Chúng tôi có phải lập trình cặp mọi lúc không?
Đây là điều mà cả nhóm của bạn nên cùng quyết định. Trước khi quyết định, hãy thử làm việc theo cặp trong tất cả các mã nguồn sản phẩm (mọi thứ bạn cần phải bảo trì) trong một tháng. Ban có thể sẽ thấy thú vị hơn mong đợi.
Bất chấp những quy định, bạn vẫn sẽ làm ra những đoạn mã mà bạn không phải phải bảo trì (Khung giải pháp là một ví dụ). Những cái này có thể được hưởng lợi từ nghiên cứu cá nhân.
Một vài tác vụ cứ lặp đi lặp lại đến nỗi mà không cần thiết phải động não thêm.Tuy nhiên, trước khi từ bỏ lập trình cặp, hãy xem tại sao thiết kế của bạn lại yêu cầu quá nhiều sự lặp lại. Nó có thể là dấu hiệu của một lỗ hổng thiết kế. Hoa tiêu nên sử dụng thêm thời gian để nghĩ về việc cải tiến thiết kế và thảo luận nó với cả nhóm.
Làm sao tôi có thể tập trung khi mà luôn có ai đó cứ nói chuyện với tôi?
Khi điều hướng, nếu bạn gặp khó khăn để hiểu các bước tiếp theo người lái định làm, hãy yêu cầu người lái nói ra suy nghĩ của họ.
Là người lái, đôi khi bạn có thể thấy rằng mình đang mất tập trung. Hãy để người điều hướng biết, họ có thể đưa ra gợi ý giúp bạn giải quyết vấn đề. Cũng có thể, bạn chỉ cần một vài khoảnh khắc yên tĩnh để tập trung lại.
Nếu bạn khó tập trung, hãy thử thực hiện các bước nhỏ hơn.
Nếu bị mất tập trung liên tục, bạn có thể đã làm theo các bước quá lớn. Hãy sử dụng TDD (Test-Driven Development) và làm theo các bước rất nhỏ (baby step). Dựa vào người điều hướng của bạn để theo dõi những gì bạn cần làm (nói với cô ấy nếu bạn có một ý tưởng, cô ấy sẽ viết nó ra) và chỉ tập trung vào vài dòng mã cần phải làm để vượt qua kiểm thử.
Nếu bạn đang làm việc với một kĩ thuật mà bạn không hoàn toàn hiểu, dành vài phút để làm việc với một khung giải pháp. Bạn và người cùng cặp của bạn có thể cùng làm hoặc làm riêng.
Làm gì nếu chúng tôi bị lẻ một người ?
Người lập trình viên bị lẻ ra đó có thể làm những công việc khác không liên quan đến mã nguồn sản phẩm. Anh ta có thể nghiên cứu kỹ thuật mới, hoặc nghiên cứu sâu hơn về công nghệ mà nhóm đang dùng. Hoặc anh ta có thể bắt cặp cùng với một khách hàng hoặc kiểm thử viên để xem xét chương trình, “đánh bóng” chương trình hoặc làm kiểm thử khám phá. Hoặc anh ta cũng có thể làm batman của nhóm (trong một nhóm XP, batman là người xử lý những yêu cầu trợ giúp hoặc yêu cầu đột xuất của khách hàng, thuyết phục họ dời yêu cầu đột xuất đó sang phân đoạn sau, xem thêm ở “Iteration Planning” ).
Thường thì lập trình viên bị lẻ ra dùng thời gian xem lại thiết kế tổng thể để hiểu rõ hơn nó hoặc nghĩ cách cải thiện những phần chưa ổn. Nếu có nhiều việc cần làm về tái cấu trúc, người lập trình viên lẻ có thể đảm nhận việc này.
Nếu nhóm chỉ có 2 hay 3 người, có nên lập trình cặp liên tục?
Thậm chí một ông thánh cũng có thể làm bạn phát cáu nếu bạn cứ phải cặp với ông ta ngày này qua ngày khác. Bạn phải tự mình quyết định khi nào thì lập trình cặp và khi nào bạn cần thời gian làm việc một mình. Nếu bạn thấy ổn nhưng cặp của bạn lộn xộn dần, đừng cố quá, hãy nghỉ ngơi một chút.
Tôi đã từng lập trình cặp với một người trong 3 tháng liền làm một dự án hai người. Tôi nghĩ việc chúng tôi có một văn phòng rộng và một cái bàn to rất hữu ích: nó giúp chúng tôi không gian để di chuyển vòng vòng xả căng thẳng. Chúng tôi còn có một cái tủ lạnh mini với đầy đồ ăn ở trong.
Thậm chí khi có những điều kiện thoải mái như vậy, tôi vẫn có những lần phải phát cáu lên.
Có lẽ điều quan trọng giúp tôi có thể lập trình cặp với cùng một người lâu như vậy là nhờ người cùng cặp với tôi là người rất dễ tính và không để tâm đến những lần tôi phát cáu đó.
Quá tập trung vào công việc và quên mất việc chuyển cặp, làm cách nào để chuyển cặp thường xuyên hơn?
Thực tế, thời điểm tốt nhất để đổi cặp và có được không khí làm việc tươi mới là khi bạn cảm thấy bế tắc hoặc “ngán”.
Một vài đội dùng đồng hồ báo giờ để chuyển cặp sau một khoảng thời gian định trước. Báo cáo của Belshee cho thấy rằng chuyển cặp sau mỗi 90 phút đem lại hiệu quả tốt. Mặc dù việc tạo thói quen chuyển cặp là rất tốt, nhưng hãy chắc chắn là tất cả mọi người đều muốn vậy (Có thể có ai đó không muốn chuyển cặp mà muốn tiếp tục làm việc cặp với người cũ để giải quyết nốt vấn đề sắp xong chẳng hạn).
Làm thế nào để lập trình cặp từ xa?
Bạn có thể dùng tai nghe và phần mềm chia sẻ màn hình desktop như VNC hay NetMeeting để lập trình cặp từ xa. Tôi có nghe nói đến những đội đã dùng hai máy tính nhưng chia sẻ cùng màn hình với nhau cùng với chương trình VoIP. Khi tôi thử theo cách này, tôi thấy rằng nó khá tệ. Các đội XP thường ngồi cùng nhau, vì vậy việc lập trình cặp từ xa thường không cần thiết.
Những lợi ích đáng kinh ngạc của Lập trình Cặp
Khi bạn đã lập trình cặp thuần thục, bạn sẽ thấy mình hết sức tập trung vào công việc và làm việc với bạn cùng cặp. Bạn sẽ ít bị gián đoạn và xao nhãng hơn. Khi bị ai đó gián đoạn thì sẽ có một người giải quyết vấn đề còn người kia tiếp tục công việc. Sau gián đoạn, bạn có thể trở lại với công việc ngay lập tức. Đến cuối ngày, bạn sẽ thấy thoả mãn dù mệt mỏi. Bạn thích thú được làm việc tập trung và thân thiện với bạn cùng cặp.
Toàn nhóm có được mã chất lượng cao hơn hẳn. Nợ kỹ thuật (technical debt) giảm. Kiến thức thông suốt trong nhóm, giúp nâng cao trình độ của mỗi người và giúp thành viên mới nhanh chóng hoà nhập vào nhóm.
Chống chỉ định
Lập trình cặp yêu cầu một môi trường làm việc thoải mái (tham khảo các thiết kế “Sit Together” ở chương 6). Nếu không gian làm việc của bạn không cho phép các cặp ngồi cạnh nhau một cách thoải mái, hoặc là thay đổi không gian làm việc hoặc là đừng lập trình cặp nữa.
Tương tự như vậy, nếu đội của bạn không ngồi cùng nhau, lập trình cặp có thể mất tác dụng. Việc lập trình cặp từ xa thì không thể bằng được khi ngồi cùng nhau.
Một lý do khác để không lập trình cặp khi lập trình viên không thích ứng được. Lập trình cặp là một sự thay đổi lớn về phong cách lập trình và bạn có thể gặp phải vấn đề không tương thích. Tôi thường giải quyết vấn đề này bằng cách yêu cầu mọi người cố gắng thử lập trình cặp trong một hoặc hai tháng trước khi đưa ra quyết định cuối cùng. Nếu họ vẫn không thể thích ứng được, tốt nhất là không nên áp dụng lập trình cặp nữa thay vì cố gắng ép buộc.
Các giải pháp thay thế
Lập trình cặp là một phương pháp rất mạnh mẽ. Nó làm giảm các thiếu sót, cải thiện chất lượng thiết kế, chia sẻ kiến thức giữa các thành viên trong nhóm, tăng tính kỉ luật, giảm phiền nhiễu mà không bị giảm năng suất. Nếu bạn không thể lập trình cặp, bạn cần phương pháp thay thế.
Thanh tra mã nguồn một cách chính thống có thể giảm sai sót, cải thiện chất lượng, tăng tính kỉ luật. Tuy nhiên, theo kinh nghiệm của tôi, các lập trình viên có vấn đề bao gồm cả sự kiểm tra trong lịch làm việc của họ, ngay cả khi họ đang ủng hộ nó. Lập trình cặp dễ dàng hơn để làm một cách nhất quán, và nó cung cấp nhiều phản hồi nhanh hơn là sự kiểm duyệt theo lịch trình. Nếu bạn muốn sử dụng những kiểm duyệt ở nơi đang lập trình cặp, hãy thêm một số cơ chế hỗ trợ để giúp chúng được thực hiện.
Kiểm duyệt độc lập không có khả năng chia sẻ kiến thức kỹ càng như việc sở hữu mã tập thể đòi hỏi. Nếu bạn không thể lập trình theo cặp, hãy xem xét tránh việc sở hữu mã tập thể, ít nhất lúc đầu.
Nếu bạn vẫn muốn có việc sở hữu mã tập thể, bạn cần một cơ chế thay thế cho việc chia sẻ kiến thức về trạng thái của mã nguồn cơ sở. Tôi đã thành lập các nhóm nghiên cứu thường xuyên nơi mà các lập trình viên gặp nhau hàng ngày trong khoảng 30 phút để xem xét và thảo luận về thiết kế.
Tôi không biết bất kì công cụ nào giúp giảm sự mất tập trung tốt như lập trình cặp. Tuy nhiên, tôi nhận thấy rằng mình không chịu đựng được nhiều phiền nhiễu khi đang mệt. Khi không lập trình cặp, hãy quan tâm nhiều hơn đến tầm quan trọng của nhiệt huyết trong công việc.
- Một nghiên cứu cho thấy rằng lập trình cặp tốn công sức hơn 15% so với lập trình một mình, nhưng nhanh tạo thành sản phẩm hơn
và ít lỗi hơn 15% [Cockburn & Williams]. Tuy nhiên, mỗi đội mỗi khác nên kết quả thống kê trên chỉ nên dùng để tham khảo.
Nguồn: Tạp Chí Lập Trình
