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ĩ:
- Tôi cần giúp đỡ để họ không chuyển sang chế độ phòng thủ.
- 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ì:
- Tác giả sẽ không học được từ đó.
- 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."
- 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.