Trong các đánh giá mã, người đánh giá có nên luôn đưa ra giải pháp cho các vấn đề không? [đóng cửa]

Khi xem xét mã, tôi thường cố gắng đưa ra các khuyến nghị cụ thể về cách giải quyết các vấn đề. Nhưng do thời gian có hạn mà người ta có thể dành để xem xét, điều này không phải lúc nào cũng hoạt động tốt. Trong những trường hợp này, tôi thấy hiệu quả hơn nếu nhà phát triển tự đưa ra giải pháp.

Hôm nay tôi đã xem lại một số mã và thấy rằng một lớp rõ ràng không được thiết kế tốt. Nó có một số thuộc tính tùy chọn chỉ được gán cho một số đối tượng nhất định và để trống cho các đối tượng khác. Cách tiêu chuẩn để giải quyết điều này sẽ là tách lớp và sử dụng kế thừa. Tuy nhiên trong trường hợp cụ thể này, giải pháp này dường như quá phức tạp. Bản thân tôi không tham gia vào việc phát triển phần mềm này và không quen thuộc với tất cả các mô-đun. Vì vậy, tôi không cảm thấy đủ hiểu biết để đưa ra quyết định cụ thể.

Một trường hợp điển hình khác mà tôi đã trải qua nhiều lần là tôi thấy một hàm rõ ràng là vô nghĩa hoặc thậm chí sai lệch, tên lớp hoặc tên biến nhưng bản thân tôi không thể đưa ra một cái tên hay.

Vì vậy, nói chung, với tư cách là một nhà phê bình, có ổn không khi nói "mã này bị sai sót bởi vì ..., làm khác đi" hoặc bạn phải đưa ra một giải pháp cụ thể?

Là người đánh giá, công việc của bạn là kiểm tra xem một đoạn mã (hoặc tài liệu) có đáp ứng các mục tiêu nhất định đã được thỏa thuận trước khi đánh giá hay không.

Một số trong những mục tiêu này thường sẽ liên quan đến một cuộc gọi phán xét cho dù mục tiêu đã được thực hiện hay chưa. Ví dụ, mục tiêu mà mã phải được duy trì thường yêu cầu một cuộc gọi phán xét.

Là một nhà phê bình, công việc của bạn là chỉ ra nơi mà các mục tiêu chưa được đáp ứng và đó là công việc của tác giả để đảm bảo rằng công việc của mình thực sự đáp ứng các mục tiêu. Theo cách này, công việc của bạn không phải là sửa lỗi như thế nào.

Mặt khác, chỉ cần nói với tác giả "điều này là thiếu sót. Khắc phục nó" thường không dẫn đến một bầu không khí tích cực trong đội. Đối với một bầu không khí tích cực, tốt nhất là ít nhất chỉ ra lý do tại sao một cái gì đó không hoàn hảo trong mắt bạn và để cung cấp một sự thay thế tốt hơn nếu bạn có.
Bên cạnh đó, nếu bạn đang xem xét một cái gì đó có vẻ "sai" nhưng bạn không thực sự có giải pháp thay thế tốt hơn, thì bạn cũng có thể để lại nhận xét dọc theo dòng "Mã / thiết kế này không phù hợp với tôi, nhưng tôi không có một sự thay thế rõ ràng. Chúng ta có thể thảo luận về điều này? " và sau đó cố gắng để có được một cái gì đó tốt hơn với nhau.

Một số câu trả lời tốt ở đây, nhưng tôi nghĩ thiếu một điểm quan trọng. Nó tạo ra một sự khác biệt lớn mà bạn đang xem xét mã, người đó có kinh nghiệm như thế nào và người đó xử lý các đề xuất đó như thế nào. Nếu bạn biết rõ về đồng đội của mình và bạn mong đợi một lưu ý như "mã này bị sai sót bởi vì ..., hãy làm khác đi" để đủ để anh ấy hoặc cô ấy đưa ra giải pháp tốt hơn, thì một nhận xét như vậy có thể ổn. Nhưng chắc chắn có những người mà một nhận xét như vậy là không đủ, và những người cần được nói chính xác làm thế nào để cải thiện mã của họ. Vì vậy, IMHO đây là một cuộc gọi phán xét mà bạn chỉ có thể thực hiện cho trường hợp cá nhân.

