Cách tốt nhất để lập trình viên xử lý việc được xem xét mã là gì?

Tôi còn khá mới đối với việc xem xét mã, nhưng tôi đã viết mã được nhiều năm trong suốt tiến sĩ - điều không phải lúc nào cũng khiến bạn trở thành một lập trình viên giỏi!

Nếu người đánh giá thay đổi mã của bạn và chuyển qua mã theo từng dòng, bạn sẽ làm gì nếu bạn không đồng ý? Đôi khi bạn đã chọn X và người đánh giá thay đổi nó thành Y, và bạn có suy nghĩ về Y nhưng quyết định không làm điều đó vì những bất lợi, nhưng người đánh giá khẳng định rằng những bất lợi đó không quan trọng. Bạn có nên xác minh sự bất đồng của bạn, hoặc chỉ không và lắng nghe họ?

Thật khó khăn nếu bạn không giỏi chấp nhận những lời chỉ trích, và nếu người đánh giá là một người cao cấp hơn trong tổ chức. Sẽ không tốt khi đi qua vì quá phòng thủ.

Đúng, đi qua như phòng thủ là không hữu ích; nhưng sau đó - không bị chỉ trích, vì vậy nếu bạn cảm thấy điều này đang xảy ra, bạn thực sự nên nói lên những lo ngại của mình rằng việc xem xét mã không giúp bạn viết mã tốt hơn trong tổ chức.

Người đánh giá có trách nhiệm xem xét mã về sự không tuân thủ và khiếm khuyết thực sự, không sử dụng nó như một phương tiện để viết mã của bạn theo cách họ đã làm. Điều này có nghĩa là đánh giá ở đó để xem xét cách bạn đã làm một cái gì đó và chỉ ra bất kỳ lĩnh vực nào bạn đã mắc lỗi (điều tốt nhất của chúng tôi làm) hoặc không hiểu khuôn khổ hoặc tiêu chuẩn hoặc "lý do lịch sử" một số mã được viết đó là nơi bạn đang ở

Vì vậy, nếu có nhiều cách để làm một cái gì đó, cần phải có một lý do chính đáng tại sao mã của bạn được thay đổi thành một cách khác, nếu không, việc đơn giản là nó không mang tính xây dựng sẽ không giúp bạn.

Ngoài ra, hãy nhớ rằng người đánh giá cũng không hoàn hảo. Họ có thể có ý tưởng rằng Y là cách để làm điều đó và không nhận ra rằng X tốt hơn. Bạn nên giải thích lý do tại sao bạn làm theo cách X. Người đánh giá có thể đồng ý với bạn hoặc anh ta có thể cho bạn biết lý do tại sao Y là giải pháp tốt hơn - có thể có những yếu tố khác mà bạn không biết rằng anh ta làm.

Nói tóm lại, đánh giá là một cách để khiến các thành viên trong nhóm truyền đạt về những thay đổi mã của họ. Vì vậy, nói chuyện với người đánh giá về nó.

NẾU nó giúp, nói chuyện một cách vô tư, như thể bạn thậm chí không phải là tác giả của mã được xem xét. Mã cuối cùng thuộc về công ty hoặc nhóm và nhóm sẽ phải duy trì nó. Bạn tình cờ là người đã viết nó, đó không phải là một yếu tố quan trọng như nhiều người tin.

Viết mã máy tính là một ví dụ điển hình của việc đưa ra quyết định trong sự không chắc chắn . Luôn có những áp lực mâu thuẫn, và cách bạn quyết định trong bất kỳ câu hỏi nào tùy thuộc vào áp lực mà bạn cảm nhận và mức độ lớn của bạn đối với chúng.

Do đó, khi người đánh giá không đồng ý với quyết định của bạn, điều đó có nghĩa là họ thấy áp lực / rủi ro khác với bạn hoặc họ coi một số trong số họ lớn hơn / nhỏ hơn bạn. Bạn phải hoàn toàn nói về những khác biệt này, bởi vì không làm như vậy kéo dài những vấn đề dẫn đến bất đồng ngay từ đầu.

