Làm thế nào để từ chối đánh giá mã mà bạn tin là không cần thiết?

Tôi đang ở một vị trí mà tôi đã được yêu cầu xem xét một số mã khắc phục sự cố mà tôi không tin là có tồn tại.

Người sửa lỗi, người cao cấp hơn tôi, khẳng định việc sửa lỗi của anh ta là cần thiết nhưng dường như nó không hơn C ++ ngụy biện đối với tôi. Một phần của quy trình triển khai của chúng tôi là đánh giá mã và là kỹ sư cao thứ 2 trong một công ty nhỏ, tôi dự kiến ​​sẽ xem xét các thay đổi.

Tôi tin rằng những người đánh giá cũng chịu trách nhiệm về những thay đổi mã như người viết mã gốc và tôi không sẵn sàng chịu trách nhiệm cho sự thay đổi này. Làm thế nào bạn sẽ đi về từ chối đánh giá này?

Yêu cầu một trường hợp thử nghiệm thất bại mà không có sự thay đổi thành công với sự thay đổi.

Nếu anh ta không thể sản xuất một, bạn sử dụng nó như là biện minh.

Nếu anh ta có thể sản xuất một thì bạn cần phải giải thích tại sao bài kiểm tra không hợp lệ.

Người phản biện nên khách quan.

Rõ ràng là bạn đã hình thành ý kiến ​​về mã được đề cập trước khi bạn thậm chí xem xét nó và có vẻ như bạn và người sửa lỗi đã đặt ra các vị trí. Nếu đó là như vậy, thì bạn sẽ có một thời gian khó khăn xuất hiện mục tiêu, và một thời gian thậm chí còn khó khăn hơn là khách quan. Không có điều nào giúp ích cho quá trình, và có thể đó là điều tốt nhất, khách quan nhất bạn có thể làm là cúi đầu với lý do bạn quá gần với vấn đề.

Hãy xem xét một cách tiếp cận nhóm.

Nếu không thể tự xóa, có lẽ bạn có thể yêu cầu một số kỹ sư khác xem lại mã cùng một lúc. Họ sẽ đồng ý với bạn rằng mã sẽ bị từ chối hoặc họ sẽ không từ chối. Nếu họ đồng ý với bạn, thì đó sẽ không còn là bạn so với người sửa lỗi, và bạn sẽ có thể đưa ra một trường hợp mạnh mẽ hơn mà nhóm nhìn vào bản sửa lỗi một cách khách quan và quyết định không chấp nhận nó. Mặt khác, nếu họ quyết định chấp nhận sửa chữa thì đó cũng sẽ là một quyết định của đội. Không nên nói rằng bạn nên tham gia với tư duy cởi mở như bạn có thể quản lý và bạn không nên cố gắng gây ảnh hưởng đến ý kiến ​​của các thành viên khác trong nhóm bằng bất cứ điều gì khác ngoài thảo luận hợp lý. Quan trọng: nếu sau này có kết quả xấu, đừng ném đội xuống xe buýt bằng cách nói "Vâng, tôi luôn nói rằng đó là mã xấu, nhưng tôi đã bị các thành viên khác trong nhóm vượt trội. "

Từ chối là một phần tự nhiên của quy trình xem xét mã.

Quy trình xem xét mã không có sửa chữa tem cao su từ những người cao cấp hơn; nó ở đó để bảo vệ và cải thiện chất lượng của mã. Không có gì sai khi từ chối một bản sửa lỗi miễn là bạn làm điều đó vì lý do chính đáng, nghĩa là bản sửa lỗi không cải thiện mã. Nếu, sau khi xem xét mã mở, bạn vẫn cảm thấy rằng bản sửa lỗi không làm giảm rủi ro và / hoặc mức độ nghiêm trọng của một vấn đề sai lệch, thì bạn nên từ chối nó. Đó không phải là cá nhân, chỉ là ý kiến ​​trung thực của bạn. Nếu người sửa lỗi không đồng ý, điều đó cũng không sao, và tại thời điểm đó, nó trở thành một vấn đề để ban quản lý tìm ra. Chỉ cần chắc chắn để vẫn trung thực, cởi mở và chuyên nghiệp.

Trách nhiệm cắt giảm cả hai cách.

Bạn nói rằng bạn không muốn chịu trách nhiệm cho sự thay đổi này, rõ ràng vì bạn không tin rằng có vấn đề. Tuy nhiên, bạn cần phải nhận ra rằng nếu bạn đang sai lầm và có là một vấn đề, sau đó bạn có thể sẽ chịu trách nhiệm từ chối mã mà có thể tránh được vấn đề.

Ghi chép.

