Nếu bạn ghép nối chương trình, bạn có cần đánh giá ngang hàng không?

Question

Tôi nghĩ rằng đánh giá ngang hàng là một phần rất tốt trong quá trình phát triển, họ thường bắt hoặc hỏi những điều không rõ ràng khi mã được viết ban đầu và giúp bạn tự ý thức hơn để định dạng tốt hơn, đưa vào nhận xét, v.v.

Tuy nhiên, nếu bạn là lập trình ghép đôi, bạn có một đánh giá ngang hàng trực tiếp một cách hiệu quả, vì vậy bạn có nên xem xét ngang hàng như một phần của quy trình không? Bạn có thể có các bài đánh giá ngang hàng không?

Tôi hỏi khi lập trình ghép đôi bắt đầu xảy ra ở nơi tôi làm việc và thường được coi là thay thế cho đánh giá ngang hàng. Tôi không chắc lắm, nhưng hãy nghĩ rằng thời gian dành cho nhà phát triển dành cho việc lập trình cặp và đánh giá ngang hàng có thể làm hỏng năng suất.

Có một similar question một khi trở lại nhưng với sự nhấn mạnh khác nhau và không có sự đồng thuận rõ ràng

Answer 1

Điều đó phụ thuộc.

Mục tiêu của một đánh giá ngang hàng, theo ý kiến ​​của tôi, không chỉ tìm lỗi trực tiếp đến mã được viết mà còn đảm bảo rằng mã cũng sẽ hoạt động tốt với cơ sở mã tồn tại. Đôi khi, bạn có thể muốn liên quan đến chuyên gia về mã bạn đang viết và có thể không phải là thành viên của cặp.

Ví dụ: nếu bạn viết phần Đồ họa 3D của một ứng dụng, bạn có thể muốn chuyên gia OpenGL xem xét nó.

Vì vậy, tùy thuộc vào hoàn cảnh, bạn có thể muốn có cặp mắt thứ ba để xem xét vấn đề của mình. Người này thậm chí có thể không được thu thập (trong một múi giờ khác hoặc một cái gì đó).

Ngoài ra, khi bạn ghép nối, bạn có thể có xu hướng suy nghĩ giống nhau. Vì vậy, một ý kiến ​​khác có thể mở mắt của bạn về một cái gì đó bạn bị mất.

Nếu nhà phát triển của tôi ghép nối mã, tôi vẫn sẽ kích động họ để xem xét mã của họ nếu họ không phải là chuyên gia 100% trong phần đó của mã.

Answer 2

Nếu các đối tác thay đổi trong lập trình cặp, sau đó về cơ bản bạn có đánh giá ngang hàng tự động (thậm chí nhiều hơn chỉ là một đôi mắt "thêm"). Và trong trường hợp cả hai lập trình viên không chắc chắn về cách làm điều gì đó, họ có thể (nên) vẫn yêu cầu trợ giúp, điều này lại dẫn đến một số đánh giá ngang hàng.

Answer 3

Tôi nghĩ đánh giá ngang hàng vẫn quan trọng bởi vì bộ óc liên quan đến cả hai trường hợp khá khác nhau tại thời điểm lập trình bộ trí thông thường không quan trọng trong khi thực hiện đánh giá ngang hàng mà suy nghĩ là phân tích quan trọng giống như nhận được kiểm tra thủ công được thực hiện bởi cùng một devloper người đã bị lệch nó sẽ không được tốt như nhận được nó thực hiện từ một thử nghiệm

Answer 4

Chuyển đổi cặp được thiết kế để giải quyết vấn đề đánh giá ngang hàng. Khi nhà phát triển tham gia vào cặp mới, anh/cô ấy phải hiểu vấn đề anh ta/cô ấy sẽ làm việc. Và sự hiểu biết bao gồm việc xem xét.

Tôi tin rằng chỉ những chuyên gia được tách riêng mới đánh giá các điểm quan trọng của hệ thống là bắt buộc.

Answer 5

Ghép là đánh giá ngang hàng. Hoặc như XP nói, nếu một cái gì đó là tốt sau đó mang nó đến cùng cực. Nếu đánh giá ngang hàng là tốt, hãy thực hiện nó liên tục tức là, lập trình ghép đôi.

Khi lập trình ghép nối được thực hiện đúng và các cặp được xoay vòng thường xuyên, bạn sẽ thực hiện các đánh giá ngang hàng liên tục của tất cả các mã được phát triển.Tốt hơn, mã được xem xét vì nó được thiết kế, thử nghiệm và viết (có, viết bài kiểm tra đầu tiên A.K.A Test Driven Development) không phải sau khi mã đã được viết và tốn kém hơn để sửa chữa.

Mã đánh giá ngang hàng nhưng là một lợi thế của lập trình ghép nối. Những lợi thế khác là:

Cải thiện chất lượng: Một cặp lập trình viên tích cực làm việc trên các thẻ cùng một câu chuyện sẽ hoàn thành thẻ với khiếm khuyết ít

Cải thiện năng suất: một cặp là ít có khả năng bị chậm lại nếu không hoàn toàn bị chặn khi giải quyết một vấn đề. Hơn nữa, bạn khó có thể nhận email hoặc kỳ nghỉ trên web khi bạn đang làm việc với đối tác ... bạn không muốn để đối tác thất vọng. Bạn sẽ giải quyết vấn đề với thiết kế gọn gàng hơn và ít dòng mã hơn khi làm việc như một cặp

Loại bỏ các kiến ​​thức về doanh nghiệp: Với các cặp xoay, bạn sẽ tìm hiểu kiến ​​thức về ứng dụng và miền. Nhóm này ít có khả năng bị chặn bởi vì Sue đã đi nghỉ và không ai biết mã của cô ấy.

Chuyển giao kỹ năng: Cặp quay dạy kỹ năng mới (kỹ thuật và miền) với nhau khi chúng hoạt động cùng nhau. Cấp độ của đội sẽ tăng lên cho mọi người và kiến ​​thức truyền bá thông qua đội.

Nhóm tự chọn: Nhóm học được một kỹ năng của người phản đối và nhanh chóng loại bỏ những người không thực hiện.