Cách đưa ra phản hồi sau quá trình xem xét mã


10

Tôi hiện đang xem xét một số mã của các nhà phát triển cơ sở mới tham gia nhóm của tôi, tôi tự hỏi làm thế nào tôi nên cung cấp đầu ra của đánh giá này:

  1. Tôi có nên tự sửa mã không?

  2. Tôi có nên cung cấp cho họ thông tin phản hồi về quy trình xem xét và để họ thực hiện các sửa lỗi theo hướng dẫn của tôi không? Và nếu vậy, làm thế nào để tôi đưa ra phản hồi này, tôi có điền tài liệu mẫu nhất định và gửi cho họ không, hoặc có một số phần mềm sẽ giúp tôi đánh dấu những thứ có vấn đề bên trong các tệp mã nơi họ có thể kiểm tra sau này? (Tôi đang sử dụng Visual Studio).

Sau khi tôi đã xem xét mã và sửa lỗi xong, một thời gian đã trôi qua và một số phần mã tôi đã xem xét trong quá khứ đã thay đổi, làm cách nào để tôi thực hiện lại quy trình xem lại? Tôi có nên kiểm tra lại tất cả các mã một lần nữa không? Hay tôi chỉ kiểm tra những phần đã thay đổi? Và nếu vậy làm thế nào để tôi theo dõi các phần đã thay đổi để tôi tránh xem lại mã đôi?


Câu trả lời:


14

Câu trả lời ngắn

Tôi có nên tự sửa mã không?

Không.

Tôi có nên cung cấp cho họ thông tin phản hồi về quy trình xem xét và để họ thực hiện các sửa lỗi theo hướng dẫn của tôi không?

Đúng. Theo đề nghị của bạn , không hướng dẫn . Hướng dẫn âm thanh quá có thẩm quyền.

Và nếu vậy, làm thế nào để tôi đưa ra phản hồi này, tôi có điền tài liệu mẫu nhất định và gửi cho họ không, hoặc có một số phần mềm sẽ giúp tôi đánh dấu những thứ có vấn đề bên trong các tệp mã nơi họ có thể kiểm tra sau này? (Tôi đang sử dụng Visual Studio).

Sử dụng một công cụ để cung cấp thông tin phản hồi. Bạn có thể sử dụng Visual Studio.

Câu trả lời dài

Tôi đã từng sử dụng Visual Studio nhưng tôi liên tục phải hỏi các nhà phát triển khác, "Này, bạn có thể gửi cho tôi công việc của bạn để tôi có thể xem lại không?" Tôi không thích điều đó và nó không bao giờ hoạt động tốt. Bây giờ, tôi sử dụng Đánh giá trợ lý vì tôi có thể bắt đầu đánh giá bằng cách xem xét các đăng ký. Tôi không cần phải dựa vào một nhà phát triển khác gửi cho tôi công việc để xem xét. Nó cũng giúp tôi đánh dấu các mục là khuyết điểm, hoặc đơn giản là đánh dấu các mục để tác giả xem xét. Điều này hoạt động cho nhóm của chúng tôi bởi vì một khi chúng tôi bắt đầu đánh giá, nó sẽ ở ngay trên bảng đánh giá và không bị lạc trong bản dịch. Điều này được tích hợp với Visual Studio. Như tôi đã đề cập, Visual Studio cũng có quy trình đánh giá riêng nhưng tôi thấy nó có những hạn chế và quy trình không tự nhiên; do đó, tôi sử dụng Đánh giá trợ lý.

Công cụ này cũng giúp với quá trình qua lại, thảo luận, vv

Quá trình, nhiều hay ít, như sau:

Tôi xem lại một cái gì đó, sau đó tôi gửi nó cho tác giả (trong trường hợp của bạn là dev). Họ thay đổi và sau đó họ gửi lại. Tôi nhìn vào những thay đổi và cung cấp thông tin phản hồi. Nếu tôi tốt với những thay đổi, tôi đóng đánh giá. Nếu không thì nó qua lại. Đôi khi nếu có quá nhiều qua lại, tôi sẽ chỉ đi bộ đến bàn của họ và sử dụng bảng trắng - nó thực sự thúc đẩy quá trình.

