Sau một số vấn đề nghiêm trọng về chất lượng trong năm ngoái, công ty của tôi gần đây đã giới thiệu các bài đánh giá mã. Quá trình xem xét mã đã nhanh chóng được giới thiệu, không có hướng dẫn hoặc bất kỳ loại danh sách kiểm tra nào.

Một nhà phát triển khác và tôi đã chọn để xem xét tất cả các thay đổi được thực hiện cho các hệ thống, trước khi chúng được hợp nhất vào thân cây.

Chúng tôi cũng được chọn là "Trưởng nhóm kỹ thuật". Điều này có nghĩa là chúng tôi chịu trách nhiệm về chất lượng mã, nhưng chúng tôi không có thẩm quyền để thực hiện các thay đổi trong quy trình, phân công lại các nhà phát triển hoặc giữ lại các dự án.

Về mặt kỹ thuật, chúng ta có thể từ chối hợp nhất, đưa nó trở lại phát triển. Trong thực tế, điều này kết thúc gần như luôn luôn với ông chủ của chúng tôi yêu cầu rằng nó được vận chuyển đúng thời gian.

Quản lý của chúng tôi là một MBA, người chủ yếu quan tâm đến việc tạo ra một lịch trình của các dự án sắp tới. Trong khi anh ta đang cố gắng, anh ta gần như không biết phần mềm của chúng tôi làm gì từ quan điểm kinh doanh và đang đấu tranh để hiểu ngay cả những yêu cầu cơ bản nhất của khách hàng mà không cần giải thích từ nhà phát triển.

Hiện tại việc phát triển được thực hiện trong các chi nhánh phát triển ở SVN, sau khi nhà phát triển nghĩ rằng anh ta đã sẵn sàng, anh ta chỉ định lại vé trong hệ thống bán vé của chúng tôi cho người quản lý của chúng tôi. Người quản lý sau đó giao nó cho chúng tôi.

Các đánh giá mã đã dẫn đến một số căng thẳng trong nhóm của chúng tôi. Đặc biệt là một số thành viên lớn tuổi đặt câu hỏi về những thay đổi (Tức là "Chúng tôi luôn làm như vậy" hoặc "Tại sao phương pháp nên có một cái tên hợp lý, tôi biết nó làm gì?").

Sau vài tuần đầu, đồng nghiệp của tôi bắt đầu để mọi thứ trôi qua, để không gây rắc rối với đồng nghiệp (cô ấy nói với tôi rằng sau khi một khách hàng báo cáo lỗi, cô ấy biết về lỗi, nhưng sợ rằng nhà phát triển sẽ tức giận với cô ấy vì đã chỉ ra nó).

Tôi, mặt khác, bây giờ được biết đến là một ass để chỉ ra các vấn đề với mã cam kết.

Tôi không nghĩ rằng tiêu chuẩn của tôi quá cao.

Danh sách kiểm tra của tôi tại thời điểm này là:

• Mã sẽ biên dịch.
• Có ít nhất một cách mã sẽ hoạt động.
• Mã sẽ làm việc với hầu hết các trường hợp bình thường.
• Mã sẽ làm việc với hầu hết các trường hợp cạnh.
• Mã sẽ ném ngoại lệ hợp lý nếu dữ liệu được chèn không hợp lệ.

Nhưng tôi hoàn toàn chấp nhận trách nhiệm của cách tôi đưa ra phản hồi. Tôi đã đưa ra những điểm có thể hành động để giải thích lý do tại sao một cái gì đó nên được thay đổi, đôi khi thậm chí chỉ hỏi tại sao một cái gì đó được thực hiện theo một cách cụ thể. Khi tôi nghĩ nó là xấu, tôi chỉ ra rằng tôi sẽ phát triển nó theo một cách khác.

Điều tôi còn thiếu là khả năng tìm ra thứ gì đó để chỉ ra là "tốt". Tôi đọc rằng người ta nên cố gắng kẹp tin xấu trong tin tốt.

Nhưng tôi đang có một thời gian khó khăn để tìm thấy một cái gì đó là tốt. "Này lần này bạn thực sự cam kết tất cả mọi thứ bạn đã làm" là hạ thấp hơn là tốt đẹp hoặc hữu ích.

Xem lại mã ví dụ

Này Joe

Tôi có một số câu hỏi về những thay đổi của bạn trong Lớp Thư viện \ ACME \ ExtractOrderMail.

Tôi không hiểu tại sao bạn đánh dấu "TempFilesToDelete" là tĩnh? Hiện tại, một cuộc gọi thứ hai đến "GetMails" sẽ đưa ra một ngoại lệ, bởi vì bạn thêm Tệp vào đó nhưng không bao giờ xóa chúng, sau khi bạn xóa chúng. Tôi biết rằng chức năng chỉ được gọi một lần mỗi lần chạy, nhưng trong tương lai điều này có thể thay đổi. Bạn có thể biến nó thành một biến đối tượng, sau đó chúng ta có thể có nhiều đối tượng song song.

... (Một số điểm khác không hoạt động)

Điểm nhỏ:

• Tại sao "GetErrorMailBody" lấy Ngoại lệ làm Thông số? Tôi đã bỏ lỡ một cái gì đó? Bạn không ném ngoại lệ, bạn chỉ cần vượt qua nó và gọi "ToString". Tại sao vậy?
• SaveAndSend Không phải là một tên hay cho Phương thức. Phương pháp này sẽ gửi thư lỗi nếu quá trình xử lý thư bị sai. Bạn có thể đổi tên nó thành "SendErrorMail" hoặc một cái gì đó tương tự không?
• Xin đừng chỉ nhận xét mã cũ, xóa nó hoàn toàn. Chúng tôi vẫn có nó trong lật đổ.

Làm thế nào để tìm thấy những điều tích cực trong một đánh giá mã?

Sau một số vấn đề nghiêm trọng về chất lượng trong năm ngoái, công ty của tôi gần đây đã giới thiệu các bài đánh giá mã.

Tuyệt vời, bạn có một cơ hội thực sự để tạo ra giá trị cho công ty của bạn.

Sau vài tuần đầu, đồng nghiệp của tôi bắt đầu để mọi thứ trôi qua, để không gây rắc rối với đồng nghiệp (cô ấy nói với tôi rằng sau khi một khách hàng gửi lỗi, cô ấy biết về lỗi này, nhưng sợ rằng nhà phát triển sẽ giận cô ấy vì đã chỉ ra nó).

Đồng nghiệp của bạn không nên thực hiện đánh giá mã nếu cô ấy không thể xử lý việc nói với các nhà phát triển những gì sai với mã của họ. Công việc của bạn là tìm ra các vấn đề và khắc phục chúng trước khi chúng ảnh hưởng đến khách hàng.

Tương tự như vậy, một nhà phát triển đe dọa đồng nghiệp đang yêu cầu bị sa thải. Tôi đã cảm thấy sợ hãi sau khi xem xét mã - tôi đã nói với sếp của mình và nó đã được xử lý. Ngoài ra, tôi thích công việc của mình, vì vậy tôi tiếp tục phản hồi, tích cực và tiêu cực. Là một nhà phê bình, đó là tôi, không phải ai khác.

Tôi, mặt khác, bây giờ được biết đến là một ass để chỉ ra các vấn đề với mã cam kết.

Chà, thật không may, bạn nói rằng bạn thật khéo léo. Bạn có thể tìm thấy nhiều hơn để khen ngợi, nếu bạn có nhiều hơn để tìm kiếm.

Phê bình mã, không phải tác giả

Bạn đưa ra một ví dụ:

Tôi có một số câu hỏi về những thay đổi của bạn trong

