Hoán đổi cặp: Ưu và nhược điểm là gì?

Ý tưởng chung được hầu hết các nhà lý thuyết Agile / XP tán thành dường như là các cặp nên trao đổi thường xuyên. Ví dụ, mỗi lập trình viên nên trao đổi các cặp một lần mỗi ngày; Một nửa số người trao đổi vào đầu ngày, một nửa số người trao đổi sau bữa ăn trưa: do các yếu tố bên ngoài như cuộc họp, ngày lễ và giống như hầu hết mọi người sẽ có xu hướng lật thời gian trao đổi của họ một hoặc hai lần mỗi tuần để cấu hình cặp phân phối khá đồng đều trên toàn đội.

Một lý do đằng sau việc hoán đổi thường xuyên là kiến thức được lan truyền trong nhóm một cách nhanh chóng và đồng đều, thay vì tập trung vào các kỹ năng cụ thể ở từng cá nhân - ngụ ý rằng công việc có thể tiếp tục suôn sẻ nếu mọi người rời khỏi công ty. Một lý do khác, đó là một hệ quả tất yếu của giáo điều xung quanh việc lập trình cặp, đó là mỗi lần ai đó trao đổi với bạn sẽ nhận được một đánh giá mã mới bởi một cặp mắt mới, vì vậy nó chỉ có thể cải thiện chất lượng mã.

Cả hai khẳng định nghe có vẻ hợp lý; từ quan điểm quản lý, có vẻ như bạn có được sự gia tăng cả về tính ổn định và chất lượng, và vì việc hoán đổi thường xuyên như vậy là khá nhiều lý thuyết tiêu chuẩn trong hầu hết các cuốn sách Agile / XP mà tôi đã xem.

Vì vậy, khi thực sự được đưa vào thực tế, mọi người thực sự nghĩ gì về việc hoán đổi cặp từ

Quan điểm của một lập trình viên?
Quan điểm của một người quản lý?

Và

Điều gì sẽ xác định khi ai đó hoán đổi / lên một cặp?

agile pair-programming

Đây có phải là điều tương tự như "Lập trình cặp?"

— Robert Harvey

@Robert Harvey - Vâng, đó là một khía cạnh của lập trình cặp. Khi một nhóm quyết định rằng họ sẽ lập trình theo cặp (trong một phần tỷ lệ trong ngày làm việc của họ), thì họ cần quyết định cách sắp xếp các lập trình viên thành các cặp, tức là khi một lập trình viên nên rời khỏi một cặp (một người khác nên tham gia cùng một lúc ). Đó là "Hoán đổi cặp".

+1 cho câu hỏi tuyệt vời. Đáng buồn thay, tôi nghĩ rằng thật khó để tìm thấy một cửa hàng ghép nối thường xuyên, hãy để một mình đủ để có dữ liệu về trao đổi cặp. Hy vọng rằng tôi đã sai về điều này và bạn nhận được một số phản hồi tốt, tôi rất thích nghe một số.

— Jesse McCulloch

Cá nhân tôi sẽ thấy cặp trao đổi rất mất tập trung. Cố gắng đối phó với rất nhiều tính cách và trình độ kỹ năng khác nhau trong các khu vực gần như vậy sẽ tạo ra quá nhiều bất đồng về nhận thức.

— Robert Harvey

@Jlie McCulloch - Tôi làm việc tại một nơi chỉ ghép các chương trình và hoán đổi khá nhiều như những cuốn sách nói rằng một đội nên làm. Tôi cũng đã làm việc trong một môi trường solo thuần túy và do đó có một số quan điểm khá tốt về độ tương phản. Tuy nhiên, tôi muốn nghe ý kiến của người khác vì tôi muốn xem liệu họ có khớp với ý kiến của tôi không mà ảnh hưởng đến họ quá nhiều.

Câu trả lời:

Lập trình cặp rất khó.

Điều này thật khó vì nó hoạt động tốt nhất khi 2 người tham gia ở gần trình độ kỹ năng và điều đó có thể khó khăn trong một số môi trường làm việc. Có thể khó khăn hơn khi bạn trao đổi vì bạn cần tìm người khác có trình độ kỹ năng phù hợp và sau đó đưa họ đến để giải quyết vấn đề hiện tại. Lợi ích là nhiều người tiếp xúc với bất kỳ đoạn mã nhất định nào đã được ghép nối. Điều này sẽ dẫn ít lần hơn khi mã không thể được sửa vì không ai biết đủ về nó. Nó cũng nên tuyên truyền quyền sở hữu nhóm và khả năng cho bất cứ ai để nhận bất kỳ phần công việc.