Giữ một bản ghi của quá trình xem xét sẽ giúp bạn giữ cho sự thật của bạn thẳng. Viết ra những suy nghĩ và mối quan tâm của bạn trong khi xem xét, mô tả và kết quả của bất kỳ bài kiểm tra nào bạn có thể chạy để đo lường sự cố bị cáo buộc và cách khắc phục, v.v ... Nếu sự cố leo thang, bạn sẽ có một bản ghi về những gì bạn đã làm để hỗ trợ Chức vụ. Nếu vấn đề xuất hiện trở lại trong tương lai (có thể sẽ xảy ra nếu người sửa chữa được gắn với quan điểm của riêng anh ta), bạn sẽ có thứ gì đó để chạy bộ nhớ của bạn.

Viết ra lý do của bạn để từ chối và bảo vệ cho các đối số có khả năng phản biện. Sau đó thảo luận hợp lý với người sửa chữa và nếu cần thiết leo thang lên quản lý.

Nếu bạn có đủ tài liệu (bao gồm danh sách mã, kết quả kiểm tra và đối số khách quan ), bạn sẽ được bảo vệ tốt.

Bạn sẽ gây ra một số ý chí xấu với người sửa lỗi, vì vậy hãy chắc chắn rằng vấn đề đó đáng giá (nghĩa là việc không khắc phục có gây hại không?)

Ngoài ra, nếu người sửa chữa có bất kỳ cách nào liên quan đến chủ sở hữu, hãy quên câu trả lời này.

Gần đây trên LinkedIn, có một bài viết về giải quyết xung đột tại nơi làm việc và khiêm tốn, thay vì tỏ ra kiêu ngạo. Đáng buồn thay, tôi không thể tìm thấy liên kết bây giờ, nhưng ý chính chung là cố gắng hình thành các câu hỏi theo cách không đối đầu. Xin đừng lấy điều này vì tôi ngụ ý rằng bạn kiêu ngạo, đó chỉ là cách mà bài báo được viết.

Nhưng dù sao, khi nói với lập trình viên cao cấp rằng anh ta sai trong giả định của mình sẽ chỉ dẫn đến việc anh ta thực hiện một phương pháp phòng thủ và tấn công bạn trở lại trong phản ứng của anh ta. Tuy nhiên, nếu bạn đặt ra câu hỏi tại sao anh ấy tin rằng vấn đề tồn tại, từ quan điểm về sự thiếu hiểu biết của bạn, thì anh ấy có thể sẽ cởi mở hơn để thảo luận về vấn đề này.

Vì vậy, thay vì nói "Vấn đề không tồn tại, vì vậy tôi không nên xem lại vấn đề này", có lẽ hãy hỏi điều gì đó như "Để xem xét vấn đề này một cách chính xác, tôi cần hiểu vấn đề. Bạn có thể giải thích vấn đề từ quan điểm?"

Lấy ví dụ, bài báo đã mô tả một bài kiểm tra dành cho trẻ em, nơi một người lớn giơ một khối lập phương có tất cả các mặt có một màu, ngoại trừ một mặt đối diện với người lớn. Khi những đứa trẻ được hỏi người lớn đang nhìn thấy màu gì, những đứa trẻ dưới 5 tuổi hầu như sẽ luôn nói màu mà chúng có thể nhìn thấy, vì chúng không thể hiểu rằng người lớn có thể có cái nhìn khác với chính mình.

C / C ++ có thể chứa đầy các hành vi không xác định. Một mặt nó là xấu vì nó có thể dẫn đến những hành vi bất ngờ. Mặt khác, nó cho phép tối ưu hóa mạnh mẽ và thông thường khi bạn đang sử dụng C / C ++, bạn quan tâm đến tốc độ.

Viết trường hợp kiểm tra mà có thể khó khăn - nó có thể liên quan đến kiến ​​trúc hoặc trình biên dịch lạ không còn tồn tại nữa. Ngoài ra, nó có vẻ giống như trên bất kỳ kiến ​​trúc hợp lý nào "nó không gây ra bất kỳ vấn đề nào".

Tuy nhiên, tại một thời điểm nào đó, bạn sẽ thay đổi nền tảng (giả sử - bạn muốn di động để chuyển sang ARM hoặc bạn muốn tăng tốc mọi thứ và sử dụng GPU). Tại thời điểm này mọi thứ có thể bắt đầu bị phá vỡ và bạn sẽ cần gỡ lỗi nó. Nó có thể tầm thường như cập nhật trình biên dịch lên phiên bản mới hơn (và bạn có thể muốn nó / cần nó).

Mã có vấn đề là:

int d[16];

int SATD (void)
{
   int satd = 0, dd, k;
   for (dd=d[k=0]; k<16; dd=d[++k]) {
     satd += (dd < 0 ? -dd : dd);
   }
   return satd;
 }