Tránh sử dụng các từ "bạn" và "của bạn", thay vào đó là "thay đổi".

Tôi đã bỏ lỡ một cái gì đó? [...] Tại sao vậy?

Đừng thêm những lời hoa mỹ vào những bài phê bình của bạn. Đừng đùa nữa. Có một quy tắc tôi đã nghe, "Nếu nó khiến bạn cảm thấy tốt khi nói, đừng nói điều đó, nó không tốt."

Có lẽ bạn đang tự đánh vào cái tôi của mình bằng chi phí của người khác. Giữ nó chỉ là sự thật.

Tăng thanh bằng cách đưa ra phản hồi tích cực

Nó nâng tầm để ca ngợi các nhà phát triển đồng nghiệp của bạn khi họ đáp ứng các tiêu chuẩn cao hơn. Vì vậy, điều đó có nghĩa là câu hỏi,

Làm thế nào để tìm thấy những điều tích cực trong một đánh giá mã?

là một trong những tốt, và đáng để giải quyết.

Bạn có thể chỉ ra nơi mã đáp ứng lý tưởng của thực tiễn mã hóa cấp cao hơn.

Tìm kiếm chúng để làm theo các thực tiễn tốt nhất, và tiếp tục nâng cao thanh. Sau khi những lý tưởng dễ dàng hơn được mọi người mong đợi, bạn sẽ muốn ngừng ca ngợi những điều này và tìm kiếm những cách thực hành mã hóa tốt hơn nữa để được khen ngợi.

Ngôn ngữ thực hành tốt nhất

Nếu ngôn ngữ hỗ trợ tài liệu về mã, không gian tên, các tính năng lập trình hướng đối tượng hoặc chức năng, bạn có thể gọi chúng ra và chúc mừng tác giả sử dụng chúng khi thích hợp. Những vấn đề này thường thuộc hướng dẫn phong cách:

• Nó có đáp ứng các tiêu chuẩn hướng dẫn phong cách ngôn ngữ trong nhà không?
• Liệu nó có đáp ứng hướng dẫn phong cách có thẩm quyền nhất cho ngôn ngữ (có lẽ nghiêm ngặt hơn so với trong nhà - và do đó vẫn tuân thủ phong cách trong nhà)?

Thực hành tốt nhất chung

Bạn có thể tìm thấy những điểm để ca ngợi về các nguyên tắc mã hóa chung, dưới nhiều mô hình khác nhau. Ví dụ, họ có những điều không tốt? Do các unittests bao gồm hầu hết các mã?

Tìm kiếm:

• kiểm tra đơn vị chỉ kiểm tra chức năng chủ đề - chế nhạo chức năng đắt tiền không có ý định kiểm tra.
• mức độ bao phủ mã cao, với thử nghiệm hoàn chỉnh về API và chức năng công khai về mặt ngữ nghĩa.
• kiểm tra chấp nhận và kiểm tra khói kiểm tra chức năng đầu cuối, bao gồm cả chức năng được chế giễu cho các thử nghiệm đơn vị.
• Đặt tên tốt, điểm dữ liệu chính tắc để mã là DRY (Đừng lặp lại chính mình), không có chuỗi hoặc số ma thuật.
• đặt tên biến rất tốt được thực hiện mà ý kiến ​​phần lớn là dư thừa.
• dọn dẹp, cải thiện khách quan (không đánh đổi) và tái cấu trúc phù hợp làm giảm các dòng mã và nợ kỹ thuật mà không làm cho mã hoàn toàn xa lạ với các tác giả ban đầu.

Lập trình chức năng

Nếu ngôn ngữ là chức năng hoặc hỗ trợ mô hình chức năng, hãy tìm những lý tưởng sau:

• tránh toàn cầu và nhà nước toàn cầu
• sử dụng các hàm đóng và một phần
• chức năng nhỏ với tên dễ đọc, chính xác và mô tả
• điểm thoát đơn, giảm thiểu số lượng đối số

Lập trình hướng đối tượng (OOP)

Nếu ngôn ngữ hỗ trợ OOP, bạn có thể khen ngợi cách sử dụng phù hợp các tính năng này:

• đóng gói - cung cấp một giao diện công cộng nhỏ và được xác định rõ ràng và ẩn các chi tiết.
• kế thừa - mã được sử dụng lại một cách thích hợp, có thể thông qua mixins.
• Đa hình - các giao diện được định nghĩa, có lẽ các lớp cơ sở trừu tượng, các hàm được viết để hỗ trợ đa hình tham số.

trong OOP, cũng có các nguyên tắc RẮN (có thể là một số tính năng dự phòng cho các tính năng OOP):

• trách nhiệm duy nhất - mỗi đối tượng có một bên liên quan / chủ sở hữu
• mở / đóng - không sửa đổi giao diện của các đối tượng đã thiết lập
• Thay thế Liskov - các lớp con có thể được thay thế cho các trường hợp của cha mẹ
• phân tách giao diện - giao diện được cung cấp bởi thành phần, có lẽ mixins
• đảo ngược phụ thuộc - giao diện được xác định - đa hình ...

Nguyên tắc lập trình Unix :

Nguyên tắc Unix là mô-đun, rõ ràng, thành phần, tách biệt, đơn giản, tinh ranh, minh bạch, mạnh mẽ, đại diện, ít bất ngờ nhất, im lặng, sửa chữa, kinh tế, tạo, tối ưu hóa, đa dạng và mở rộng.

Nói chung, những nguyên tắc này có thể được áp dụng theo nhiều mô hình.

Tiêu chí của bạn

Những thứ này quá tầm thường - tôi sẽ cảm thấy ủy khuất nếu được khen ngợi vì điều này:

• Mã sẽ biên dịch.
• Có ít nhất một cách mã sẽ hoạt động.
• Mã sẽ làm việc với hầu hết các trường hợp bình thường.

Mặt khác, đây là những lời khen ngợi khá cao, xem xét những gì bạn dường như đang giải quyết và tôi sẽ không ngần ngại khen ngợi các nhà phát triển đã làm điều này:

• Mã sẽ làm việc với hầu hết các trường hợp cạnh.
• Mã sẽ ném ngoại lệ hợp lý nếu dữ liệu được chèn không hợp lệ.

Viết ra các quy tắc để thông qua mã xem xét?

Tuy nhiên, đó là một ý tưởng tuyệt vời trong khi tôi thường không từ chối mã cho việc đặt tên xấu, tôi đã thấy việc đặt tên quá tệ đến nỗi tôi sẽ từ chối mã với các hướng dẫn để sửa nó. Bạn cần có thể từ chối mã vì bất kỳ lý do.

Quy tắc duy nhất tôi có thể nghĩ đến để từ chối mã là không có gì quá nghiêm trọng đến nỗi tôi sẽ không sản xuất nó. Một cái tên thực sự tồi tệ là thứ mà tôi sẵn sàng tránh sản xuất - nhưng bạn không thể biến nó thành một quy tắc.

Phần kết luận

Bạn có thể khen ngợi các thực tiễn tốt nhất được theo dõi dưới nhiều mô hình, và có thể theo tất cả chúng, nếu ngôn ngữ hỗ trợ chúng.

Đừng bận tâm chọn một cái gì đó tốt trừ khi đó là một ví dụ ngắn gọn và liên quan trực tiếp đến vấn đề tập trung.

Tôi sẽ không phủ nó - từ những âm thanh của nó mà bạn đang đối phó với ít nhất một người không an toàn với khả năng của họ và đang xử lý bị thách thức về công việc của họ một cách non nớt. Họ cũng có khả năng xấu trong công việc của họ - một nhà phát triển giỏi nên luôn sẵn sàng tự phản ánh, đưa ra những lời chỉ trích mang tính xây dựng và sẵn sàng thay đổi cách làm của họ.