Nếu người đánh giá của bạn có thâm niên hơn, kinh nghiệm của họ có thể nói với họ chính xác rằng rủi ro này hoặc rủi ro đó không liên quan lắm trong thực tế hoặc họ có thể biết rằng một loại lỗi nào đó có lịch sử lâu dài xảy ra trong tổ chức của bạn và đáng để cẩn thận hơn để tránh nó Ngược lại, nếu bạn cảm thấy rằng bạn biết điều gì đó mà người đánh giá của bạn có thể không biết, bạn phải hoàn toàn bày tỏ điều đó; giữ số tiền im lặng cho sự vô chủ của nhiệm vụ về phía bạn.

Phần quan trọng nhất của việc xử lý tình huống là hiểu rằng sự chỉ trích về các quyết định thiết kế hầu như không phải là sự chỉ trích về tính cách của ai đó. (Trong những trường hợp hiếm hoi thực sự là như vậy, bạn sẽ nhận thấy điều đó sớm thôi, và nếu bạn thực sự không thể làm hài lòng ai đó, thì bạn không làm gì khác biệt, vậy tác hại của việc tuân theo các thực tiễn tốt nhất là gì? càng sớm càng tốt.) Đó chỉ là kết quả của những người khác nhau có nhận thức khác nhau về nhiều rủi ro và phần thưởng liên quan đến mã máy tính, và đưa ra mức độ phức tạp của mã máy tính hiện đại, điều đó chỉ được dự kiến. Nói về sự khác biệt giúp cải thiện mã và cải thiện sự hợp tác của bạn trong trường hợp này và trong các trường hợp trong tương lai.

Các câu trả lời khác chứa thông tin rất tốt rồi. Tôi muốn mở rộng một chút về một số khía cạnh đã được gợi ý bởi gbjbaanb (xem bình luận của tôi để trả lời của anh ấy).

Theo kinh nghiệm của tôi, tôi đã quan sát các loại phản hồi khác nhau trong quá trình đánh giá mã:

1. "Tôi thành thật tin rằng điều này là sai / không tối ưu và bạn nên thay đổi nó theo cách này." Tôi thường coi trọng loại phản hồi này và tôi sẽ chỉ phản đối sự thay đổi được đề xuất nếu tôi nghĩ rằng tôi có quan điểm mạnh mẽ chống lại nó.
2. "Tôi thấy giải pháp của bạn ổn, hãy xem xét phương án này nhưng tùy thuộc vào việc bạn có chấp nhận thay đổi hay không." Tôi cũng rất coi trọng loại phản hồi này: người đánh giá đang đề xuất một giải pháp thay thế, mặc dù họ không có ý kiến ​​mạnh mẽ rằng giải pháp của họ là tốt hơn. Tôi có cơ hội học được điều gì đó và tôi sẽ chấp nhận thay đổi nếu tôi thích nó hơn. Mặt khác, người đánh giá thấy nó ổn nếu tôi giữ mã theo sở thích của mình.
3. "Tôi sẽ làm điều đó khác đi để bạn phải thay đổi nó, theo thời gian." Hoặc thậm chí "Ồ, tôi đã thay đổi mã của bạn bởi vì ...", thay đổi chưa được đề xuất, nó đã được cam kết rồi! Một số giải thích nhanh về sự thay đổi được đưa ra, với gợi ý rằng không có nhiều thời gian để thảo luận về các chi tiết vì chúng ta phải chuyển sang nhiệm vụ tiếp theo.
4. Người đánh giá đề xuất những thay đổi nhỏ có tính chất tầm thường không cải thiện mã mà chỉ làm cho nó khác đi. Khi được yêu cầu thảo luận về các thay đổi được đề xuất, người đánh giá sẽ tham gia vào các cuộc thảo luận dài về các chi tiết tầm thường cho đến khi bạn từ bỏ kiệt sức.

Tùy chọn 3, 4 có thể được ngụy trang thành 1 và 2: "Điều thực sự quan trọng là làm theo cách tôi đã đề xuất." hoặc "Bạn có thể từ chối thay đổi nếu bạn thực sự muốn.", nói với giọng điệu thực tế có nghĩa là trái ngược với những gì đang được nói. Trong trường hợp bạn phản đối những thay đổi mà bạn cho là không cần thiết, quyền sở hữu mã được chia sẻ có thể được sử dụng để biện minh cho thái độ này: "Mã không thuộc về bạn, nó thuộc về nhóm!" Bạn có thể biết khi nào ý định của người đánh giá không trung thực nếu người đánh giá không cởi mở để thảo luận, bị kích thích và cố gắng đẩy giải pháp của họ bằng mọi giá. Về cơ bản họ đã quyết định, và bất kỳ cuộc thảo luận nào thêm chỉ là một sự lãng phí thời gian.

