Bài tập rà soát mã nguồn: cách sử dụng đánh giá ngang hàng để phát triển khả năng phân tích và phán đoán kỹ thuật.

Một lập trình viên mở một pull request để thêm chức năng tính toán giảm giá vào dịch vụ thanh toán. Các bài kiểm tra đều đạt và bản diff ngắn gọn. Người đánh giá chấp thuận nó trong hai phút với chú thích "LGTM" (Low Get It - Không có gì để nói). Ba tháng sau, một đồng nghiệp cần thay đổi chức năng tương tự và phát hiện ra rằng nó trộn lẫn các quy tắc định giá, làm tròn và truy cập cơ sở dữ liệu ở cùng một chỗ. Không ai có thể chắc chắn nó được phép làm gì.

Đây là một tình huống minh họa, không phải là một sự cố đã được ghi nhận. Nó cho thấy kết quả mà việc đánh giá mã nguồn ngang hàng cần đạt được khi nó hoạt động như một hoạt động học tập: một người đánh giá có thể nhận thấy một thay đổi hợp lý, phát hiện ra vấn đề chưa phải là lỗi và giải thích nó theo cách mà tác giả có thể hành động dựa trên đó.

Hướng dẫn này dành cho các trưởng nhóm hỗ trợ kỹ thuật và các quản lý kỹ thuật. Nó trình bày cách thiết kế. bài tập đánh giá mã Nó giúp xây dựng kỹ năng đó một cách có chủ đích, thay vì hy vọng người đánh giá sẽ tự nhận ra. Nó bao gồm vấn đề về hiệu suất, những lỗ hổng cần chẩn đoán, cách cấu trúc quá trình chuẩn bị và thực hành, một ví dụ minh họa, và cách kiểm tra xem kỹ năng đó có được áp dụng vào các bài đánh giá thực tế hay không. Hãy để các kỹ sư cấp cao xác nhận mọi trường hợp, lỗi và tiêu chí trước khi bạn sử dụng nó.

Bài tập đánh giá mã là gì?

Bài tập đánh giá mã là các nhiệm vụ thực hành có cấu trúc, trong đó một lập trình viên xem xét một thay đổi đã được chuẩn bị trước, giải thích những gì họ tìm thấy và tại sao điều đó lại quan trọng, đồng thời nhận phản hồi về chất lượng của lời giải thích đó. Chúng khác với các đánh giá mà nhóm của bạn thực hiện hàng ngày. Thay đổi được chọn trước, các vấn đề cần quan tâm đã được biết trước, và mục tiêu là cải thiện kỹ năng của người đánh giá chứ không phải là triển khai thay đổi đó.

sự kiện nhanh chóng

1. Mô tả vấn đề về hiệu năng

Hãy bắt đầu bằng nhiệm vụ, tóm gọn trong một câu: khi được yêu cầu thay đổi, người đánh giá cần giải thích những gì họ tìm thấy, tại sao điều đó lại quan trọng và tác giả có thể làm gì để khắc phục. Từ "giải thích" là từ quan trọng. Phát hiện ra vấn đề chỉ là một nửa kỹ năng. Diễn đạt vấn đề sao cho đồng nghiệp có quan điểm khác có thể hiểu, cân nhắc và hành động mới là nửa còn lại.

Nghiên cứu về quy trình đánh giá mã nguồn hiện đại ủng hộ việc nhìn xa hơn việc chỉ tìm lỗi. Trong một nghiên cứu tại Microsoft, Bacchelli và Bird đã quan sát, phỏng vấn và khảo sát các nhà phát triển và quản lý. Họ nhận thấy rằng việc tìm ra lỗi vẫn là động lực chính cho việc đánh giá, nhưng các đánh giá lại ít tập trung vào lỗi hơn so với dự đoán của mọi người. Chúng cũng mang lại những lợi ích khác, chẳng hạn như chia sẻ kiến ​​thức, nâng cao nhận thức nhóm và tìm ra các giải pháp thay thế, và các nhà nghiên cứu mô tả việc hiểu mã nguồn và sự thay đổi là khía cạnh quan trọng nhất của việc đánh giá.Bacchelli và Bird, ICSE 2013Đây là nghiên cứu về các nhóm làm việc của một công ty, vì vậy hãy sử dụng nó như một lý do để thiết kế nhằm mục đích thấu hiểu, chứ không phải để làm chuẩn mực cho nhóm của bạn.