Tôi đã thấy rằng ngay cả trong những môi trường mà việc ghép đôi được thực hiện, việc hoán đổi cặp cũng không đáng giá. Tuy nhiên, điều này có thể là do các nhiệm vụ của chúng tôi không bao giờ mất quá ~ 1,5 ngày. Chúng tôi đã tìm thấy một lợi ích tuyệt vời để phá vỡ các nhiệm vụ không lớn hơn ~ 1,5 ngày làm việc. Trao đổi cặp có thể có ý nghĩa hơn trong bối cảnh của các tác vụ chạy dài hơn.

— chế độ ăn kiêng
nguồn

Cá nhân, tôi thích ghép đôi với mọi người ở mọi cấp độ. Đôi khi tôi đang học, đôi khi tôi đang dạy và đôi khi chúng ta chỉ đang hoàn thành công việc. Nhưng học tập và giảng dạy xây dựng năng lực nhóm lâu dài, mà tôi nghĩ cũng quan trọng như kiểm tra các tính năng.

— William Pietri

bạn có thể nghĩ như vậy, nhưng người quản lý dự án khi thấy thời hạn của anh ta bốc hơi khi chuyên môn của bạn được sử dụng để đào tạo mọi người về thời gian của anh ta thay vì viết ra mã nhanh như bạn không thể đồng ý. Và đó là cách mà hầu hết các dự án vận hành, đơn giản là không có thời gian để đào tạo mọi người có các kỹ năng cần thiết để thực hiện công việc để đàn em bị treo lủng lẳng, chỉ tốt khi chịu trách nhiệm cho việc vượt ngân sách.

— jwenting

@William Pietri: Theo kinh nghiệm của tôi, ghép đôi không phải là một định dạng tốt cho việc giảng dạy. Tôi không gặp vấn đề gì khi lấy ai đó và đưa họ qua mã để giải thích cho họ chuyện gì đang xảy ra. Tuy nhiên, đó không phải là lập trình cặp.

— dietbuddha

@jwenting: Nếu bạn nói rằng lập trình cặp sẽ không hoạt động tốt trong các cửa hàng tập trung vào thời hạn nhảm nhí về chất lượng và tính bền vững, tôi sẽ không tranh luận. Mẹo của tôi: làm việc ở đâu đó không điên rồ.

— William Pietri

@dietbuddha: Làm việc cho tôi! Cách nhanh nhất để tôi học một ngôn ngữ, khung hoặc thư viện mới là kết hợp với những người biết rõ về nó. Và tôi biết không có cách nào tốt hơn để tăng tốc độ của một noob hơn là ghép đôi. Ví dụ: điều này mang lại trải nghiệm: slesinsky.org/brian/code/starting_xp.html

— William Pietri

Tôi vừa là lập trình viên vừa là người quản lý. Đây là của tôi:

Trao đổi thường xuyên là tuyệt vời. Tôi thích trao đổi 2-4 lần mỗi ngày, nhanh như tôi nghĩ bạn có thể đi. Đối với chúng tôi, điều đó đến ở các điểm phá vỡ tự nhiên: thường là bữa trưa và giữa buổi chiều. Thay đổi mỗi ngày hoặc hai ngày có lẽ là tốt, nhưng tôi lo lắng về việc sẽ lâu hơn thế. (Tôi đã nghe nói về một nơi hoán đổi hiếm khi cứ sau sáu tuần, điều mà tôi nghĩ là điên rồ; sau nhiều thời gian bên nhau, bạn sẽ sẵn sàng đâm chết một vị thánh.)

Là một lập trình viên, tôi thích nó bởi vì tôi có những quan điểm mới mẻ, có thể kiểm tra các lĩnh vực khác của mã và có thể gắn bó hoặc tiếp tục từ một cái gì đó mà tôi thích. Gần đây tôi đã đi từ mã hóa solo trở lại để ghép nối, và tôi rất vui mừng: tôi học được nhiều hơn, vui vẻ hơn và làm được nhiều việc hơn.

Là một người quản lý, tôi nghĩ thật tuyệt vời vì nó giải quyết được rất nhiều vấn đề về yếu tố xe tải và tắc nghẽn. Ví dụ, cuối tuần này tôi sẽ dành một ngày cuối tuần dài cho đám cưới của một người bạn và tôi không lo lắng gì cả: mọi thứ tôi đã làm cũng đã được người khác làm việc. Tôi cũng nghĩ rằng nó thực sự giúp các thành viên trong nhóm đánh giá cao điểm mạnh và điểm yếu của nhau và khuyến khích quyền sở hữu mã tập thể.