Bây giờ điều đó ở ngoài không khí cho phép nói về bạn. Bất kể nếu bạn nghĩ rằng bạn đang hợp lý, bạn cần phải hết sức cẩn thận với những người như thế này để có được quả bóng lăn. Tôi đã tìm ra cách tốt nhất để đối phó với những người này là rất cẩn thận với cách bạn diễn đạt mọi thứ.

Hãy chắc chắn rằng bạn đang đổ lỗi cho mã chứ không phải tác giả . Tập trung vào một vấn đề trong tay chứ không phải là ngọn núi là cơ sở mã của bạn, mà họ có thể đã có một bàn tay quan trọng trong việc tạo ra và sẽ được coi là một cuộc tấn công cá nhân hơn nữa. Chọn các trận đánh của bạn ban đầu, tập trung vào các vấn đề quan trọng thể hiện với người dùng của bạn để bạn không đưa ra một loạt lời chỉ trích về người khiến họ loại bỏ mọi điều bạn đang nói.

Ngôn ngữ cơ thể và giọng điệu rất quan trọng nếu bạn đang nói chuyện trực tiếp với họ, hãy rõ ràng với những gì bạn đang nói và đảm bảo rằng bạn không nói chuyện với họ hoặc loại bỏ khả năng kỹ thuật của họ. Họ rất có thể sẽ phòng thủ ngay lập tức vì vậy bạn cần giải quyết những lo lắng của họ thay vì xác nhận chúng. Bạn cần có ý thức về cuộc trò chuyện này mà không quá rõ ràng để họ vô thức nghĩ rằng bạn đứng về phía họ, và hy vọng họ chấp nhận rằng họ cần thực hiện những thay đổi được chú ý.

Nếu điều này không hiệu quả, bạn có thể bắt đầu tích cực hơn một chút. Nếu sản phẩm có thể chạy được từ phòng hội thảo, hãy mang nó lên máy chiếu trong quá trình xem xét mã và hiển thị lỗi trước, tốt hơn nếu người quản lý ở ngay đó để người đó không thể lùi lại. Điều này không làm họ xấu hổ mà buộc họ phải chấp nhận rằng vấn đề là có thật đối với người dùng và nó cần được khắc phục, thay vì chỉ là một sự kìm kẹp mà bạn có với mã của họ.

Cuối cùng, nếu bạn không đến bất cứ nơi nào, mệt mỏi vì đối xử với người đó như một học sinh mẫu giáo và quản lý hoàn toàn không biết về vấn đề này và nó phản ánh kém về hiệu suất của bạn với tư cách là người đánh giá mã hoặc bạn quan tâm đến sức khỏe của bạn công ty và / hoặc sản phẩm, bạn cần bắt đầu nói chuyện với sếp về hành vi của họ. Càng cụ thể và nhân cách càng tốt - làm cho một trường hợp kinh doanh mà năng suất và chất lượng đang bị ảnh hưởng.

Đánh giá mã có thể độc hại, lãng phí thời gian, ý chí cho các cuộc chiến mọt sách sống động. Chỉ cần nhìn vào sự khác biệt của ý kiến ​​về những thứ như mã sạch so với nhận xét, quy ước đặt tên, kiểm tra đơn vị và tích hợp, kiểm tra chiến lược, RESTfulness, v.v., v.v.

Cách duy nhất để đảm bảo bạn tránh điều này là viết ra các quy tắc để thông qua đánh giá mã.

Sau đó, đó không phải là một người thất bại hoặc phê duyệt đăng ký. Họ chỉ đơn thuần là kiểm tra rằng các quy tắc đã được tuân theo.

Và bởi vì chúng được viết ra trước, khi bạn viết mã của mình, bạn có thể tuân theo các quy tắc và không phải giải thích lý do của bạn hoặc có các đối số sau này.

Nếu bạn không thích các quy tắc, có một cuộc họp để thay đổi chúng.

Tôi sẽ không phủ đường phản hồi của bạn bởi vì nó có thể được coi là bảo trợ.

Theo tôi, cách thực hành tốt nhất là luôn tập trung vào mã và không bao giờ tập trung vào tác giả.

Đó là đánh giá mã , không phải đánh giá nhà phát triển , vì vậy:

• "Vòng lặp while này có thể không bao giờ kết thúc", không phải "Vòng lặp của bạn có thể không bao giờ kết thúc"
• "Một trường hợp thử nghiệm là cần thiết cho kịch bản X", chứ không phải "Bạn đã không viết thử nghiệm để bao quát kịch bản này"

Điều cũng rất quan trọng để áp dụng quy tắc tương tự trong khi nói về đánh giá với người khác:

• "Anne, bạn nghĩ gì về mã này?", Chứ không phải "Anne, bạn nghĩ gì về mã của Jon?"

Đánh giá mã không phải là thời gian để đánh giá hiệu suất - nó nên được thực hiện riêng.

Tôi ngạc nhiên rằng nó đã không được đề cập trong bất kỳ câu trả lời nào cho đến nay và có lẽ kinh nghiệm của tôi về đánh giá mã là không bình thường, nhưng:

Tại sao bạn xem lại toàn bộ yêu cầu hợp nhất trong một tin nhắn?

Kinh nghiệm của tôi với các đánh giá mã là thông qua GitLab; Tôi luôn tưởng tượng rằng các công cụ đánh giá mã khác sẽ hoạt động tương tự.

Khi tôi đưa ra đánh giá mã, tôi nhận xét về các dòng riêng biệt, riêng biệt của diff. Điều này cực kỳ khó nhận được dưới dạng chỉ trích cá nhân, bởi vì nó là bình luận về mã mã hóa và thực sự được hiển thị dưới dạng bình luận về mã, được hiển thị ngay bên dưới mã mà nó là một bình luận.

Tôi cũng có thể nhận xét về toàn bộ yêu cầu hợp nhất và thường làm. Nhưng các điểm cụ thể có thể được chỉ ra trên các dòng cụ thể của diff. (Ngoài ra, khi một cam kết mới được thêm vào sao cho khác biệt thay đổi, các nhận xét về "khác biệt lỗi thời" sẽ bị ẩn theo mặc định.)

Với quy trình công việc này, các đánh giá mã trở nên mô đun hơn và ít gắn kết hơn. Một dòng từ đánh giá mã có thể nói một cách đơn giản,

Cách tiếp cận tốt đẹp, gói này trong một chức năng chuyên dụng!

Hoặc nó có thể nói,

Tên đối tượng này không thực sự phù hợp với mục đích của đối tượng; có lẽ chúng ta có thể sử dụng một cái tên như 'XYZ'?

Hoặc nếu có vấn đề lớn với một phần, tôi có thể viết:

Tôi thấy rằng mã này hoạt động (và tôi thấy lý do tại sao nó hoạt động) nhưng nó đòi hỏi nghiên cứu tập trung để hiểu nó. Bạn có thể vui lòng cấu trúc lại nó thành các chức năng riêng biệt để nó sẽ dễ bảo trì hơn trong tương lai không?

.

Sau khi viết tất cả những điều trên, tôi có thể đưa ra nhận xét tóm tắt về toàn bộ yêu cầu hợp nhất, đại loại như:

Đây là một tính năng mới tuyệt vời và nó sẽ thực sự hữu ích khi được hợp nhất. Bạn có thể vui lòng dọn sạch chức năng đặt tên và xử lý cấu trúc lại được đề cập trong các nhận xét riêng lẻ mà tôi đã thực hiện và sau đó cho tôi biết để xem lại nó không? :)