Tiêu chuẩn đánh giá do Google công bố cũng chỉ ra điều tương tự. Tiêu chuẩn này hướng dẫn người đánh giá ưu tiên chấp thuận một thay đổi khi nó chắc chắn cải thiện chất lượng tổng thể của mã nguồn, ngay cả khi nó không hoàn hảo, và nói rằng quá trình đánh giá có thể dạy cho các nhà phát triển điều gì đó mới mẻ, vì vậy những nhận xét giúp ai đó học hỏi đều được hoan nghênh.Các quy trình kỹ thuật của GoogleCả hai nguồn đều mô tả quá trình xem xét là nơi mà việc đánh giá được thực hiện và đưa ra kết luận. Đó chính là điều mà các bài tập của bạn nên hướng đến.

2. Chẩn đoán những thiếu sót về kiến ​​thức và bối cảnh.

Hãy so sánh nhiệm vụ này với những gì chương trình hiện tại của bạn đang thực hành và đánh giá.

1. Liệu phương pháp hiện tại có sử dụng đúng nhiệm vụ thực tế? Nếu người đánh giá mới học bằng cách đọc hướng dẫn về phong cách và sau đó đánh giá các yêu cầu kéo (pull request) thực tế, họ sẽ thực hành trên công việc thực tế mà không có chỗ nào an toàn để mắc lỗi. Nếu việc đánh giá là một bài kiểm tra về quy tắc đánh giá, nó sẽ đo lường khả năng nhớ các quy tắc, chứ không phải khả năng áp dụng chúng vào một thay đổi.
2. Yêu cầu về khả năng nhận thức là gì? Trong thang phân loại Bloom sửa đổi, việc đánh giá xem một thiết kế có hợp lý hay không và cân nhắc các ưu nhược điểm của nó nằm ở cấp độ phân tích và đánh giá, còn việc đề xuất một cấu trúc tốt hơn đạt đến cấp độ sáng tạo. Nếu bài tập của bạn chỉ hỏi "đoạn mã này làm gì?", chúng sẽ dừng lại ở mức độ hiểu. Hướng dẫn của chúng tôi về... Phù hợp các hoạt động học tập với Phân loại Bloom. Hướng dẫn cách lựa chọn hoạt động phù hợp với trình độ.
3. Liệu có điều gì khác ngoài kỹ năng đang cản trở bạn? Kiểm tra thời gian xem xét, công cụ, quyền sở hữu và các quy tắc nhóm. Nếu người đánh giá chỉ có năm phút cho mỗi yêu cầu kéo (pull request), thì sẽ không có bài tập nào tạo ra được lời giải thích thấu đáo. Nếu tác giả coi mọi nhận xét là lời chỉ trích, người đánh giá sẽ làm giảm nhẹ kết quả cho đến khi họ không còn nói gì nữa. Hãy báo cáo những nguyên nhân này cho những người có thể khắc phục chúng.

3. Chuẩn bị thiết kế, thực hành và phản hồi

Hãy giao nhiệm vụ riêng cho từng giai đoạn.

Sự chuẩn bị. Hãy kiểm tra những gì người đánh giá cần trước khi bắt đầu: danh sách kiểm tra đánh giá của nhóm, các nguyên tắc thiết kế mà nhóm dựa vào, và cách đọc bản so sánh mã (diff) trong công cụ của bạn. Hãy thực hiện việc này theo tốc độ riêng và ngắn gọn. Việc kiểm tra lại chỉ xác nhận các điều kiện tiên quyết, chứ không phải là bằng chứng cho thấy ai đó có khả năng đánh giá.