Đánh giá mã là một lĩnh vực nhạy cảm, vì vậy hãy rất cẩn thận với lựa chọn từ ngữ. Tôi không bao giờ nói với ai

Lựa chọn từ ngữ kém

Tôi đã xem lại mã của bạn và có một số mục bạn cần thay đổi.

Tôi thay vì nói điều này:

Lựa chọn từ ngữ tốt hơn

Tôi đã xem mã của bạn và tôi cần sự giúp đỡ. Bạn có thể vui lòng xem lại các mục tôi đã gửi cho bạn và xem nếu bạn có thể làm rõ một số câu hỏi của tôi?

Điều này khiến tác giả nghĩ:

  1. Tôi cần giúp đỡ để họ không chuyển sang chế độ phòng thủ.
  2. Có vẻ như họ là người đánh giá, không phải tôi. Về mặt kỹ thuật, vì tôi đang yêu cầu họ có một cái nhìn khác và thay đổi một số thứ, nên họ giống như người đánh giá.

Những lựa chọn từ đơn giản này đã giúp tôi rất nhiều.

Tôi không bao giờ đánh giá thấp devs junior. Tôi đã làm việc với một số nhà phát triển cao cấp (hơn 10 năm kinh nghiệm) và ở đó mã còn tệ hơn một sinh viên hợp tác cơ sở. Vì vậy, chỉ vì họ là đàn anh hay đàn em không quan trọng lắm; công việc của họ thực sự là những gì nói lớn hơn nhiều năm kinh nghiệm.

Thông thường, để khuyến khích các nhà phát triển cơ sở và cho họ tham gia đánh giá, tôi sẽ gửi cho họ một cái gì đó để xem xét cho tôi: Một cái gì đó họ có thể tìm ra, một cái gì đó họ sẽ thấy thách thức nhưng không hoàn toàn vượt quá họ. Tôi có thể từ nó như dưới đây:

Bạn có thể vui lòng xem lại một số mã cho tôi vì tôi không thể tìm ra nó.

Điều này giúp tôi rất nhiều lần nữa. Điều này có ích vì nó cho thấy rõ rằng tôi không phải là người duy nhất đánh giá, nhưng họ cũng thực hiện đánh giá và họ cũng là một phần của quy trình. Nó cho thấy rằng toàn bộ ý tưởng là sản xuất mã tốt, sạch và yêu cầu giúp đỡ nếu cần. Quá trình xem xét là một văn hóa vì vậy chúng tôi thực sự cần phải làm việc với nó.

Bây giờ một số người có thể lo lắng rằng nếu họ làm như trên, các nhà phát triển cơ sở sẽ mất sự tôn trọng vì họ chỉ làm những việc bạn không thể làm. Nhưng đó là xa sự thật: yêu cầu giúp đỡ cho thấy sự khiêm tốn. Ngoài ra, có rất nhiều tình huống trong đó bạn có thể tỏa sáng. Cuối cùng nếu đó là nỗi sợ của bạn, bạn có vấn đề về lòng tự trọng. Cuối cùng, có lẽ tôi thực sự không biết điều đó: Ý tôi là một số nhà phát triển có thuật toán mới trong đầu vì họ mới nghiên cứu chúng một tháng trước.

Dù sao, trở lại với đàn em và đánh giá. Bạn sẽ nhìn thấy khuôn mặt của họ khi họ phát hiện ra và gửi cho tôi một câu trả lời. Sau đó tôi có thể nói với họ, "OK, hãy để tôi thực hiện các thay đổi và nếu bạn hài lòng với nó, xin vui lòng đóng lại vấn đề."

Họ cảm thấy tuyệt vời khi có sức mạnh để nhìn vào công việc của tôi và nói: "Vâng, những thay đổi của bạn là tốt. Tôi đã đóng vấn đề."

Tôi không bao giờ tự sửa mã vì:

  1. Tác giả sẽ không học được từ đó.
  2. Nó giống như tôi nói: "Chuyển sang một bên, để tôi chỉ cho bạn cách thực hiện. Mã của tôi tốt hơn của bạn."
  3. Tại sao tôi Đây là công việc nhiều hơn cho tôi.