Tùy chọn IMO 1 và 2 là dấu hiệu của một nhà phê bình trung thực, người đang cố gắng giúp đỡ, đang cố gắng dạy cho bạn điều gì đó trong khi tôn trọng công việc của bạn và cũng sẵn sàng tự học một điều gì đó. Trong kịch bản này, tôi cố gắng không quá tự hào khi tôi nhận được phản hồi mang tính xây dựng từ một người đánh giá.

Tùy chọn 3, 4 gợi ý rằng có một số trò chơi quyền lực đang diễn ra: điều quan trọng là chúng tôi làm theo cách của tôi hay theo cách của bạn, chứ không phải chúng tôi cố gắng tìm một giải pháp tốt thỏa mãn cả hai. Điều này có thể liên quan đến cái tôi của người đánh giá, nhưng cũng khiến họ không thể hiểu bất kỳ mã nào không theo cách nghĩ của họ. Họ thường bị làm phiền bởi mã trông không quen thuộc với họ và muốn áp đặt theo cách của họ trên toàn bộ cơ sở mã.

Nếu tình huống 3 và 4 xảy ra quá thường xuyên, làm việc nhóm có thể trở nên khá khó chịu. Trong tình huống như vậy tôi sẽ xem xét rời khỏi đội.

Để giải quyết vấn đề của bạn phải làm gì khi bạn không đồng ý ...

Nói nó là cách của chúng tôi để đi như hầu hết mọi người đã chỉ ra.

Nếu bạn đã thực hiện điều đó, có thể hơn một lần, một kỹ thuật hữu ích mà chúng tôi sử dụng là nếu vẫn còn bất đồng trong một số lĩnh vực là nói 'ừ, sẽ tốt hơn khi tái cấu trúc rằng -

Chúng ta có thể đặt một vé riêng cho điều đó không?

Một vé riêng biệt cho phép bạn nhận được mã, thay vì chế độ 'đáng sợ và không bao giờ di chuyển' mà tôi đã biết rõ ở một số nơi. Điều này rất phù hợp với sự nhanh nhẹn, thực hiện số lượng nhỏ nhất 'có thể' và truyền tải. Đôi khi yagni sẽ kết thúc áp dụng. Đôi khi người quản lý sản phẩm sẽ quyết định rằng có nhiều nhu cầu cấp thiết hơn so với công cụ tái cấu trúc đó về mặt giá trị cho khách hàng, thời hạn và tài nguyên.

Đánh giá mã có thể là một điều tốt nói chung, nhưng theo kinh nghiệm của tôi, nó được phục vụ tốt nhất như là một công cụ cho các nhà phát triển trong các nhóm mới sử dụng các hướng dẫn mã hóa mới hoặc để sửa các lỗi quan trọng, do đó nguy cơ mắc lỗi sẽ giảm. Nếu bạn tin rằng bạn biết rõ hơn người đánh giá, bạn nên hỏi tại sao giải pháp mà người đó đề xuất là tốt hơn và tranh luận với những hiểu biết của bạn về vấn đề này. Không ai biết mọi thứ tốt nhất, vì vậy việc xem lại mã nên hoặc có thể là một kinh nghiệm học tập có giá trị cho cả hai.

Việc xem xét mã là cả một cơ hội để nắm bắt các vấn đề tiềm năng và truyền đạt kiến ​​thức, cho cả người đánh giá và người viết mã.

Là một người xem xét mã, trách nhiệm là làm nổi bật các lĩnh vực rủi ro có thể xảy ra, không tuân thủ thực tiễn tiêu chuẩn, cải tiến và nói chung chỉ là một quan điểm khác trên cùng một lĩnh vực mã.

Điều này sẽ không dẫn đến thay đổi mã mà không thảo luận / hiểu các quyết định của người viết mã tại thời điểm phát triển.

Nếu người đánh giá đang thực hiện các thay đổi, họ có thể gặp khó khăn khi giao việc cho người khác, điều này rất khó đối với nhiều người thông minh.