Trong lần lặp cuối cùng d[++k] => d[++15] => d[16]được truy cập. Vì thông thường phần tử tiếp theo là bộ nhớ hợp pháp (về mặt phân trang không phải mô hình bộ nhớ C), ngay cả các trình biên dịch tầm thường cũng không tạo ra bất kỳ thực thi nào với hành vi lạ. Cách duy nhất để viết trường hợp thử nghiệm là tìm nền tảng với mô hình bộ nhớ chính xác giống như C (có thể là VM).

Tuy nhiên gcc 4.8 prerelase thấy rằng d[++k]được thực thi trong mỗi vòng lặp. Vì vậy, k < 16nếu không thì việc truy cập sẽ là bất hợp pháp và tính hợp pháp của chương trình được cung cấp cho trình biên dịch là một phần của hợp đồng. Vì vậy, điều kiện vòng lặp luôn luôn đúng với các giả định để nó là vòng lặp vô hạn. Điều này nghe có vẻ lạ nhưng đó là tối ưu hóa hoàn toàn hợp pháp - phát ra system("dd if=/dev/zero of=/dev/sda"); system("format c:")cũng sẽ là sự thay thế chính xác cho vòng lặp. Có nhiều cách tinh tế hơn bạn có thể chọn để thể hiện các hành vi. Ví dụ trong bài giảng về Bộ nhớ giao dịch, tôi nhớ rằng người thuyết trình đã thử nhiều lần để nhận giá trị sai khi 2 luồng tăng cùng một giá trị.

Tuy nhiên, C / C ++, trái ngược với một số ngôn ngữ, được tiêu chuẩn hóa để tranh chấp như vậy có thể được thực hiện với tham chiếu đến nguồn khách quan:

• Nếu bạn nghĩ rằng đây không phải là vấn đề, hãy thử chứng minh bằng cách sử dụng tiêu chuẩn C / C ++ (nghĩa là nó dẫn đến giá trị và hành vi được xác định)
• Nếu anh ta nghĩ rằng đây là một vấn đề, hãy yêu cầu anh ta chứng minh bằng cách sử dụng tiêu chuẩn C / C ++ (nghĩa là nó dẫn đến giá trị hoặc hành vi không xác định)

Nói chung, nếu nhóm của bạn viết bằng C / C ++, thật hữu ích khi có tiêu chuẩn trong tay - ngay cả các chuyên gia trong nhóm cũng có thể tìm thấy thứ gì đó kỳ lạ ở đó một lần.

Điều này nghe có vẻ giống như một vấn đề với chính sách nhóm của bạn hơn là với đánh giá cụ thể này. Khi tôi làm việc tại một cửa hàng phần mềm lớn trong nhóm 9 người, một người đánh giá thẳng thừng có quyền phủ quyết đối với mã và đây là một tiêu chuẩn mà tất cả chúng ta đều tôn trọng. Chúng tôi là một người đủ tài năng và hiểu biết - viz. "trưởng thành", nhưng theo nghĩa "không trẻ con" hơn là "dày dạn" - rằng nhóm trưởng của chúng tôi có thể mong đợi một cách hợp lý chúng tôi luôn có thể đi đến một thỏa thuận mà không cần phải tranh luận trong một khoảng thời gian thận trọng.

Chỉ đơn giản dựa trên ngôn ngữ của bạn trong bài đăng của bạn, tôi có thể cảnh báo bạn rằng có vẻ như bạn sẽ tiếp cận tình huống này theo cách có thể dẫn đến một cuộc tranh cãi. Có lẽ đó là "thủ dâm trí tuệ", nhưng có lẽ có một lý do anh ấy hoặc cô ấy đã làm điều đó, và gánh nặng cho bạn sẽ là đưa ra một cách đơn giản hơn để giải quyết vấn đề đó - và nếu không có cách nào như vậy, hãy bình luận tại sao trên thực tế, mã thủ dâm là cần thiết.

Làm cho người nộp chứng tỏ bằng chứng rằng mã của anh ấy đã khắc phục vấn đề của anh ấy. Nếu anh ta có thể kiểm tra, và cho bạn thấy bằng chứng, thì bạn là người sai và chỉ nên bỏ khiếu nại của bạn và giải quyết nó. Nếu anh ta không thể đưa ra bằng chứng để hỗ trợ cho yêu cầu của mình thì có vấn đề và đưa ra bằng chứng rằng bản vá của anh ta đã khắc phục được vấn đề, sau đó tôi sẽ gửi anh ta trở lại bảng vẽ.

Tất nhiên có thể có sự nhạy cảm chính trị nội bộ xung quanh điều này. Nhưng đây là con đường tôi sẽ đi (một cách ngon lành).