Ngay cả khi yêu cầu hợp nhất là bữa sáng hoàn chỉnh của chó, mỗi bình luận riêng lẻ có thể đơn giản. Sẽ chỉ có nhiều hơn trong số họ. Sau đó, nhận xét tóm tắt có thể nói:

Tôi xin lỗi, nhưng mã này không thực sự gây khó chịu. Có rất nhiều trường hợp cạnh (như chi tiết trong các bình luận riêng lẻ) sẽ được xử lý không chính xác và mang lại trải nghiệm xấu cho người dùng, hoặc thậm chí hỏng dữ liệu trong một trường hợp. (Xem bình luận về cam kết 438a95fb734.) Ngay cả một số trường hợp sử dụng thông thường sẽ dẫn đến hiệu suất ứng dụng cực kỳ kém (cụ thể được ghi chú trong các nhận xét riêng lẻ về diff cho somefile.c).

Để sẵn sàng sản xuất, tính năng này sẽ cần viết lại đầy đủ với sự chú ý nhiều hơn vào những giả định nào là an toàn để thực hiện tại mọi điểm trong luồng. (Gợi ý: Không có giả định nào an toàn trừ khi chúng được kiểm tra.)

Tôi đang đóng yêu cầu hợp nhất đang chờ viết lại đầy đủ.

Tóm tắt: Xem xét các khía cạnh kỹ thuật của mã dưới dạng nhận xét về từng dòng mã. Sau đó tóm tắt những nhận xét đó trong một nhận xét tổng thể về yêu cầu hợp nhất. Đừng để cá nhân chỉ xử lý các sự kiện và theo ý kiến ​​của bạn về mã chứ không phải về người viết mã. Và căn cứ ý kiến ​​của bạn về sự thật, quan sát chính xác và hiểu biết.

Tôi thực sự ngạc nhiên không ai nhặt được, nhưng có một cái gì đó sai với đánh giá mẫu được đăng.

Đơn giản là không có lý do gì bạn nên giải quyết trực tiếp với Joe. Rằng Joe sửa chữa những thất bại của mình không phải là việc của bạn. Đó là một người làm, là doanh nghiệp của bạn. Mối quan tâm của bạn là chất lượng mã. Vì vậy, thay vì viết yêu cầu / đơn đặt hàng / yêu cầu (rằng, nếu tôi là Joe, tôi chỉ có thể từ chối vì bạn không hợp pháp cho việc này), hãy giữ vai trò của bạn và viết một danh sách việc cần làm ẩn danh đơn giản.

Cố gắng công bằng trong việc đưa ra điểm tốt và điểm xấu không chỉ là không thể mà hoàn toàn nằm ngoài vai trò của bạn.

Dưới đây là ví dụ về cải cách với nội dung được lấy từ đánh giá của bạn:

• Trước khi chúng tôi thực hiện các thay đổi trong Thư viện \ ACME \ ExtractOrderMail, chúng tôi cần khắc phục một số vấn đề.
• Trừ khi tôi bỏ lỡ điều gì đó, "TempFilesToDelete" không nên tĩnh.
• Trong tương lai, chúng tôi có thể gọi hàm nhiều hơn một lần cho mỗi lần chạy, đây là lý do tại sao chúng tôi cần (những gì phải được thực hiện ở đây).
• Tôi cần hiểu lý do tại sao "GetErrorMailBody" lấy Ngoại lệ làm Thông số. (và, tôi đang ở biên giới ở đây, bởi vì bây giờ, bạn đã có một kết luận )
• SaveAndSend nên được đổi tên để phù hợp hơn với hành vi của nó, ví dụ như "SendErrorMail"
• Mã nhận xét nên được xóa cho mục đích dễ đọc. Chúng tôi sử dụng lật đổ cho rollback cuối cùng.

Nếu bạn xây dựng bài đánh giá như thế này, bất kể người đọc ghét bạn đến mức nào, tất cả những gì anh ta có thể thấy ở đây là ghi chú về những cải tiến mà ai đó phải thực hiện sau này. Ai ? Khi nào ? Không ai quan tâm. Gì ? Tại sao ? Điều đó bạn nên nói.

Bây giờ, bạn sẽ giải quyết các lý do đánh giá mã rất căng thẳng bằng cách đưa yếu tố con người ra khỏi phương trình.

Toàn bộ quan điểm của mã xem xét là để tìm vấn đề. Nếu có bất kỳ lỗi nào , điều tốt nhất bạn có thể làm là viết một trường hợp thử nghiệm bị lỗi.

Nhóm của bạn (người quản lý) nên thông báo rằng việc tạo ra lỗi là một phần của trò chơi, nhưng việc tìm và sửa chúng sẽ cứu công việc của mọi người .

Có thể hữu ích khi có các cuộc họp thường xuyên (nhóm hoặc cặp) và giải quyết một vài vấn đề. Lập trình viên ban đầu đã không đưa ra các vấn đề có chủ ý và đôi khi anh ta có thể nghĩ rằng nó đủ tốt (và đôi khi nó có thể xảy ra). Nhưng có đôi mắt thứ hai đó mang lại một cái nhìn hoàn toàn mới mẻ, và anh ta có thể học được rất nhiều từ việc xem xét các vấn đề.

Nó thực sự là một điều văn hóa, và nó cần rất nhiều sự tin tưởng và giao tiếp. Và thời gian để làm việc với kết quả.

Tôi nghĩ rằng điều tích cực cần làm là có được sự đồng thuận về các tiêu chuẩn mã hóa trước khi thực hiện đánh giá. Những người khác có xu hướng mua nhiều hơn một cái gì đó khi họ có đầu vào.

Đối với một cái gì đó như quy ước đặt tên, hãy hỏi người khác nếu điều này là quan trọng. Hầu hết các nhà phát triển sẽ đồng ý đặc biệt là giữa các đồng nghiệp của họ. Ai muốn trở thành người không muốn đồng ý với điều gì đó quá phổ biến trong thế giới lập trình? Khi bạn bắt đầu quá trình bằng cách chọn mã của ai đó và chỉ ra lỗ hổng, họ sẽ rất phòng thủ. Khi các tiêu chuẩn được thiết lập, sẽ có sự bất đồng về cách giải thích hoặc những gì được coi là "đủ tốt", nhưng bạn tốt hơn so với hiện tại.

Một phần khác của quy trình này là xác định cách đánh giá mã sẽ xử lý các phản đối. Điều này không thể trở thành cuộc tranh luận bất tận. Đến một lúc nào đó, ai đó phải đưa ra quyết định. Có lẽ có thể có một bên thứ ba làm thẩm phán hoặc người đánh giá có được tất cả quyền lực. Công cụ phải được thực hiện nên là mục tiêu.

Phần cuối cùng của việc này là để cho mọi người biết rằng Code Reviews không phải là ý tưởng của bạn, họ sẽ ở lại, vì vậy mọi người nên nỗ lực để tận dụng tốt nhất ý tưởng đó. Nếu mọi người cảm thấy bất lực, có lẽ họ có thể được phép xem lại mã của bạn?

Hy vọng rằng, một số kết quả có thể đo lường được cho việc quản lý là hạn chế lỗi, khiếu nại của khách hàng, sự chậm trễ, v.v. và nỗ lực đưa vào điều này.

Điều này có thể khắc nghiệt, nhưng đừng lo lắng về việc đưa ra phản hồi tốt nếu không có gì tốt để đo lường.

Tuy nhiên, trong tương lai, khi các nhà phát triển của bạn bắt đầu cải thiện mã của họ, đó là khi bạn muốn cung cấp cho họ phản hồi tốt. Bạn sẽ muốn chỉ ra những cải tiến trong mã và bạn cũng sẽ muốn chỉ ra những lợi ích cho toàn bộ nhóm. Khi bạn bắt đầu thấy sự cải thiện, họ cũng sẽ như vậy, và mọi thứ sẽ dần bắt đầu xuất hiện.