Nhưng tôi sẽ đề xuất ý tưởng và đoạn mã trong các bình luận của tôi để giúp đỡ tác giả. Xin lưu ý rằng đôi khi các đánh giá của tôi chỉ đơn giản là hỏi tác giả rằng tôi không hiểu mã của họ; có thể không có gì sai với mã của họ. Họ có thể cần thay đổi tên biến, thêm nhận xét, v.v. Vì vậy, tôi thậm chí sẽ không biết phải thay đổi gì trong trường hợp đó; chỉ họ sẽ

Nếu bạn tiếp tục thực hiện đánh giá, sớm hay muộn, bạn sẽ có một ý tưởng thực sự tốt về trình độ kiến ​​thức của từng nhà phát triển trong nhóm. Biết điều này thực sự hữu ích và bạn cần tận dụng nó và giải phóng nó. Đây là cách thực hiện: Nếu tôi xem xét một số mã và thấy các khu vực rõ ràng để cải thiện và tôi biết một nhà phát triển khác cũng có thể bắt chúng, tôi sẽ khiến họ xem xét mã thay thế. Một cái gì đó như "Này, tôi thấy một vài lĩnh vực có thể được cải thiện. Bạn có thể vui lòng xem lại chi tiết hơn và gửi ý kiến ​​của bạn cho tác giả không?" Điều này cũng hoạt động rất tốt vì bây giờ tôi có 2 nhà phát triển khác làm việc với nhau.

Nếu tôi đang xem xét một số công việc và tôi nhận thấy một cái gì đó mà cả nhóm có thể được hưởng lợi, thì tôi sẽ tạo ra một kịch bản giả thuyết và giải thích vấn đề trong một cuộc họp. Tôi sẽ bắt đầu bằng cách giải thích kịch bản và hỏi mọi người nếu họ có thể tìm ra vấn đề hoặc thấy một vấn đề, hãy lôi kéo họ tham gia. Khiến mọi người đặt câu hỏi. Sau đó cuối cùng trình bày một cách tiếp cận tốt hơn. Nếu ai đó có cách tiếp cận tốt hơn, tôi cảm ơn họ và thừa nhận trước đội, cách tiếp cận của họ tốt hơn. Điều này cho thấy tôi không phải là kiểu người "theo cách của tôi hay đường cao tốc". Hơn nữa, tôi KHÔNG BAO GIỜ mở tác phẩm của ai đó và bắt đầu chỉ ra các vấn đề trong một cuộc họp, tác giả sẽ không đánh giá cao nó - bất kể tôi nghĩ mình tốt đẹp và vô hại như thế nào.

Khi tôi thực hiện đánh giá, tôi không chỉ tìm kiếm mã sạch tốt mà còn cả những gì mã đang làm. Nếu yêu cầu kinh doanh là: Nếu một nhân viên đã làm việc với công ty lâu hơn 10 năm, hãy tăng cho họ 5%. Nếu không, 2,5% . Điều đầu tiên tôi kiểm tra là nếu nó thực sự làm điều đó. Sau đó, tôi kiểm tra nếu nó đang làm điều đó một cách sạch sẽ, nhất quán và hiệu quả.

Nếu tôi thực hiện đánh giá, tôi đảm bảo theo dõi hoặc không ai thực hiện đánh giá nghiêm túc.

Tôi đã từng làm việc với ai đó nhiều năm trước, người sẽ thực hiện đánh giá và quản lý nhà phát triển, và người quản lý QA nhưng cả hai người quản lý đều xuất thân từ nền tảng kinh doanh hoặc có ít kinh nghiệm phát triển. Ông chỉ làm điều này để gây ấn tượng với họ. Không ai thích nó và đó là khi tôi tự nhủ mình sẽ không bao giờ phạm sai lầm đó.

Một điều khác anh ấy thường làm là chọn phong cách lập trình và tin chắc rằng phong cách của anh ấy là tốt nhất ("kungfu của tôi tốt hơn phong cách khỉ của bạn ..."). Đó là một bài học khác cho tôi: luôn có nhiều hơn 1 cách giải quyết vấn đề.

Trả lời một số câu hỏi được đánh số của bạn

1- Tôi có nên tự sửa mã không?

Không, xin vui lòng xem lý do tôi nêu ở trên.