Vì vậy, nói chung, với tư cách là một nhà phê bình, có ổn không khi nói "mã này bị lỗi, làm khác đi" hoặc bạn phải đưa ra một giải pháp cụ thể?

Cả hai đều là IMO lý tưởng. Điều tốt nhất để làm là nói chuyện với tác giả và khắc phục vấn đề hợp tác.

Đánh giá mã không phải là không đồng bộ. Rất nhiều vấn đề sẽ mở khóa nếu bạn ngừng xem chúng là một quá trình quan liêu và mất một ít thời gian để giao tiếp trực tiếp.

Trong các đánh giá mã, người đánh giá có nên luôn đưa ra giải pháp cho các vấn đề không?

Không. Nếu bạn đang làm rằng bạn không phải là người đánh giá, bạn là người viết mã tiếp theo.

Trong các đánh giá mã, người đánh giá có bao giờ nên trình bày một giải pháp cho các vấn đề không?

Không. Công việc của bạn là truyền đạt vấn đề trong tầm tay. Nếu trình bày một giải pháp làm cho vấn đề rõ ràng thì làm điều đó. Chỉ không mong đợi tôi làm theo giải pháp của bạn. Điều duy nhất bạn có thể làm ở đây là đưa ra quan điểm. Bạn không được ra lệnh thực hiện.

Khi nào một nhà phê bình nên trình bày một giải pháp cho các vấn đề?

Khi đó là cách hiệu quả nhất để giao tiếp. Chúng tôi mã khỉ không phải chuyên ngành tiếng Anh. Đôi khi cách tốt nhất để chỉ ra rằng mã hút ... ít hơn tối ưu ... là hiển thị cho họ mã ít hút hơn ... là nhiều lựa chọn hơn ... ôi chết tiệt, bạn hiểu ý tôi là gì.

Vấn đề chính là nếu mọi người biết cách viết mã tốt hơn, họ thường sẽ làm như vậy ngay từ đầu. Việc một lời phê bình có đủ cụ thể hay không phụ thuộc rất nhiều vào kinh nghiệm của tác giả. Các lập trình viên rất có kinh nghiệm có thể có một lời chỉ trích như "lớp này quá phức tạp" và quay lại bảng vẽ và tìm ra thứ gì đó tốt hơn, bởi vì họ vừa có một ngày nghỉ vì đau đầu hoặc bị cẩu thả vì họ vội vàng

Thông thường, mặc dù, bạn ít nhất phải xác định nguồn gốc của biến chứng. "Lớp học này quá phức tạp vì nó vi phạm Luật Demeter ở mọi nơi." "Lớp này trộn lẫn các trách nhiệm của lớp trình bày và lớp liên tục." Học cách xác định những lý do đó và giải thích ngắn gọn chúng là một phần của việc trở thành một nhà phê bình tốt hơn. Bạn hiếm khi phải đi vào rất nhiều chi tiết về các giải pháp.

Có hai loại lập trình viên xấu: những người không tuân theo các thực hành tiêu chuẩn và những loại "chỉ" tuân theo các thực tiễn tiêu chuẩn.

Khi tôi đã hạn chế liên hệ công việc / cung cấp phản hồi cho ai đó, tôi sẽ không nói: "Đây là một thiết kế tồi." nhưng một cái gì đó như "Bạn có thể giải thích lớp này cho tôi?" Bạn có thể phát hiện ra đó là một giải pháp tốt, nhà phát triển chân thành đã làm tốt nhất có thể hoặc thậm chí công nhận rằng đó là một giải pháp tồi, nhưng nó đủ tốt.