Cái khác; có thể có một không khí phòng thủ bởi vì họ cảm thấy như thể họ không có tiếng nói. Tại sao không để họ xem lại mã của nhau? Hỏi họ những câu hỏi cụ thể và cố gắng để họ tham gia. Không nên là bạn so với họ; nó nên là một nỗ lực của nhóm

1. Bạn sẽ thay đổi gì về mã này nếu bạn có thời gian?
2. Làm thế nào bạn sẽ cải thiện khu vực này của cơ sở mã?

Hỏi điều đó bây giờ, và yêu cầu sáu tháng kể từ bây giờ. Có một kinh nghiệm học tập ở đây.

Điểm chính - không khen ngợi về mã khi không được bảo hành, nhưng công nhận nỗ lực và chắc chắn nhận ra sự cải thiện. Cố gắng thực hiện đánh giá một bài tập nhóm thay vì một bài tập đối nghịch.

Chất lượng không căng thẳng

Bạn đã hỏi làm thế nào bạn có thể tìm thấy những điều tích cực để nói về mã, nhưng câu hỏi thực sự của bạn là làm thế nào bạn có thể tránh được căng thẳng trong nhóm [của bạn] trong khi giải quyết các vấn đề chất lượng nghiêm trọng.

Thủ thuật cũ của sandwich kẹp tin xấu trong tin tốt lành có thể phản tác dụng. Các nhà phát triển có khả năng nhìn thấy nó cho những gì nó là: một kế hoạch.

Tổ chức của bạn gặp rắc rối từ trên xuống

Sếp của bạn giao nhiệm vụ cho bạn với việc đảm bảo chất lượng. Bạn đã đưa ra một danh sách các tiêu chí cho chất lượng mã. Bây giờ, bạn muốn ý tưởng để củng cố tích cực để cung cấp cho nhóm của bạn.

Tại sao hỏi chúng tôi những gì bạn cần làm để làm cho nhóm của bạn hạnh phúc? Bạn đã xem xét yêu cầu nhóm của bạn?

Có vẻ như bạn đang cố gắng hết sức để trở nên tốt đẹp. Vấn đề không phải là cách bạn đang truyền tải thông điệp của mình. Vấn đề là giao tiếp đã được một chiều.

Xây dựng văn hóa chất lượng

Một nền văn hóa chất lượng phải được nuôi dưỡng để phát triển từ dưới lên.

Hãy để sếp của bạn biết rằng bạn lo ngại chất lượng không được cải thiện đủ nhanh và bạn muốn thử áp dụng một số lời khuyên từ Tạp chí Harvard Business Review .

Gặp gỡ nhóm của bạn. Mô hình hóa các hành vi bạn muốn thấy trong nhóm của bạn: khiêm tốn, tôn trọng và cam kết cải thiện.

Nói điều gì đó như: Từ Như bạn biết, [đồng nghiệp] và tôi được giao nhiệm vụ đảm bảo chất lượng mã, để ngăn chặn các vấn đề sản xuất mà chúng tôi phải chịu gần đây. Cá nhân tôi không nghĩ rằng tôi đã giải quyết vấn đề này. Tôi nghĩ rằng sai lầm lớn nhất của tôi là không liên quan đến tất cả các bạn nhiều hơn vào lúc đầu. [đồng nghiệp] và tôi vẫn chịu trách nhiệm quản lý về chất lượng mã, nhưng trong tương lai, tất cả chúng ta đều nỗ lực về chất lượng cùng nhau.

Lấy ý tưởng từ nhóm về chất lượng mã. (Một bảng trắng sẽ giúp.) Hãy chắc chắn rằng các yêu cầu của bạn đến đó vào cuối. Đưa ra những hiểu biết của bạn theo những cách tôn trọng, và đặt câu hỏi khi thích hợp. Hãy sẵn sàng ngạc nhiên về những gì nhóm của bạn cảm thấy là quan trọng. Hãy linh hoạt, không ảnh hưởng đến nhu cầu kinh doanh.

. )

Nhận xét mã hợp tác

Tôi đã không làm việc tại một nơi như bạn mô tả, nơi một vài lập trình viên cao cấp xem xét tất cả các mã và sửa lỗi. Không có gì ngạc nhiên khi mọi người trả lời như bạn là một giáo viên đánh dấu đỏ trên giấy tờ của họ.

Nếu bạn có thể bán ý tưởng cho quản lý, hãy bắt đầu thực hiện đánh giá mã ngang hàng . Điều này được thực hiện tốt nhất trong các nhóm nhỏ, bao gồm cả bạn hoặc nhà phát triển có trách nhiệm khác. Đảm bảo mọi người được đối xử tôn trọng.

Một mục tiêu quan trọng của mã đánh giá ngang hàng là đảm bảo mã có thể được hiểu bởi tất cả các thành viên của nhóm. Hãy xem xét ví dụ của bạn về các tên hàm không rõ ràng: nghe từ một nhà phát triển cơ sở hơn rằng họ thấy tên hàm khó hiểu có thể dễ chấp nhận hơn so với một hiệu chỉnh khác của Cameron từ nhà phát triển cấp cao.

Chất lượng là một hành trình

Một điều khác cần làm là loại bỏ bất kỳ khái niệm nào rằng đánh giá mã là một loại điều vượt qua / thất bại. Mọi người nên mong đợi để thực hiện một số chỉnh sửa sau khi xem xét mã. (Và công việc của bạn là đảm bảo chúng xảy ra.)

Nhưng nếu nó không hoạt động ...

Giả sử bạn thực hiện một số bước tiến thiết lập văn hóa chất lượng. Bạn vẫn có thể không đưa mọi người lên tàu. Nếu ai đó vẫn không có chương trình chất lượng, thì bây giờ vấn đề là họ không phù hợp với nhóm, thay vì có vấn đề giữa hai bạn. Nếu họ cần phải bị đuổi khỏi đội, những người còn lại trong đội sẽ hiểu rõ hơn lý do.

Xin lỗi vì đã có một câu trả lời dài khác, nhưng tôi không nghĩ rằng những người khác đã giải quyết đầy đủ yếu tố con người của vấn đề này.

đôi khi thậm chí chỉ hỏi tại sao một cái gì đó được thực hiện theo một cách cụ thể. Khi tôi nghĩ nó là xấu, tôi chỉ ra rằng tôi sẽ phát triển nó theo một cách khác.

Vấn đề với "Tại sao bạn thực hiện nó theo cách này?" Là bạn đặt nhà phát triển ngay lập tức vào phòng thủ. Câu hỏi tự nó có thể ngụ ý tất cả các loại tùy thuộc vào ngữ cảnh: Bạn có quá ngu ngốc khi nghĩ đến một giải pháp tốt hơn? Đây có phải là điều tốt nhất bạn có thể làm? Bạn đang cố gắng để làm hỏng dự án này? Bạn thậm chí quan tâm đến chất lượng công việc của bạn? v.v.

Tương tự "Tôi sẽ làm điều này khác đi ..." cũng mang tính đối đầu, bởi vì ngay lập tức nhà phát triển sẽ có " Tôi đã làm theo cách này ... Bạn có vấn đề với nó? " Và một lần nữa, nó đối đầu hơn nó cần phải được và biến cuộc thảo luận khỏi việc cải thiện mã.

Thí dụ:

Thay vì hỏi "Tại sao bạn chọn không sử dụng biến không đổi cho giá trị này?", Chỉ cần nói "Giá trị được mã hóa cứng này phải được thay thế bằng hằng số XYZtrong tệp Constants.h" Đặt câu hỏi cho thấy nhà phát triển chủ động chọn không sử dụng đã được xác định hằng số, nhưng hoàn toàn có khả năng họ thậm chí không biết nó tồn tại. Với cơ sở mã đủ lớn, sẽ có rất nhiều điều mà mỗi nhà phát triển không biết. Đây đơn giản là một cơ hội học tập tốt để nhà phát triển đó làm quen với các hằng số của dự án.

Có một dòng tốt để đi bộ với các đánh giá mã: bạn không cần phải phủ đường lên tất cả những gì bạn nói, bạn không cần phải kẹp tin xấu với tin tốt và bạn không cần phải làm dịu cú đánh. Đó có thể là văn hóa mà tôi tham gia, nhưng đồng nghiệp của tôi và tôi không bao giờ khen nhau trong các bài đánh giá mã - các phần của mã chúng tôi phát triển không có khiếm khuyết là đủ để khen ngợi. Những gì bạn cần làm là xác định khuyết điểm bạn nhìn thấy, và có thể đưa ra lý do tại sao (lý do tại sao ít hữu ích hơn khi nó rõ ràng / đơn giản).

Tốt

• "Tên của biến này cần được thay đổi để phù hợp với tiêu chuẩn mã hóa của chúng tôi."

• "'B' trong tên hàm này cần được viết hoa để trở thành PascalCase."

• "Mã này không được thụt lề đúng cách."

• "Mã này là một bản sao của mã được tìm thấy ABC::XYZ()và thay vào đó nên sử dụng chức năng đó."

• "Bạn nên sử dụng thử với các tài nguyên để mọi thứ được đảm bảo được đóng đúng trong chức năng này, ngay cả khi xảy ra lỗi." [Tôi chỉ thêm một liên kết ở đây để người dùng không phải java sẽ biết ý nghĩa của tài nguyên thử]

• "Hàm này cần được cấu trúc lại để đáp ứng các tiêu chuẩn phức tạp n-path của chúng tôi."

Xấu:

• "Tôi nghĩ rằng bạn có thể cải thiện mã này bằng cách thay đổi tên biến để phù hợp với tiêu chuẩn của chúng tôi"

• " Có lẽ sẽ tốt hơn nếu sử dụng try-with-resource để đóng đúng thứ trong chức năng này"

• "Có thể mong muốn có một cái nhìn khác về tất cả các điều kiện trong chức năng này. Độ phức tạp của đường dẫn N của nó vượt quá độ phức tạp tối đa cho phép tiêu chuẩn của chúng tôi."

• "Tại sao các vết lõm ở đây 2 không gian thay vì 4 tiêu chuẩn của chúng tôi?"

• "Tại sao bạn lại viết một hàm phá vỡ tiêu chuẩn phức tạp n-path của chúng tôi?"

Trong các báo cáo xấu, các phần in nghiêng là những thứ mà mọi người thường sử dụng khi họ muốn làm dịu cú đánh, nhưng tất cả những gì nó thực sự làm trong một bài đánh giá mã là khiến bạn không chắc chắn về bản thân. Nếu bạn, người đánh giá, không chắc chắn về cách cải thiện mã, vậy tại sao mọi người nên lắng nghe bạn?

Những tuyên bố 'tốt' là thẳng thừng, nhưng họ không buộc tội nhà phát triển, họ không tấn công nhà phát triển, họ không đối đầu và họ không đặt câu hỏi tại sao khiếm khuyết tồn tại. Nó có tồn tại; Đây là bản sửa lỗi. Họ chắc chắn không đối đầu như câu hỏi 'tại sao' cuối cùng.

Vấn đề mà bạn thấy là: Các nhà phát triển không hài lòng khi mã của họ bị chỉ trích. Nhưng đó không phải là vấn đề. Vấn đề là mã của họ không tốt (giả sử rõ ràng rằng mã đánh giá của bạn là tốt).

Nếu các nhà phát triển không thích mã của họ thu hút sự chỉ trích, thì giải pháp rất dễ dàng: Viết mã tốt hơn. Bạn nói rằng bạn đã có vấn đề nghiêm trọng với chất lượng mã; điều đó có nghĩa là mã tốt hơn là cần thiết.

"Tại sao phương pháp nên có một tên hợp lý, tôi biết nó làm gì?" là một cái gì đó mà tôi thấy đặc biệt đáng lo ngại. Anh ấy biết những gì nó làm, hoặc ít nhất là anh ấy nói như vậy, nhưng tôi thì không. Bất kỳ phương thức nào không nên chỉ có một tên hợp lý, nó nên có một tên làm cho nó rõ ràng ngay lập tức cho người đọc mã những gì nó làm. Bạn có thể muốn truy cập trang web của Apple và tìm kiếm video WWDC về các thay đổi từ Swift 2 sang Swift 3 - một số lượng lớn các thay đổi được thực hiện chỉ để mọi thứ dễ đọc hơn. Có lẽ loại video đó có thể thuyết phục các nhà phát triển của bạn rằng các nhà phát triển thông minh hơn họ rất nhiều, họ thấy tên phương thức trực quan là rất, rất quan trọng.

Một điều đáng lo ngại khác là đồng nghiệp của bạn đã nói rằng "cô ấy tự nói với tôi rằng sau khi một khách hàng gửi lỗi, cô ấy đã biết về lỗi này, nhưng sợ rằng nhà phát triển sẽ nổi giận với cô ấy vì đã chỉ ra nó". Có khả năng là có một số hiểu lầm, nhưng nếu một nhà phát triển nổi điên nếu bạn chỉ ra một lỗi cho họ, điều đó thật tệ.

Tôi rất không đồng ý với phương pháp đánh giá mã bạn đã mô tả. Hai nhân viên đi vào một 'phòng kín' và đưa ra những lời chỉ trích thể chế hóa loại ý niệm bất lợi mà các đánh giá mã tốt nên tránh .

Làm cho mã đánh giá một trải nghiệm tích cực đến mức có thể là điều cần thiết để làm cho nó thành công. Bước một là loại bỏ khái niệm đối nghịch của đánh giá. Làm cho nó một sự kiện nhóm hàng tuần hoặc hai tuần một lần ; đảm bảo mọi người đều biết rằng họ được chào đón tham gia. Đặt hàng trong pizza hoặc bánh sandwich hoặc bất cứ điều gì. Thậm chí đừng gọi nó là 'đánh giá mã' nếu điều đó khuấy động ý nghĩa tiêu cực. Tìm thứ gì đó để ăn mừng, để khuyến khích, chia sẻ - ngay cả khi đó không gì khác hơn là tiến bộ thông qua lần chạy nước rút hoặc lặp lại hiện tại. Thay phiên nhau phân công lãnh đạo qua đánh giá.

Làm cho quá trình một nỗ lực để phục vụ sản phẩm và người dân. Nếu chúng được thực hiện một cách xây dựng, tích cực, trong đó các kỹ thuật hoặc mô hình tốt được chia sẻ và khuyến khích giống như những người nghèo không được khuyến khích - mọi người đều có lợi. Mọi người đều được huấn luyện trước công chúng. Nếu bạn có một lập trình viên vấn đề không "hiểu được", họ nên được giải quyết một cách riêng tư và riêng biệt - không bao giờ đứng trước nhóm rộng hơn. Đó là tách biệt với đánh giá mã.