2- Tôi có nên cung cấp cho họ thông tin phản hồi về quy trình xem xét và để họ thực hiện các sửa lỗi theo hướng dẫn của tôi không?

Có, cố gắng sử dụng câu và một giai điệu thân thiện nhưng cần phải chú ý. Hãy rõ ràng như bạn có thể. Nêu vấn đề với mã là gì, làm thế nào để cải thiện nó. Đừng chỉ đơn giản là yêu cầu thay đổi nó. Nhưng cung cấp lý do.

Làm cách nào để cung cấp phản hồi này, tôi có điền tài liệu mẫu nhất định và gửi cho họ không, hoặc có một số phần mềm sẽ giúp tôi đánh dấu những thứ có vấn đề bên trong các tệp mã nơi họ có thể kiểm tra sau này? (Tôi đang sử dụng Visual Studio).

Như tôi đã nói, bạn có thể sử dụng công cụ tôi sử dụng hoặc công cụ khác. Không sử dụng email hoặc tài liệu từ vì chúng bị mất và thật khó để theo dõi nó.

Sau khi tôi đã xem xét mã và sửa lỗi xong, đôi khi đã thông qua và một số phần mã tôi đã xem xét trong quá khứ đã thay đổi, làm cách nào để tôi thực hiện lại quy trình xem lại? Tôi có nên kiểm tra lại tất cả các mã một lần nữa không?

Chủ yếu những gì tôi làm là để kiểm tra delta (chỉ thay đổi). Nhưng bạn cần phải có bức tranh tổng thể trong tâm trí để đảm bảo không có gì bị phá vỡ và nó tuân theo kiến ​​trúc.

Suy nghĩ cuối cùng

Cá nhân tôi nghĩ rằng từ "đánh giá mã" là một lựa chọn kém và không biết nó đã bắt đầu như thế nào. Họ có thể đã chọn một từ tốt hơn nhiều và ít thẩm quyền hơn.


Điều này sẽ chỉ làm việc cho những thứ nhỏ như tên biến. Tuy nhiên, nếu kiến ​​trúc sai, không có công cụ nào có thể giúp bạn. Bạn chỉ cần vứt bỏ toàn bộ và viết lại.
t3chb0t

@ t3chb0t Vì sao chuyện nhỏ? Bởi making sense architecturally, tôi có nghĩa là đảm bảo mã lớp truy cập dữ liệu nằm trong lớp truy cập dữ liệu, xác thực UI nằm trong UI, v.v. Nói cách khác, đảm bảo rằng các mối quan tâm không bị chảy vào các khu vực khác. Có các công cụ để giúp giữ kiến ​​trúc; Thực tế bây giờ VS làm điều này ra khỏi hộp bây giờ . Chúng tôi sử dụng đó là tốt.
CodingYoshi

Liên quan đến các công cụ, tôi nghĩ rằng một công cụ hoàn toàn hợp lệ để sử dụng là bất kỳ hình thức phần mềm theo dõi vé / công việc nào mà bạn có thể đã sử dụng để theo dõi những gì cần phải làm. Ví dụ: nếu bạn đang sử dụng Github, bạn có thể có tất cả các thay đổi liên quan đến một vấn đề và sau đó đánh giá sẽ được thực hiện trong chuỗi thảo luận đó. Jira và Trac là hai công cụ khác như vậy. Điều này giữ một nơi tập trung cho tất cả các thông tin liên quan đến công việc và nó hiển thị rõ ràng trước khi vé được đóng.
Kat

@Kat Tôi không chắc chắn nếu một công cụ bán vé là công cụ phù hợp để sử dụng ở đây. Các công cụ xem xét mã cho thấy sự khác biệt giữa các thay đổi và các vấn đề là các vấn đề khác với các vấn đề trên hệ thống bán vé; chúng có nghĩa là những thứ khác nhau. Nhưng tôi có thể sai.
CodingYoshi

3

Rất nhiều phụ thuộc vào cách bạn hiểu đánh giá mã tại công ty của bạn. Có những công ty mà việc xem xét mã là một quá trình chính thức hóa hiếm khi diễn ra nhưng lại là một vấn đề lớn. Ở những người khác, xem xét mã là một phần bắt buộc của mỗi nhiệm vụ được thực hiện, và là một điều rất trần tục và nhanh chóng với ít hình thức. Cá nhân, tôi chọn cách tiếp cận sau, nhưng nó có thể hoặc không thể là quyết định của bạn nếu bạn có thể sử dụng nó hay không.