Là một lập trình viên nhận được đánh giá, bạn sẽ được bảo vệ khỏi một vấn đề có thể xảy ra khi được triển khai, được trao cơ hội học hỏi điều gì đó mới và cơ hội chia sẻ kiến ​​thức của bạn với người đánh giá.

Bất kể thâm niên, cách suy nghĩ của bạn có thể đưa ra một giải pháp mà không xảy ra với một số người, vì vậy đánh giá có thể là cơ hội để bạn tỏa sáng chỉ bằng cách làm những gì bạn tin là đúng.

Miễn là cả lập trình viên và người đánh giá chấp nhận rằng họ có thể sai và không sao cả, việc đánh giá trở thành thứ gì đó củng cố đội ngũ vì bạn cùng nhau giải quyết.

Có vẻ như bạn chưa xem xét mã của mình :-)

Mục tiêu của đánh giá mã là để có được mã có chất lượng tốt và để biết rằng bạn đã có mã có chất lượng tốt. Khi mã của một nhà phát triển thiếu kinh nghiệm được xem xét, thì nó có thể được sử dụng để dạy cách viết mã tốt hơn, đồng thời tránh làm nản lòng nhà phát triển đó.

Người xem xét không bao giờ nên thay đổi mã của bạn. Họ có thể đưa ra các đề xuất mạnh mẽ hơn hoặc ít hơn về cách họ muốn thay đổi mã của bạn và họ có thể quyết định có chấp nhận mã của bạn hay không.

Nếu đánh giá đúng / nếu tôi xem lại mã của bạn, những gì bạn có thể nhận được là một số nhận xét về cách tôi sẽ viết mã mà bạn có thể học hoặc bỏ qua - đây là những điều tôi có ý kiến ​​và bạn có thể tự do quan điểm khác nhau. Trong khu vực của tôi, việc đặt tên tốt cho các hàm, biến và vv được coi là quan trọng, vì vậy bạn có thể nhận được một số đề xuất để cải thiện việc đặt tên. Thông thường bạn nên thực hiện các thay đổi trong trường hợp đó (đôi khi bằng cách tìm một tên thậm chí tốt hơn cho một cái gì đó). Đôi khi tôi sẽ tìm thấy lỗi. Bạn sửa chúng. Đôi khi tôi sẽ tìm thấy những thứ mà tôi nghĩ là lỗi và tôi đã sai. Nếu thật khó để thấy rằng mã là chính xác, bạn làm cho nó rõ ràng hơn. Nếu tôi hiểu sai, bạn nói với tôi.

Nếu tôi nghĩ rằng thiết kế nói chung là không đúng, thì điều này đã được thảo luận trước đó. Sau đó chúng ta nên suy nghĩ xem liệu thiết kế của bạn có đủ tốt hay không, xem xét có bao nhiêu công việc liên quan đến một thay đổi, hoặc có thể tôi đã sai và thiết kế của bạn tốt hơn. Chúng ta nên kết thúc với thỏa thuận.

Nếu người đánh giá và người được đánh giá không thể đồng ý, thì chúng tôi có vấn đề. Bởi vì điều đó có nghĩa là một trong số chúng tôi không có khả năng làm việc nhóm, hoặc một trong số chúng tôi không có khả năng phân biệt giữa một thiết kế tốt hay xấu, hoặc cả hai. Đây không hẳn là lỗi của bạn. Thật không may, có những nhà phát triển cao cấp và không biết gì, và đó sẽ là một vấn đề cho công ty và cho bạn.

Nếu nó xảy ra, hãy suy nghĩ rất, rất khó khăn: Bạn có gặp vấn đề gì khi chấp nhận những lời chỉ trích có căn cứ không? Nếu đó là trường hợp, bạn cần thay đổi thái độ của bạn. Bạn có quá thiếu kinh nghiệm để xem tại sao người đánh giá là đúng? Nếu đó là trường hợp, đó không phải là vấn đề. Tin tưởng người đánh giá và học hỏi. Bạn có chắc chắn rằng bạn biết rõ hơn người đánh giá? Chấp nhận đánh giá, nhưng hỏi một nhà phát triển đáng tin cậy thứ ba về ý kiến ​​của anh ta. Hãy nhớ rằng bạn có thể thực sự chắc chắn về bản thân và đúng, nhưng bạn cũng có thể thực sự chắc chắn về bản thân và sai.