Nếu bạn gặp khó khăn trong việc tìm kiếm thứ gì đó "tốt" để đưa ra, điều đó với tôi đặt ra một câu hỏi: Nếu tiến độ đang được thực hiện trong dự án và mọi người đang làm việc, thì chính sự tiến bộ đó là điều đáng để ăn mừng. Nếu bạn thực sự thấy không có gì tốt, điều đó có nghĩa là mọi thứ đã được thực hiện kể từ lần đánh giá cuối cùng là xấu hoặc không tốt hơn trung tính . Đó thực sự là trường hợp?

Đối với các chi tiết, tiêu chuẩn chung là rất cần thiết. Cung cấp cho mọi người một cổ phần trong những gì đang được thực hiện. Và cho phép các kỹ thuật mới hơn, tốt hơn được tích hợp vào cơ sở mã của bạn. Thất bại trong việc đảm bảo những thói quen cũ không bao giờ bị loại bỏ dưới chiêu bài "chúng tôi luôn làm theo cách đó".

Điểm chính trong tất cả những điều này là các bài đánh giá mã được đưa ra một đoạn rap tệ bởi vì chúng được thực hiện kém, được sử dụng như những cái búa để coi thường những lập trình viên ít kinh nghiệm hoặc kém kỹ năng và đó là dịch vụ không dành cho ai. Những người quản lý sử dụng chúng theo cách này cũng không có khả năng trở thành người quản lý rất hiệu quả. Đánh giá mã tốt trong đó mọi người là người tham gia phục vụ mọi người - sản phẩm, nhân viên và công ty.

Xin lỗi về độ dài của bài đăng, nhưng đã ở trong một nhóm mà phần lớn đánh giá mã bị bỏ qua, nó đã dẫn đến một di sản của mã không thể nhầm lẫn và chỉ một phạm vi hẹp các nhà phát triển có thể ngay cả khi được phép thay đổi một cơ sở mã cũ. Đó là một con đường tôi chọn không đi qua nữa.

Nghịch lý của mã tốt là nó hoàn toàn không nổi bật và có vẻ như nó rất đơn giản và dễ viết. Tôi thực sự thích ví dụ người chơi bi-a từ câu trả lời này . Trong các đánh giá mã, điều đó làm cho nó thực sự dễ dàng để che đậy, trừ khi nó là một bộ tái cấu trúc từ mã xấu.

Tôi làm cho một điểm để tìm kiếm nó. Nếu tôi đang xem lại mã và tôi đã đọc một tệp rất dễ đọc đến mức có vẻ dễ viết, tôi chỉ cần viết nhanh "Tôi thích cách các phương pháp ở đây ngắn và sạch" hoặc bất cứ điều gì phù hợp .

Ngoài ra, bạn nên dẫn dắt bằng ví dụ. Bạn nên nhấn mạnh rằng mã của bạn cũng được xem xét và bạn nên mô hình hóa cách bạn muốn nhóm của mình hành xử khi nhận được sự điều chỉnh. Quan trọng nhất, bạn nên chân thành cảm ơn mọi người đã phản hồi. Điều này tạo ra nhiều sự khác biệt hơn bất kỳ phản hồi đơn phương nào bạn có thể đưa ra.

Nghe có vẻ như vấn đề thực sự là chỉ có hai người đang thực hiện tất cả các đánh giá mã, trong đó chỉ có bạn là người nghiêm túc, điều đó đã khiến bạn rơi vào tình huống không may với rất nhiều trách nhiệm và rất nhiều áp lực từ các thành viên khác trong nhóm.

Cách tốt hơn là phân phối trách nhiệm thực hiện đánh giá mã cho nhóm và để mọi người tham gia thực hiện chúng, ví dụ như bằng cách cho phép các nhà phát triển chọn ai để xem lại mã của họ. Đây là điều mà công cụ đánh giá mã của bạn nên hỗ trợ.

Tôi đã thấy điều này xảy ra trực tiếp và muốn cảnh báo bạn khỏi những câu trả lời thách thức trí tuệ cảm xúc - chúng có thể giết chết toàn bộ đội. Trừ khi bạn muốn tuyển dụng, đào tạo và bình thường hóa các nhà phát triển mới mỗi năm, việc tạo ra mối quan hệ tích cực với các đồng nghiệp của bạn là điều cần thiết. Rốt cuộc, không phải toàn bộ quan điểm của việc thực hiện các đánh giá này để cải thiện chất lượng mã và thúc đẩy văn hóa nơi chất lượng mã cao hơn ngay từ đầu? Tôi sẽ lập luận rằng đó thực sự là một phần công việc của bạn để cung cấp sự củng cố tích cực như một phương tiện tích hợp hệ thống đánh giá mã này vào văn hóa nhóm.

Dù sao, âm thanh như bạn cần để xem lại hệ thống Đánh giá mã của bạn. Ngay bây giờ, từ âm thanh của nó, mọi thứ trong quá trình xem xét của bạn là, hoặc có thể được hiểu là, chủ quan hơn là khách quan. Rất dễ có cảm giác bị tổn thương khi cảm thấy như ai đó đang tách mã của bạn vì họ không thích nó, thay vì họ có lý do để họ có thể trích dẫn khi điều gì đó không phù hợp với hướng dẫn. Bằng cách này, thật dễ dàng để theo dõi và 'ăn mừng' những cải tiến tích cực về chất lượng mã (đối với hệ thống đánh giá của bạn) theo bất kỳ cách nào phù hợp với văn hóa văn phòng của bạn.

Các Hướng dẫn kỹ thuật cần phải tập hợp bên ngoài phiên đánh giá và đưa ra Danh sách kiểm tra hướng dẫn mã hóa / mã hóa và nó cần phải được tuân thủ và tham khảo trong quá trình đánh giá. Đây phải là một tài liệu sống có thể được cập nhật và cải tiến khi quá trình phát triển. Các cuộc họp của Trưởng nhóm Công nghệ này cũng nên diễn ra khi 'Cách chúng tôi luôn thực hiện' so với 'Cách thức mới và cải tiến để thảo luận sẽ diễn ra, mà không có nhà phát triển nào được xem xét cảm giác như sự bất đồng là kết quả của mã của họ. Khi hướng dẫn ban đầu đã được thực hiện ít nhiều, một cách khác để củng cố tích cực cho các nhà phát triển là yêu cầu phản hồi của họ và sau đó thực sự hành động về nó và phát triển quy trình với tư cách là một nhóm, điều này thật tuyệt vời khi giúp họ tăng tốc để bắt đầu xem xét mã cho các bảng để bạn không bị mắc kẹt khi đánh giá cho đến khi bạn nghỉ hưu.

Cơ sở...

Lập trình viên là người giải quyết vấn đề. Chúng tôi có điều kiện để bắt đầu gỡ lỗi khi gặp sự cố hoặc lỗi.

Mã là một phương tiện định dạng phác thảo. Chuyển sang tường thuật định dạng đoạn văn để phản hồi giới thiệu ngắt kết nối phải được dịch. Chắc chắn một cái gì đó bị mất hoặc hiểu lầm. Không thể tránh khỏi, người đánh giá không nói bằng ngôn ngữ của lập trình viên.

Thông báo lỗi do máy tính tạo ra hiếm khi được đặt câu hỏi và không bao giờ được coi là một vấn đề cá nhân.

Các mục xem xét mã là các thông báo lỗi do con người tạo ra. Chúng được dự định để nắm bắt các trường hợp cạnh mà các lập trình viên và các công cụ tự động bỏ lỡ cũng như các tác dụng phụ không thể tránh khỏi đối với các chương trình và dữ liệu khác.

Kết luận ...

Do đó, các mục đánh giá mã càng nhiều có thể được kết hợp vào các công cụ tự động, chúng sẽ càng được nhận tốt hơn.