Thực hành. Sử dụng các thay đổi đã được chuẩn bị sẵn với một số ít vấn đề cần quan tâm thuộc nhiều loại khác nhau: lỗi về tính chính xác, vấn đề về khả năng bảo trì như việc phân chia trách nhiệm lẫn lộn trong ví dụ ban đầu, tên không rõ ràng hoặc thiếu kiểm thử, và một số đoạn mã hoạt động tốt. Yêu cầu người đánh giá viết nhận xét mà họ muốn để lại, xếp hạng các vấn đề cần quan tâm và cho biết họ muốn bổ sung thêm thông tin gì. Bài học thực hành của CodeRefinery cho thấy hình thức như sau: mọi người mở một yêu cầu kéo (pull request) chứa một lỗi chính tả nhỏ và một lỗi lớn hơn, sau đó xem xét nó với tư cách là đồng nghiệp (CodeRefinery, Thực hành đánh giá mã.Hãy tự xây dựng từ mã nguồn của riêng bạn để các quy ước và sự đánh đổi là có thật.

Phản hồi. Hãy liên kết điều đó với các quyết định mà người đánh giá đã đưa ra. Câu "Bạn đã nhận thấy vấn đề làm tròn nhưng nhận xét của bạn chỉ nói 'điều này có vẻ sai' mà không nói rõ dữ liệu đầu vào nào gây ra lỗi" sẽ hữu ích hơn câu "đã tìm thấy 2 trong số 4".

Nhập liệu trực tiếp hay xem xét không đồng bộ? Phản hồi trực tiếp mang lại giá trị cao nhất khi vấn đề không rõ ràng và người đánh giá học hỏi được từ việc nghe một kỹ sư cấp cao giải thích lý do tại sao họ lại nêu ra vấn đề đó, hoặc bỏ qua nó. Đánh giá không đồng bộ là đủ để so sánh các nhận xét với đánh giá của chuyên gia có chú thích.

4. Hãy cùng nhau tìm hiểu một ví dụ thực tế.

Ví dụ minh họa. Người quản lý kỹ thuật nên xác nhận trường hợp và tiêu chí trả lời trước khi sử dụng.

Trường hợp. Một thay đổi bổ sung tính toán giảm giá vào dịch vụ thanh toán. Nó đã vượt qua các bài kiểm tra. Trong một hàm, nó áp dụng giảm giá theo phần trăm và giảm giá cố định, làm tròn kết quả, ghi vào cơ sở dữ liệu và gửi một sự kiện. Nó có một bài kiểm tra, dành cho mức giảm giá theo phần trăm duy nhất.

Nhiệm vụ. Người đánh giá viết ra những nhận xét mà họ muốn để lại, xếp hạng các mối quan ngại của họ và cho biết những điều họ cần biết trước khi phê duyệt.

Lần thử đầu tiên. "Trông ổn, bài kiểm tra đạt. Có lẽ nên chia nhỏ ra?" Người đánh giá đã nhận thấy điều gì đó nhưng không nói rõ đó là gì, tại sao nó quan trọng hoặc phải làm gì. Tác giả không thể hành động dựa trên điều này.

Phản hồi và thử lại. Người điều phối hỏi: Việc thay đổi chức năng này trong tương lai có thể gây ra lỗi gì? Bạn sẽ yêu cầu tác giả bổ sung điều gì trước khi phê duyệt? Quá trình thử lại yêu cầu nhận xét cụ thể về từng vấn đề, kèm theo lý do và đề xuất.

Một nỗ lực mạnh mẽ hơn. "Hàm này áp dụng hai loại giảm giá: làm tròn, lưu và phát hành một sự kiện, vì vậy việc thay đổi cách làm tròn có thể làm thay đổi cả những gì chúng ta lưu trữ và những gì chúng ta phát hành cùng một lúc. Tôi đề nghị các quy tắc định giá được chuyển vào một hàm thuần túy để chúng ta có thể tự kiểm tra. Bài kiểm tra duy nhất chỉ bao gồm giảm giá theo phần trăm. Tôi đề nghị giảm giá cố định và một đơn hàng có tổng bằng không. Tôi không chắc liệu sự kiện có được kích hoạt khi tổng bằng không hay không, vì vậy tôi muốn hỏi tác giả." Lưu ý rằng bình luận này nêu rõ vấn đề, đưa ra lý do, đề xuất cụ thể và nêu rõ điều mà người đánh giá chưa biết.

5. Đánh giá năng lực và lập kế hoạch chuyển giao

Bằng chứng về năng lực là hiệu quả thực hiện một thay đổi mới mà người đánh giá chưa từng thấy. Chấm điểm độ chính xác của các phát hiện và tính hữu ích của lời giải thích. Một bảng tiêu chí đơn giản sử dụng thang điểm từ 0 đến 2 cho mỗi tiêu chí:

Thang điểm: 0 nghĩa là không có hoặc không được hỗ trợ, 1 nghĩa là một phần với những thiếu sót liên quan, và 2 nghĩa là đầy đủ và được chứng minh dựa trên các tiêu chí đã thống nhất. Xác định riêng các lỗi nghiêm trọng, ví dụ như phê duyệt thay đổi có nguy cơ mất dữ liệu, để điểm tổng thể tốt không thể che giấu lỗi nghiêm trọng. Điều chỉnh các tiêu chí với người quản lý kỹ thuật; bảng đánh giá này chỉ là đề xuất ban đầu, không phải là tiêu chuẩn sẵn sàng đã được xác nhận. Để biết thêm về cách tính điểm, hãy xem hướng dẫn của chúng tôi về... Thiết kế bài tập tương tác với phản hồi hữu ích.

Lập kế hoạch chuyển giao. Sau khi hoàn thành bài tập, hãy kiểm tra lại một số bài đánh giá thực tế của người đánh giá vài tuần sau đó, sử dụng cùng tiêu chí. So sánh với dữ liệu cơ sở được thu thập trước khi đào tạo và xác định rõ đối tượng cũng như thời điểm ngay từ đầu. Xem xét các thay đổi khác đã xảy ra trong cùng kỳ, chẳng hạn như công cụ đánh giá mới hoặc thay đổi nhân sự, trước khi tính điểm cho bài tập.

6. Thực hiện bài tập trực tiếp hoặc tự điều chỉnh tốc độ với AhaSlides

Bạn có thể thực hiện bài tập này trong một buổi hội thảo hoặc để người đánh giá tự mình thực hiện. Trong một buổi họp trực tiếp, hãy trình bày sự thay đổi đã chuẩn bị và sử dụng các slide tương tác để thảo luận:

1. Chọn câu trả lời Đối với câu hỏi "Bạn sẽ nêu vấn đề nào trước tiên?", hãy sử dụng các vấn đề đã được gợi ý làm các lựa chọn. Cho mọi người xem kết quả trước khi tiết lộ thứ tự xếp hạng của riêng bạn.
2. Mở đã kết thúc Đối với câu hỏi "Hãy viết nhận xét mà bạn muốn để lại". Người nhận xét có thể so sánh cách diễn đạt của họ với những người khác, và đó là lúc kỹ năng diễn đạt được thể hiện.
3. Thang điểm đánh giá Để hỏi "mức độ nghiêm trọng của việc này như thế nào?", cả nhóm có thể thấy được những điểm khác biệt trong đánh giá và thảo luận về lý do.

Đối với những người đánh giá không thể tham dự, có thể sử dụng trình tự tương tự để tự học, với phần đánh giá chuyên gia được chú thích hiển thị sau mỗi phản hồi. Hãy coi bất kỳ tuyên bố nào về việc thực thi mã, tích hợp hoặc các tính năng AI là chưa được xác nhận cho đến khi bạn đã thử nghiệm với tài liệu của riêng mình.

Nếu bạn cũng đào tạo người đánh giá về mã do AI viết, hãy xem hướng dẫn kèm theo của chúng tôi về chủ đề này. Đào tạo đánh giá mã do AI tạo raBài viết kia nói về việc kiểm toán kết quả đầu ra được tạo ra. Bài này nói về cách mọi người đánh giá công việc của nhau và cách họ giải thích những gì họ tìm thấy.

Những ràng buộc có thể vẫn còn

• Đến giờ ôn tập rồi. Một bình luận chu đáo cần nhiều thời gian hơn là chỉ viết "LGTM", và thời hạn chót khiến người ta phải viết ngắn gọn hơn.
• Các quy tắc của đội. Nếu phản hồi được hiểu là lời chỉ trích cá nhân, người đánh giá sẽ giảm nhẹ hoặc bỏ qua những nhận xét của họ.
• Phạm vi bao phủ vụ việc. Một bài tập cho thấy một vài loại mối quan ngại. Điểm số không phản ánh chính xác đánh giá của người chấm điểm nói chung.
• Chuyển khoản. Hiệu suất trong một buổi hội thảo không giống với hiệu suất khi xếp hàng chờ đợi đông đúc, vì vậy hãy kiểm tra cả các đánh giá thực tế nữa.

Hãy nêu rõ những vấn đề này với nhà tài trợ từ sớm và lên kế hoạch khắc phục riêng biệt. Các bài tập giúp người đánh giá dễ dàng nhận thấy và giải thích hơn. Chúng không tạo ra thời gian hay các tiêu chuẩn.

Các câu hỏi thường gặp

Bài tập đánh giá mã là gì?

Đây là những bài tập thực hành được chuẩn bị sẵn, trong đó một lập trình viên xem xét một thay đổi với những vấn đề đã biết, viết ra những nhận xét mà họ muốn để lại và nhận phản hồi về độ chính xác và tính hữu ích. Mục đích là để nâng cao kỹ năng của người đánh giá, chứ không phải để đưa thay đổi đó vào sản phẩm.

Làm thế nào để đánh giá xem khả năng nhận xét của người đánh giá đã được cải thiện hay chưa?

Đưa ra một thay đổi mới mà họ chưa từng thấy và chấm điểm các phát hiện cũng như lời giải thích dựa trên các tiêu chí đã thống nhất. Sau đó, kiểm tra một mẫu các đánh giá thực tế vài tuần sau đó. Bài kiểm tra về quy tắc đánh giá chỉ nhằm xác nhận các điều kiện tiên quyết.

Liệu việc đánh giá mã nguồn ngang hàng chủ yếu là để tìm lỗi?

Việc tìm ra lỗi vẫn là động lực chính, nhưng một nghiên cứu tại Microsoft cho thấy các đánh giá không chỉ tập trung vào lỗi như dự kiến ​​mà còn thúc đẩy việc chia sẻ kiến ​​thức và nâng cao nhận thức nhóm. Cần thiết kế các bài tập khuyến khích cả việc giải thích và hiểu biết, cũng như số lượng lỗi được ghi nhận.

Bắt đầu từ đâu

Hãy chọn một loại thay đổi mà nhóm của bạn thường xuyên xem xét. Viết bản mô tả hiệu suất, yêu cầu một kỹ sư cấp cao chuẩn bị một thay đổi với ba hoặc bốn vấn đề cần quan tâm, và soạn thảo một bảng đánh giá ba tiêu chí với thang điểm từ 0 đến 2 cùng danh sách các lỗi nghiêm trọng. Thử nghiệm với một nhóm nhỏ, sau đó so sánh các đánh giá thực tế tiếp theo của họ với mức cơ sở.

Để xem cách thức thực hiện bài tập đánh giá trực tiếp với nhóm của bạn và có thể tái sử dụng theo tốc độ riêng sau đó, hãy khám phá AhaSlides.