Tùy thuộc vào phản hồi, bạn sẽ có ý tưởng tốt hơn về cách tiếp cận từng tình huống và con người. Họ có thể nhanh chóng nhận ra vấn đề và tự mình tìm ra cách khắc phục. Họ có thể yêu cầu giúp đỡ hoặc sẽ cố gắng tự mình giải quyết.

Có những thực tiễn được đề xuất trong kinh doanh của chúng tôi, nhưng hầu như tất cả chúng đều có ngoại lệ. Nếu bạn hiểu dự án và cách nhóm tiếp cận nó, đó có thể là bối cảnh để xác định mục đích của việc xem xét mã và cách giải quyết các mối quan tâm.

Tôi nhận ra đây là một cách tiếp cận vấn đề hơn là một giải pháp rõ ràng. Sẽ có quá nhiều thay đổi để bao gồm tất cả các tình huống.

Khi tôi xem lại mã, tôi chỉ cung cấp một giải pháp cho các vấn đề mà tôi xác định nếu tôi có thể làm như vậy với ít nỗ lực. Tôi cố gắng cụ thể về những gì tôi nghĩ rằng vấn đề là mặc dù, tham khảo lại tài liệu hiện có nếu có thể. Yêu cầu người đánh giá cung cấp giải pháp cho mọi vấn đề được xác định sẽ tạo ra động cơ đồi trụy - nó sẽ không khuyến khích người đánh giá chỉ ra vấn đề.

Ý kiến ​​của tôi sẽ mạnh mẽ hơn đối với việc không cung cấp mã trong phần lớn các trường hợp, vì một số lý do:

• Nếu lời giải thích tự nó là không đủ, họ luôn có thể yêu cầu một mẫu về những gì bạn nghĩ về.
• Bạn sẽ không lãng phí thời gian của mình bằng cách cố gắng làm quen với một số mã mà bạn đã chạm vào trong một thời gian dài, chỉ để sửa đổi nó một chút, trong khi một người khác chỉ dành thời gian của họ để làm điều đó.
• Nếu họ đã quen thuộc với đoạn mã này và bạn thì không, chỉ đưa ra phản hồi có thể dẫn đến mã tốt hơn bạn sẽ viết. Cung cấp cho ai đó một giải pháp sẵn sàng thường sẽ khiến họ chỉ sử dụng nó, mà không xem xét cải thiện nó hơn nữa.
• Luôn luôn cung cấp một giải pháp là biên giới hạ thấp. Bạn đang làm việc với ai đó, hy vọng vì họ đủ tốt để được thuê. Nếu bạn quản lý để tìm hiểu lý do tại sao một cái gì đó là một ý tưởng tồi, tại sao họ sẽ không học nó bằng cách lắng nghe phản hồi và tự thực hiện nó?
• Luôn luôn cung cấp một giải pháp chỉ là lạ. Hãy tưởng tượng bạn đang lập trình cặp tại bàn của họ: họ vừa hoàn thành một vài dòng mà bạn cho là không tuyệt vời. Bạn chỉ cần nói với họ những gì bạn phát hiện và tại sao, hoặc bạn lấy bàn phím của họ và hiển thị phiên bản của bạn ngay lập tức? Đây là những gì luôn cung cấp giải pháp của bạn có thể cảm thấy như những người khác.
• Bạn luôn có thể nói những gì bạn làm thay vào đó, mà không dành thời gian để thực sự viết nó. Bạn đã làm điều đó khi mô tả vấn đề đầu tiên trong câu hỏi.
• Đừng đưa thức ăn ra, dạy cách câu cá;)

Chắc chắn, có một số trường hợp bạn đang nghĩ đến một số thay thế cụ thể, và nó đáng để gắn nó. Nhưng đó thực sự là hiếm trong kinh nghiệm của tôi. (rất nhiều đánh giá, các dự án lớn) Tác giả ban đầu luôn có thể yêu cầu bạn lấy mẫu nếu họ cần.