Thông báo trước là, để không bị nghi ngờ, các công cụ như vậy phải được cập nhật liên tục, thường là hàng ngày hoặc hàng tuần, để tuân thủ mọi thay đổi về quy trình, tiêu chuẩn và thực tiễn. Khi người quản lý hoặc nhóm nhà phát triển quyết định thực hiện thay đổi, các công cụ phải được thay đổi để thực thi điều đó. Phần lớn công việc của người xem mã sau đó trở thành duy trì các quy tắc trong các công cụ.

Ví dụ Đánh giá mã phản hồi ...

Một bản viết lại của ví dụ đã cho kết hợp các kỹ thuật này:

• Môn học:

  • Thư viện \ ACME \ ExtractOrderMail Class.

• Vấn đề nguyên tắc ...

  • TempFilesToDelete là tĩnh
    • Các cuộc gọi tiếp theo tới GetMails đưa ra một ngoại lệ vì các tệp được thêm vào nó nhưng không bao giờ bị xóa sau khi xóa. Mặc dù chỉ có một cuộc gọi bây giờ, hiệu suất có thể được cải thiện trong tương lai với một số song song.
    • TempFilesToDelete như một biến thể hiện sẽ cho phép nhiều đối tượng được sử dụng song song.
• Vấn đề thứ yếu ...
  • GetErrorMailBody có một tham số ngoại lệ
    • Vì bản thân nó không đưa ra một ngoại lệ và chỉ cần chuyển nó cho ToString, điều đó có cần thiết không?
  • Lưu tên và gửi tên
    • Email có thể hoặc không thể được sử dụng để báo cáo điều này trong tương lai và mã này chứa logic chung để lưu trữ một bản sao liên tục và báo cáo bất kỳ lỗi nào. Một tên chung hơn sẽ cho phép các thay đổi dự đoán như vậy mà không thay đổi các phương thức phụ thuộc. Một khả năng là StoreAndReport.
  • Nhận xét mã cũ
    • Để lại một dòng nhận xét và đánh dấu OBSOLLEX có thể rất hữu ích trong việc gỡ lỗi, nhưng một "bức tường bình luận" cũng có thể che khuất các lỗi trong mã liền kề. Chúng tôi vẫn có nó trong Subversion. Có lẽ chỉ là một bình luận tham khảo chính xác nơi Subversion?

Nếu bạn không có bất cứ điều gì tốt đẹp để nói về mã hiện có (nghe có vẻ dễ hiểu), hãy thử lôi kéo nhà phát triển cải thiện nó.

Trong một bản vá cho một thay đổi chức năng hoặc sửa lỗi, không có ích để có các thay đổi khác (đổi tên, tái cấu trúc, bất cứ điều gì), được gói vào cùng một bản vá. Nó sẽ thực hiện thay đổi để sửa lỗi hoặc thêm tính năng, không có gì khác.

Trong trường hợp đổi tên, tái cấu trúc và các thay đổi khác được chỉ định, hãy thực hiện chúng trong một bản vá riêng, trước hoặc sau.

• Điều này khá xấu, nhưng tôi đoán nó phù hợp với tất cả các mã khó chịu khác của chúng tôi. Hãy dọn dẹp nó sau (trong một bản vá với, lý tưởng nhất, không có thay đổi chức năng).

  Nó cũng giúp nếu bạn tham gia tái cấu trúc và để họ xem lại mã của bạn . Nó cho bạn cơ hội để nói lý do tại sao bạn nghĩ rằng một cái gì đó tốt, thay vì xấu, và cũng để cho thấy một ví dụ về việc đưa ra những lời chỉ trích mang tính xây dựng.

Nếu bạn cần thêm các bài kiểm tra đơn vị vào một tính năng mới, tốt thôi, chúng sẽ đi vào bản vá chính. Nhưng nếu bạn đang sửa một lỗi, các bài kiểm tra sẽ đi vào bản vá trước và không vượt qua để bạn có thể chứng minh bản sửa lỗi thực sự đã sửa lỗi.

Lý tưởng nhất là kế hoạch (về cách bạn có thể kiểm tra một bản sửa lỗi, hoặc những gì cần cấu trúc lại và khi nào) nên được thảo luận trước khi hoàn thành công việc, vì vậy họ đã không chìm đắm trong nỗ lực trước khi phát hiện ra bạn có vấn đề với nó.

Nếu bạn thấy mã không phù hợp với đầu vào mà bạn nghĩ nó nên, thì đó cũng có thể là sự không phù hợp trong những gì nhà phát triển xem là đầu vào hợp lý. Đồng ý rằng trước quá, nếu có thể. Ít nhất có một số cuộc thảo luận về những gì nó sẽ có thể đối phó và làm thế nào nó có thể được phép thất bại.

Tôi nghĩ thật sai lầm khi cho rằng có một giải pháp kỹ thuật hoặc dễ dàng để: "đồng nghiệp của tôi buồn bã khi tôi đánh giá công việc của họ theo tiêu chuẩn của tôi và có một số quyền lực để thực thi nó".

Hãy nhớ đánh giá mã không chỉ là một cuộc thảo luận về những gì tốt hay xấu. Chúng hoàn toàn là một "cây gậy mà chúng ta đang sử dụng", một "người đưa ra quyết định" và do đó, vô cùng ngớ ngẩn - một thứ hạng.

Nếu bạn không giải quyết những điểm đó, thực hiện đánh giá mã theo cách không có vấn đề bạn gặp phải sẽ khó khăn. Có một số lời khuyên tốt ở đây về cách thực hiện, nhưng bạn đã đặt ra cho mình một nhiệm vụ khó khăn.

Nếu bạn đúng, không có bất kỳ phòng ngọ nguậy nào, chỉ ra nó là một cuộc tấn công: ai đó đã làm rối tung lên. Nếu không: MBA khác của bạn, người không nhận được nó. Dù bằng cách nào, bạn sẽ trở thành kẻ xấu.

Tuy nhiên, nếu những gì đánh giá đang tìm kiếm và tại sao , rõ ràng và được đồng ý, bạn có cơ hội tốt để không trở thành kẻ xấu. Bạn không phải là người gác cổng, chỉ là một người đọc thử. Có được thỏa thuận này là một vấn đề khó giải quyết [1]. Tôi muốn cho bạn lời khuyên, nhưng tôi chưa hiểu rõ về nó ...

[1] Nó không được giải quyết chỉ vì mọi người đã nói "ok", hoặc ngừng chiến đấu về nó. Không ai muốn trở thành chàng trai để nói X chỉ không thực tế đối với {trí thông minh, kinh nghiệm, sức mạnh con người, thời hạn, v.v.) nhưng điều đó không có nghĩa khi nó thực sự xuất hiện trong một số trường hợp cụ thể của việc thực hiện X ...

Mã đánh giá nên được lẫn nhau. Mọi người chỉ trích mọi người. Hãy để phương châm là "Đừng nổi điên, hãy hòa nhập." Mọi người đều phạm sai lầm và một khi mọi người đã nói với một cảnh nóng về cách sửa mã của họ, họ sẽ hiểu rằng đây chỉ là thủ tục bình thường và không phải là một cuộc tấn công vào họ.

Xem mã của người khác là giáo dục. Hiểu mã đến điểm mà bạn có thể chỉ ra điểm yếu của nó và phải giải thích rằng điểm yếu đó có thể dạy cho bạn rất nhiều!

Có rất ít chỗ để khen ngợi trong một đánh giá mã, vì toàn bộ vấn đề là tìm ra sai sót. Tuy nhiên, bạn có thể nhận được nhiều lời khen ngợi về các bản sửa lỗi . Cả sự kịp thời và gọn gàng có thể được khen ngợi.