Đối với những người ở lại với công việc hiện tại, tôi cảm thấy như nó chủ yếu phụ thuộc vào những người liên quan. Đôi khi bạn muốn thấy điều gì đó thông qua, và đôi khi bạn đã sẵn sàng cho một sự thay đổi. Đôi khi chúng tôi cũng trao đổi để mang lại kiến thức chuyên môn hoặc để ai đó có thể học được điều gì đó mà họ quan tâm. Chúng tôi cố gắng duy trì các đơn vị công việc của mình khá nhỏ (0,5-2 ngày đôi), vì vậy đó không phải là vấn đề lớn. .

— William Pietri
nguồn

Đối với tôi, tôi phải nói rằng việc hoán đổi chỉ tốt khi a) Tôi không thích viết mã với anh chàng tôi đang viết mã, b) Tôi không thích câu chuyện mà tôi đang làm việc (như sửa một ropey lỗi bộ nhớ cũ). Nếu không tôi muốn ở lại từ đầu đến cuối. Cá nhân tôi nghĩ rằng việc hoán đổi cặp làm giảm chất lượng mã bởi vì mã tốt nên có một tầm nhìn rõ ràng, càng nhiều người làm việc trên một bộ phận, tầm nhìn càng trở nên lộn xộn. Về việc chia sẻ kiến thức, tôi muốn nói rằng hầu hết mọi người đều có một chút ý tưởng về những gì đang xảy ra, nhưng không ai thực sự hiểu đúng về bất cứ điều gì.

@B Tyler - Tôi nghĩ rằng một cơ sở mã là một công việc trí tuệ chung, vì vậy bạn phải có một tầm nhìn rõ ràng cũng là một tầm nhìn chung. Đó là một phần lý do tại sao tôi nghĩ rằng điều quan trọng là phải trao đổi: cần rất nhiều sự tương tác và thảo luận để phát triển một cách tiếp cận chia sẻ vững chắc.

— William Pietri

Okie, đây là câu trả lời từ một lập trình viên nhanh nhẹn / xp thực dụng tự xưng. Tôi đã được lập trình cặp trong hơn hai năm nay. Nếu lập trình cặp là tốt, hoán đổi các cặp thường xuyên (lý tưởng là cứ sau hai giờ, nếu không cứ sau nửa ngày). Ở vị trí văn phòng của chúng tôi, chúng tôi coi việc trao đổi các cặp mỗi ngày (thường là) hoặc hai ngày một lần (trong trường hợp xấu hơn). Làm điều này tự nó có thể mang lại cho chúng tôi rất nhiều niềm tin vào chất lượng mã mà chúng tôi cam kết và học hỏi hoặc thực hiện theo từng vòng quay (chúng tôi biết rằng đánh giá mã là tốt, càng tốt và càng sớm càng tốt. Đây là những gì "lập trình cặp, bao gồm cả việc thực hành trao đổi cặp" đạt được).

Tại sao chúng ta không chuyển đổi cặp cứ sau hai hoặc bốn giờ? Chà, thực ra tôi cũng đã ở trong những đội thực hành điều này. Đó chắc chắn là cách mát mẻ và năng suất hơn. Nhưng đây là thỏa thuận, khoảng thời gian của các cặp trao đổi không nên là một quy tắc, nó nên tự xảy ra; chỉ sau đó người quản lý hoặc doanh nghiệp có thể thấy lợi ích của nó.

Tôi đã chứng kiến và trải nghiệm điều này. Bây giờ tôi là nhà truyền giáo của nó. Nó không có lý thuyết. Thay vì hoàn toàn thực dụng của nó :) Chúc mừng cặp đôi bóng bàn và trao đổi.

— karthiks
nguồn

Than ôi bây giờ tôi hoàn toàn chuyển đổi sang ý kiến rằng lập trình cặp nói chung là một ý tưởng tồi; trao đổi cặp thường xuyên trong lập trình cặp chỉ làm cho mọi thứ tồi tệ hơn. Tôi đã nghe tất cả các lý thuyết và đã thử nó rất nhiều trong thực tế và tôi chỉ nghĩ rằng nó cực kỳ kém hiệu quả, nhàm chán và bực bội hơn nhiều so với lập trình solo và dẫn đến mã chất lượng thấp hơn.