Tôi đã viết một bài đăng trên blog có tiêu đề Đánh giá mã có đáng để bạn dành thời gian không? để tóm tắt quá trình được sử dụng bởi nhóm của tôi. Các vấn đề, vì chúng liên quan đến câu hỏi của bạn sẽ là:

  1. Hãy để các nhà phát triển sửa mã. Điều này sẽ cho phép họ hiểu rõ hơn ý kiến ​​của bạn (hoặc nhận ra rằng họ không hiểu đầy đủ về họ và hỏi) và thực hiện một nhiệm vụ là cách học tốt hơn so với chỉ đọc về nó.
  2. Phần mềm để đánh giá mã là cách để đi. Có nhiều tùy chọn có sẵn, cả nguồn mở và độc quyền. Hầu hết nó hoạt động với git. Nhóm của tôi sử dụng BitBucket (trước đây gọi là Stash), cũng có GitLab và GitHub, Gerrit (cá nhân tôi không phải là người hâm mộ) và một nhóm người khác. Hầu hết các ứng dụng này đều dựa trên web nên bạn không sử dụng IDE nào, nhưng cũng có các plugin cho nhiều IDE, vì vậy tôi chắc chắn cũng có một số cho Visual Studio. Phần mềm như thế này cho phép bạn xem lại mã trước khi nó được hợp nhất vào nhánh chính (thường thông qua Yêu cầu kéo) và nó hiển thị các phần được sửa đổi và một số dòng ngữ cảnh xung quanh mỗi thay đổi. Điều này làm cho mã xem lại lưu loát và không rắc rối.

Đối với chu trình xem xét-sửa chữa-kiểm tra-sửa chữa, những gì bạn chọn phải phụ thuộc vào sự trưởng thành của nhà phát triển và mức độ nghiêm trọng của các vấn đề bạn phát hiện. Khi các nhóm thực hiện đánh giá mã một quy trình hàng ngày, bạn có thể mong đợi các thay đổi nhỏ như đổi tên một lớp, chỉ đơn giản là được áp dụng và có lẽ không cần phải kiểm tra lại chúng. Nếu nhóm chưa được bán trên các đánh giá mã hoặc những người thực sự thiếu kinh nghiệm, bạn có thể muốn kiểm tra những thứ như vậy bất kể. Mặt khác, nếu đánh giá của bạn phát hiện ra một vấn đề tương tranh phức tạp mà các nhà phát triển cơ sở có thể không hiểu đầy đủ ngay cả sau khi bạn chỉ ra cho họ, bạn nên kiểm tra sửa chữa và không đưa ra sự thay đổi trước khi bạn chắc chắn rằng nó đã thực sự được sửa.

Các công cụ có thể giúp bạn thực hiện điều này vì nếu bạn làm việc với các yêu cầu kéo, bạn có thể dễ dàng thiết lập phần mềm để không cho phép hợp nhất một thay đổi cho đến khi được sự chấp thuận của một số nhà phát triển được xác định trước. Thông thường, bạn có thể xem các thay đổi trong các cam kết riêng lẻ của một thay đổi cho phép bạn dễ dàng xem xét các thay đổi được thêm vào từ vòng nhận xét cuối cùng của bạn.


1

Tôi bỏ phiếu cho lựa chọn thứ hai. Người cao niên có thể có "đường cong sáng suốt" tốt hơn khi tự thực hiện các thay đổi.

Ngoài ra: đừng là người duy nhất xem xét mã.
Hãy để một số thành viên có kinh nghiệm trong nhóm của bạn cũng xem mã và lên lịch một cuộc họp đánh giá thường xuyên nơi những người đánh giá trình bày kết quả của họ (họ đã thực hiện trước cuộc họp!) Cho tác giả. Điều này sẽ nâng cao động lực của cả hai, đàn em các thành viên trong nhóm kinh nghiệm.


4
Điểm tuyệt vời. Ngoài ra, các đàn em cũng nên "xem lại" mã của OP và mã của nhau.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.