Ngay cả sau đó, vì lý do thứ 3, khi đưa ra một mẫu, có thể đáng nói ví dụ "sử dụng x.foo()sẽ làm cho việc này đơn giản hơn" chứ không phải là một giải pháp đầy đủ - và để tác giả viết nó. Điều này cũng tiết kiệm thời gian của bạn.

Tôi nghĩ rằng chìa khóa để đánh giá mã là đồng ý với các quy tắc trước khi đánh giá.

Nếu bạn có một bộ quy tắc rõ ràng thì không cần phải đưa ra giải pháp. Bạn chỉ cần kiểm tra rằng các quy tắc đã được tuân theo.

Lần duy nhất câu hỏi về một người thay thế sẽ xuất hiện là nếu nhà phát triển ban đầu không thể nghĩ ra cách nào để thực hiện tính năng phù hợp với các quy tắc. Giả sử bạn có yêu cầu về hiệu suất, nhưng tính năng này mất nhiều thời gian hơn ngưỡng của bạn sau vài lần thử tối ưu hóa.

Tuy nhiên! nếu quy tắc của bạn là chủ quan "Tên phải được tôi chấp thuận!" sau đó, có, bạn vừa bổ nhiệm chính mình người đặt tên và nên yêu cầu danh sách các tên được chấp nhận.

Ví dụ về kế thừa (tham số tùy chọn) của bạn có lẽ tốt hơn, vì tôi đã thấy các quy tắc xem lại mã cấm các phương thức dài và 'quá nhiều' tham số hàm. Nhưng thông thường những điều này có thể được giải quyết tầm thường bằng cách chia tách. Đó là phần "giải pháp này dường như quá phức tạp", trong đó tính khách quan của bạn đang xâm nhập và có lẽ cần có sự biện minh hoặc giải pháp thay thế.

Nếu một giải pháp tiềm năng là nhanh chóng và dễ dàng để gõ, tôi cố gắng đưa nó vào bình luận đánh giá ngang hàng của tôi. Nếu không, tôi ít nhất liệt kê mối quan tâm của tôi và lý do tại sao tôi thấy mục cụ thể đó có vấn đề. Trong trường hợp tên biến / hàm mà bạn không thể nghĩ ra thứ gì tốt hơn, tôi thường, thừa nhận rằng tôi không có ý tưởng nào tốt hơn và kết thúc nhận xét dưới dạng câu hỏi mở trong trường hợp ai đó có thể . Theo cách đó, nếu không ai đưa ra một lựa chọn tốt hơn, đánh giá sẽ không thực sự được tổ chức.

Đối với ví dụ bạn đã đưa ra trong câu hỏi của mình, với lớp được thiết kế kém. Tôi sẽ để lại một số ý kiến ​​rằng trong khi có vẻ như nó có thể là quá mức cần thiết, thừa kế có lẽ là cách tốt nhất để giải quyết vấn đề mà mã đang cố gắng giải quyết và để nó ở đó. Tôi sẽ cố gắng diễn đạt theo cách chỉ ra rằng đó không phải là công cụ chặn hiển thị và tùy thuộc vào quyết định của nhà phát triển có nên sửa hay không. Tôi cũng sẽ mở ra một xác nhận rằng bạn không đặc biệt quen thuộc với phần mã đó và mời các nhà phát triển và / hoặc người đánh giá hiểu biết hơn để làm rõ nếu có lý do nào đó đã xảy ra như vậy.

Đi và nói chuyện với người mà bạn đang xem xét mã. Nói với họ một cách thân thiện, rằng bạn thấy hơi khó hiểu, và sau đó thảo luận với họ về cách làm cho nó rõ ràng hơn.

Giao tiếp bằng văn bản dẫn đến một lượng lớn thời gian lãng phí, cũng như phẫn nộ và hiểu lầm.

Mặt đối mặt, băng thông cao hơn nhiều, và người ta có kênh phụ cảm xúc để ngăn chặn sự thù địch.

Nếu bạn thực sự nói chuyện với anh chàng, điều đó nhanh hơn nhiều, và bạn có thể kết bạn mới và thấy rằng cả hai bạn đều thích công việc của mình hơn.