Liệu lập trình cặp có loại bỏ nhu cầu đánh giá mã trong dự án Lập trình cực đoan (XP) không?


14

Trong một dự án lập trình cực đoan, các lập trình viên thường lập trình cặp đôi.

Vì các cặp này cũng xoay vòng, nghĩa là bạn ghép chương trình với những người khác nhau và có ý thức sở hữu tập thể, mã nguồn thường xuyên được xem xét và cập nhật.

Được như vậy, có cần phải đánh giá mã? Ý tôi là, dừng lập trình và thực sự chỉ làm đánh giá mã.


3
Lập trình cặp chỉ là đối tượng thuê của XP. Có nhiều phương pháp nhanh khác không theo XP. Không có gì trong Tuyên ngôn phát triển phần mềm Agile cũng như các nguyên tắc đằng sau Tuyên ngôn Agile đề cập đến lập trình cặp. Cũng không có gì về đánh giá mã. Điều quan trọng của nó là không cho rằng tất cả nhanh nhẹn là cực đoan.

Hãy để tôi viết lại câu hỏi của tôi để chỉ bao gồm XP sau đó.
Eduardo Copat

Có một lý do tại sao bạn sẽ không thử nó và đảm bảo bạn đặt một số tiêu chí để dừng lại? Nếu nhóm cảm thấy thoải mái với mã được đăng ký, đó sẽ là một lý do đủ tốt.
JeffO

Câu trả lời:


13

Một trong những tài nguyên quan trọng cho Lập trình cực đoan là Wiki của Ward hay còn gọi là Kho lưu trữ mẫu Portland hay còn gọi là C2.com . Đây là nơi một số người băm ra các phương pháp khác nhau và ghi lại chúng khi họ sử dụng chúng.

Trong wiki này, có một trang: Đánh giá mã lập trình cực đoan có một số người đóng góp cho nó, bao gồm Ron Jeffries và Kent Beck.

Về vấn đề này, họ nói:

Đánh giá mã được coi là quan trọng bởi nhiều bậc thầy quy trình lớn. Chúng nhằm đảm bảo sự phù hợp với các tiêu chuẩn, và quan trọng hơn là nhằm đảm bảo rằng mã rõ ràng, hiệu quả, hoạt động và có QWAN. Họ cũng có ý định giúp phổ biến kiến ​​thức về mã cho các thành viên còn lại trong nhóm.

ExtremeProgramming yêu cầu tất cả sự phát triển được thực hiện bởi hai kỹ sư làm việc cùng nhau. Các mã thực sự được xem xét trên bay, ở một mức độ khá lớn. Điều này đảm bảo rằng nhiều hơn một người có kiến ​​thức sâu sắc về mã mọi lúc.

ExtremeProgramming yêu cầu tất cả các đối tượng có UnitTests. Chúng đảm bảo rằng đối tượng hoạt động và tiếp tục hoạt động như đã sửa đổi.

Một số ngôn ngữ là phản ánh. Trong các ngôn ngữ như vậy, UnitTests có thể kiểm tra trực tiếp sự phù hợp tiêu chuẩn quan trọng. (ví dụ: các đối tượng phải triển khai cả # = và #hash hoặc không.)

Thực hành ExtremeProgramming CollectiveCodeOwnership, có nghĩa là các đối tượng cần chú ý sẽ được nhiều nhà phát triển duyệt. Điều này có xu hướng mang lại áp lực đối với những mã sản xuất không tuân thủ các tiêu chuẩn. Các nhà phát triển truy cập được khuyến khích / dự kiến ​​sẽ đưa mã phù hợp khi họ tìm thấy độ lệch. Điều này cũng đảm bảo rằng kiến ​​thức về mã được phổ biến ngoài cặp lập trình viên ban đầu đã tạo ra nó.

Do đó, các dự án ExtremeProgramming không yêu cầu đánh giá rõ ràng. Thả chúng từ phương pháp của bạn.

Cũng có khá nhiều thảo luận về chủ đề đó từ những người khác.

Điểm quan trọng mặc dù là với sự kết hợp của các thử nghiệm, quyền sở hữu hợp tác và lập trình cặp, những điều này giải quyết các mục tiêu mà việc đánh giá mã thường được thực hiện như:

  • Phân tán kiến ​​thức về những gì đang được thực hiện
  • Một bộ nhãn cầu thứ hai (hoặc nhiều hơn) trên mã để đảm bảo rằng nó tuân theo các tiêu chuẩn
  • Xác minh chức năng chính xác của mã

Những việc này đang được thực hiện liên tục thông qua lập trình cặp và kiểm tra tự động trong Lập trình cực đoan và do đó việc kiểm tra Fagan rõ ràng là không cần thiết.

Đọc liên quan:


4
Tôi đã lập luận trong một câu hỏi khác rằng đánh giá mã là một sự lãng phí không cần thiết (theo nghĩa Lean của từ này) và lập trình cặp nên là phương pháp ưa thích để cung cấp tất cả các lợi ích mà đánh giá mã sẽ cung cấp. Không cần phải nói, mọi người đã xúc phạm đến lập luận của tôi bởi vì tôi đã không ủng hộ nó với THE VOICE OF AUTHORITY (TM) như bạn có. Đối với một nhóm người đối phó với logic ngày này qua ngày khác, chúng tôi là một nhóm phi logic.
Michael Brown

6
Rủi ro của việc lập trình cặp mà không có đánh giá mã bổ sung là cả hai lập trình viên đều tham gia rất nhiều vào thời điểm viết và họ có thể viết mã có vẻ hoàn toàn rõ ràng và hợp lý tại thời điểm đó, nhưng ít hơn khi gặp lại sau vài ngày. Rủi ro lớn và / hoặc chấp nhận được như thế nào tùy thuộc vào tổ chức của bạn.
Bart van Ingen Schenau

@MikeBrown bạn cũng có thể lập luận rằng Lập trình cặp là một sự lãng phí không cần thiết và việc xem xét mã đó sẽ v.v.
AlexFoxGill

Xem những gì tôi muốn nói bởi WASTE là định nghĩa "Lean" của từ này. Hãy nghĩ về quá trình dây chuyền lắp ráp điển hình. Ý tưởng là để chiếc xe xuống dòng càng nhanh càng tốt và kiểm tra chất lượng được thực hiện sau khi thực tế (xem xét mã). Nguyên tắc tinh gọn nhất là mất thêm một chút thời gian và công sức để xây dựng chất lượng trong (lập trình cặp) để việc kiểm tra bài trở nên không cần thiết.
Michael Brown
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.