Tag Archives: xp

Lập trình Cặp: chúng ta giúp nhau thành công

Tóm tắt

Lập trình Cặp (Pair-Programming) là cách hai lập trình viên cùng làm việc trên chỉ một máy tính, 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 giao tiếp thông suốt, họ cùng nhau hoàn thành công việc tốt hơn và nhanh hơn khi họ 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ử nào sẽ “lái” mã nguồn đi đúng hướng và những 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 tác vụ hiện thời. Trong mỗi cặp, việc hoán đổi vai trò được thực hiện sau vài tiếng để chia sẻ tầm nhìn và kiến thức.

Bài viết này được trích từ cuốn sách The Art of Agile Development (tạm dịch: Nghệ thuật Phát triển Phần mềm theo Phương pháp Linh hoạt) của tác giả James Shore và Shane Warden, được xuất bản bởi O’Reilly).

Lập trình cặp: Chúng ta giúp nhau thành công

Bạn có muốn ai đó ngồi nhìn bạn làm việc suốt ngày? Bạn có muốn phí một nửa thời gian chỉ ngồi im lìm ủ rũ xem người khác 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 lập trình cặp.

Lập trình cặp là một trong những điều đáng chú ý đầu tiên của 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ọ sẽ thấy thích lập trình cặp hơn làm một mình.

Tại sao cần lập trình cặp?

pair-programming

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 chính là để giúp bạn nghĩ tốt hơn, thông minh hơn.

Khi bạn lập trình cặp, một người viết mã (người lái). Người kia làm hoa tiêu có nhiệm vụ là ngẫm 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ĩ làm cách nào để phần đang được cài đặt đi đúng theo thiết kế tổng thể.

Việc chia ra hai vai trò như vậy giúp cho người lái tập trung vào từng dòng mã chuẩn cú pháp mà không phải lo về tổng thể chương trình, 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ị phân tâm về tiểu tiết mã nguồn cụ thể. 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ẻ.

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.

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 việc kiểm thử liên tục và hoàn thiệ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 trên. 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ùng cặp 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ị. 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 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 tuyệt đối, thấy rằng họ gặp nhiều lỗi hơn nếu lập trình đơn. 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 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ế.

“Có được bối cảnh tươi mới bằng cách luân chuyển cặp.”

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 đề đó.

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. Cá nhân tôi thì tôi chuyển cặp mỗi khi hoàn thành một phần việc. Nếu tôi làm một phần việc lớn, tôi chuyển cặp sau mỗi 4 tiếng.

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. Hãy làm từng 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ử và nói về những giả định của bạn, mục tiêu ngắn hạn, hướng phát triển chung, và bất kì vấn đề gì của tính năng đang cài đặt hoặc của toàn bộ 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

Với thời gian làm việc theo cặp sẽ trở nên tự nhiên

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 nhìn nhận ra những ý 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 bạn đổi vai trò, trở thành hoa tiêu. Dần dần việc làm cặp sẽ trở nên tự nhiên.

Khi điều hướng, bạn sẽ cảm thấy như muốn nhảy vào dành lấy bàn phím từ người cùng cặp. Hãy thư giãn, người lái của bạn sẽ thường đưa ra ý kiến 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 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ể được 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 giữ 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 tự mình bấm luôn phím đó. Nếu khi lái bạn cần nghỉ ngơi một chút, hãy đưa bàn phím cho hoa tiêu.

Thủ thuật 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 đối tác 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

Để lập trình cặp thoải mái, không gian làm việc tốt là thiết yếu. Bạn cần nhiều không gian để hai người ngồi cạnh nhau được thoải mái. Những nơi làm việc ở góc phòng nhỏ điển hình 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 mẽ 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 thích hiển thị một màn hình desktop lên hai màn hình LCD.

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

Hãy ghi nhớ rằng: 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êngiá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 sự 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 theo 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 gõ 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 theo 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 bộ nghiên cứu về lập trình theo 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 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.

Nếu bạn thấy chán khi lập trình cặp, hãy xem bạn có thể làm cho thiết kế ít lặp lại hơn không.

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 tái cấu trúc cần làm, 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 thiếu 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 tự nó 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ì phương pháp nào giúp giảm những thiết sót 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.

Đọc thêm

Pair Programming Illuminated [Williams] discusses pair programming in depth.

“The Costs and Benefits of Pair Programming” [Cockburn & Williams] reports on Laurie Williams’ initial study of pair programming.

“Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience” [Belshee] is an intriguing look at the benefits of switching pairs at strict intervals.

“Adventures in Promiscuous Pairing: Seeking Beginner’s Mind” [Lacey] explores the costs and challenges of promiscuous pairing. It’s a must-read if you plan to try Belshee’s approach.

Peer Reviews in Software: A Practical Guide [Wiegers] discusses formal inspections and peer reviews.

Nguồn http://www.jamesshore.com

Người dịch Code Blue, Nguyễn Trung Tuyến | Biên tập Phạm Anh Đới

Thợ lành nghề #1: Mở đầu Thảm họa

Tác giả: Robert C. Martin Người dịch: Hoàng Ngọc Diêu (conmale) | Biên tập: Phạm Anh Đới Bài viết này lược trích từ chương Nguyên lý, Mẫu thiết kế và Phương pháp trong cuốn Phát triển Phần mềm Linh hoạt (Agile … read more

Có phải thiết kế đã chết?

Martin Fowler là diễn giả, nhà tư vấn và tác giả của rất nhiều sách có ảnh hưởng về phát triển phần mềm, thiết kế và phân tích hướng đối tượng, UML, mẫu thiết kế, các phương pháp phát triển … read more