Làm thế nào quan trọng là phản hồi tích cực trong đánh giá mã?

Có quan trọng để chỉ ra các phần tốt của mã trong quá trình xem xét mã và lý do tại sao nó là tốt? Phản hồi tích cực có thể hữu ích cho nhà phát triển đang được xem xét và cho những người khác tham gia đánh giá.

Chúng tôi đang thực hiện đánh giá bằng cách sử dụng một công cụ trực tuyến, vì vậy các nhà phát triển có thể mở đánh giá cho mã cam kết của họ và những người khác có thể xem lại mã của họ trong một khoảng thời gian nhất định (ví dụ: 1 tuần). Những người khác có thể nhận xét về mã hoặc nhận xét của người đánh giá khác.

Có nên cân bằng giữa phản hồi tích cực và tiêu cực?

Cải thiện chất lượng và tinh thần bằng cách sử dụng Đánh giá mã ngang hàng
http://www.sl slideshoware.net/SmartBear_Software/improve-quality-and-morale-USE-peer-code-reviews

Những điều mọi người nên làm: Đánh giá mã
http://scientopia.org/bloss/goodmath/2011/07/06/things-everyone-should-do-code-review/

Cả hai bài viết này đều nói rằng một trong những mục đích của đánh giá mã là chia sẻ kiến ​​thức về các kỹ thuật phát triển tốt, không chỉ tìm lỗi.

Vì vậy, tôi muốn nói rằng nó rất quan trọng. Ai muốn đi họp và chỉ bị chỉ trích?

Khi tôi thực hiện đánh giá mã, tôi có xu hướng chỉ độc thoại, vì vậy tôi hiểu ý tôi đang đọc sẽ có rất nhiều "Ok, tôi thấy những gì nó làm .. Thật tốt khi nó kết nối với điều này và gọi điều đó, được rồi .. và mảnh đó phụ thuộc vào cả hai thứ đó. ".

Tôi nghĩ theo cách này không phải là "oo la la điều này quá tuyệt vời!", Nó có thể là một mã nhàm chán hoàn toàn tầm thường, nhưng nghe người khác thực sự phân tích và thể hiện sự hiểu biết về những gì bạn đã viết là một hình thức phản hồi tích cực trong chính nó, thông tin phản hồi là "Mã này có ý nghĩa", khi tôi chạy vào những phần mà tôi không hiểu tôi yêu cầu giải thích và khi tôi hiểu thì nó kêu lên "Ah, tôi hiểu rồi".

Tôi nghĩ rằng việc chuyển giao sự hiểu biết đơn giản là lời khen ngợi đối với một kỹ sư khác bởi vì tất cả chúng ta đều muốn mã của chúng ta được người khác hiểu, nó đưa ra một hình thức xác nhận ngầm.

Điều đó nói rằng, nếu bạn thấy các phần của mã là các đặc điểm tốt hoặc tích cực (ngay cả mã tầm thường nhàm chán cũng có thể tốt nếu đó là dạng tối thiểu của chính nó) Tôi chắc chắn có xu hướng nêu các đặc điểm đó, một lần nữa tôi không gán chúng là "Wow tuyệt quá!" nhiều đến mức "Tôi thấy đây là một triển khai tối thiểu" hoặc "Ok, thuật toán phức tạp này có rất nhiều ý kiến", tập trung vào các thuộc tính của mã không phải là tốt hay xấu vốn có.

Bất cứ khi nào bạn gán "tính tốt" hoặc "tính xấu" để viết mã trong đánh giá mã để tránh làm cho kỹ sư cảm thấy bị coi thường hoặc bị giữ trên bệ, đừng nói điều gì đó là tốt hay xấu, mà là nói về nguyên nhân và kết quả của mã của họ.

"Ok phần này có ý nghĩa, ah có một con số kỳ diệu ở đây, ý nghĩa của giá trị đó có thể không được hiểu rõ bởi kỹ sư tiếp theo để chạm vào điều này"

"Tôi thấy bạn đã có một container DI ở đây rồi, vì vậy bạn sẽ mất kết nối lỏng lẻo với kho lưu trữ đó"

"Ah có một từ điển tĩnh ở đây, nếu nhiều luồng chạm vào từ điển đó, chúng ta có thể gặp phải một số điều kiện cuộc đua"

Lưu ý, tôi không nói bất cứ điều gì tốt hay xấu, nhưng liệu kỹ sư có nên thay đổi hay không sẽ được hiểu bởi kỹ sư có mã đang được xem xét. Rõ ràng là bạn phải kết thúc đánh giá mã bằng một yay hoặc nay, nhưng việc tích lũy các tuyên bố này trong quá trình nó sẽ làm dịu đi điều này vì lời giải thích đã được đưa ra dưới dạng tuyên bố nguyên nhân và kết quả khi bạn nói với họ "Tôi muốn những con số ma thuật đã được cố định trước khi kiểm tra điều này trong ".

Nếu tôi thấy một cái gì đó trong bài đánh giá mã mà tôi thực sự thích và ở trên và vượt ra ngoài mã "đủ tốt", tôi sẽ đưa ra phản hồi tích cực.

Nói chung, tôi nghĩ rằng nếu ai đó viết một đoạn mã thực sự khiến bạn phải thốt lên "Wow, điều này thực sự rất hay!" sau đó, phản hồi tích cực là quan trọng - nó cho tác giả biết rằng những gì họ đã làm được người khác thích, và họ nên cố gắng làm điều đó một lần nữa. Nó không chỉ là tuân theo các hướng dẫn và thực hành tiêu chuẩn. Đưa ra lời khen ngợi vì ai đó thụt vào độc đáo hoặc thêm nhận xét về bản tóm tắt có thể đặt thanh khá thấp.

Đây không phải là một câu hỏi lập trình nhiều vì nó là một câu hỏi quản lý chung và tương tác giữa người với người. Phản hồi tích cực trong đánh giá mã chính xác cũng quan trọng như phản hồi tích cực trong bất kỳ loại đánh giá nào.

Điều này có được yêu cầu hay không (và mức độ mà nó được yêu cầu) là một chức năng của việc xử lý và trang điểm cảm xúc của người bạn đang nói chuyện. Một số người phản ứng với sự điều chỉnh hiệu quả hơn nhiều khi được kết hợp với lời khen ngợi. Những người khác xem lời khen là không thành thật khi giao hàng với sự điều chỉnh.

Công thức chung đôi khi được gọi là "Sandwich phản hồi": Thứ tốt thứ nhất, thứ xấu thứ hai, thứ tốt cuối cùng. Ý tưởng là giữ cho âm sắc tổng thể tích cực đồng thời đảm bảo rằng phản hồi tiêu cực được nhận. Điều này có thể giúp ngăn ngừa căng thẳng khi dự đoán đánh giá và giúp ngăn chặn việc nghiền ngẫm bản thân sau đó. Cả hai đều rất quan trọng đối với năng suất và chất lượng. Đây không chỉ là thứ cảm xúc vô cùng cảm động; Đó là hành vi của con người 101.

Một lần nữa, bạn phải biết người bạn đang làm việc cùng và hiểu những gì họ phản hồi. Đối phó với mọi người là những gì quản lý hướng đến, và những người quản lý giỏi biết cách làm cho mọi người phản hồi.

Tôi nghĩ rằng phản hồi tích cực là rất quan trọng và chủ yếu là từ động lực cá nhân, thực tế. Tất cả chúng ta ngồi và viết mã trong nhiều giờ, ngày, tuần, tháng và hầu hết chúng ta đều tự hào về những gì chúng ta làm. Mã đánh giá là một cơ hội để thể hiện điều đó.

Nếu bạn đi xem xét mã và kết quả tốt nhất bạn có thể hy vọng là "không bình luận" (nghĩa là không có sự cân bằng của phản hồi tích cực), cuộc họp có thể dễ dàng được đặt tiêu đề trong triển vọng "Tìm hiểu mọi người nghĩ bạn tệ như thế nào". Do đó, các nhà phát triển sẽ bắt đầu khó chịu bởi hoặc thậm chí sợ các đánh giá mã, và đó rõ ràng là một bất lợi cho nhóm. Các nhà phát triển sẽ "quên" để mã của họ được xem xét hoặc sẽ phát triển sự bất lực đã học và chỉ cần hỏi các nhà phê bình liên tục của họ phải làm gì về mọi điều nhỏ nhặt để tránh bị nổ tung trong các cuộc họp này.

Về mặt lý thuyết, thật tốt và tốt khi nói rằng, về mặt lý thuyết, việc khắc phục cái xấu và yêu cầu mọi người để lại cảm xúc trước cửa là điều hợp lý, nhưng chính những thái độ như một người chịu trách nhiệm cho các nhà phát triển đại diện lại bị điếc tai. Các lý thuyết sang một bên, đôi khi chúng ta và con người muốn có một cái vỗ nhẹ vào lưng, thậm chí là một danh nghĩa. Những thứ đó quan trọng.

Điều quan trọng hơn nếu bạn thực hiện đánh giá song song hoặc nhóm. Trong một bài đánh giá bằng văn bản, không có tin tức là tin tốt. Mục tiêu là để có được mã vào sản xuất. Khi đó là mã của bạn, bạn sẽ cảm thấy tốt về bản thân.

Đánh giá mã nên được sử dụng như một nguồn thông tin để giúp đỡ trong việc cố vấn và quản lý nhóm. Có rất nhiều cơ hội để đưa ra phản hồi tích cực mà không làm lộn xộn cơ sở dữ liệu đánh giá mã. Ví dụ có thể được rút ra để chia sẻ với những người khác.

Có rất nhiều thứ để xem xét nhà phát triển ngoài mã của họ. Chiếm thời gian xem lại mã có thể phản tác dụng để đưa ứng dụng ra khỏi cửa. Đặt thời gian cụ thể để giúp nhà phát triển ngoài đánh giá mã, nhưng điều đó không có nghĩa là bạn nên loại trừ phản hồi đánh giá mã.

Cách duy nhất mà tôi có thể nghĩ về việc cung cấp phản hồi tích cực về mã có thể gây tác dụng ngược với bạn là nếu bạn không cẩn thận để tránh "lời khen trái tay". Hầu hết mọi người đều quen thuộc với điều này ... nó được biểu thị bằng các cụm từ như, "Công việc tuyệt vời, nhưng ..."

Nếu mọi người đến cuộc họp với thái độ rằng đây không phải là đánh giá cá nhân của lập trình viên, mà là nỗ lực cải thiện thực hành mã hóa cho chất lượng của toàn bộ hệ thống, thì tất cả phản hồi là phản hồi "tốt". Phản hồi nêu bật các cách để cải thiện thực hành mã hóa trở nên quan trọng như phản hồi nêu bật một phương pháp mới hữu ích để xử lý một vấn đề.

Ít nhất, nếu một người không đi đến chiều dài đó, cần nhấn mạnh rằng việc phấn đấu để thực hiện một chu trình "phản hồi tốt, phản hồi tốt, phản hồi tốt, phản hồi xấu" trong quá trình đánh giá sẽ chỉ xảy ra với cùng cảm giác khen tay trái. Đừng cố gắng tạo ra phản hồi tốt, cố gắng củng cố nỗ lực tốt và nâng cao kiến ​​thức.

Các cụm từ mà tôi đã học được nhiều nhất từ, trong những năm qua:

• "Đó là một cách tiếp cận thú vị. Điều gì xảy ra nếu chúng ta phải điều chỉnh [một số trường hợp sử dụng khác]?"
• "Hãy thử đi! Bạn có biết chúng tôi đã có một phương pháp để làm điều đó không? Có lẽ chúng ta nên thực hiện một số điểm chuẩn để xem phương pháp nào hiệu quả hơn."

Quy trình làm việc mà tôi thích nhất với các đánh giá mã là:

1. Dev gửi bản vá trên danh sách gửi thư / công cụ trực tuyến.
2. Tất cả những người cần quan tâm nhìn vào các bản vá, đề xuất cải tiến.
3. Dev trở lại # 1
4. Nếu không cần cải thiện, mọi người nói "Làm tốt lắm, xin hãy cam kết." <- PHẢN HỒI TÍCH CỰC. Tất cả các mã được chấp nhận là tốt. Càng ít người phải bảo bạn thay đổi mọi thứ, bạn càng làm tốt hơn.
5. Dev cam kết, chuyển sang mục tiếp theo.

Thông thường những gì sẽ xảy ra là các nhà phát triển mới sẽ nhận được nhiều phản hồi 'chỉnh sửa' hơn khi họ đã quen thuộc với cơ sở mã.

Lợi ích của phương pháp này là:

1. Mọi người đều biết mọi người đang làm gì. Không có kiến ​​thức độc quyền hoặc cam kết bí ẩn.
2. Mọi người học hỏi từ phản hồi của người khác. Điều này quan trọng. Nếu phản hồi chỉ xảy ra giữa 2 người trong cuộc trò chuyện trực tiếp trong khi ghép nối, thì ai đó ở phía bên kia của căn phòng không có lợi như cách họ sẽ xảy ra trong danh sách gửi thư.
3. Các nhà phát triển khác thường có thể phát hiện ra một số lỗi trước khi chúng nằm trong kiểm soát phiên bản.

Tôi không thể đồng ý với điều này cả. Có gì khác biệt giữa Kỹ thuật phát triển tốt và cái gọi là Ninja Coders, những người có thể viết mã tuyệt vời nhưng không thể giải thích được thành đơn thuần? Phát triển phần mềm hiện nay (IMO) là một môn học Mẫu số chung thấp nhất, nơi sự tinh tế và xảo quyệt bị xa lánh để ủng hộ khả năng duy trì và dễ hiểu. Nó quá rủi ro.

Tôi không thể nghĩ về một lần tôi từng thấy mã trong một bài đánh giá sẽ khiến tôi phải thốt lên 'Ôi thật tuyệt'. Tôi chỉ có thể giả sử rằng nếu tôi gặp phải mã như thế này thì nó sẽ rơi vào trại Cool-Yet-Un-acceptable.

Bạn cũng gặp vấn đề với những người không có phản hồi tích cực có lẽ đã cố gắng quá nhiều và tạo ra một mớ hỗn độn cuối cùng "Hãy tin tôi, nó hoạt động!".

Đánh giá mã có để phân tán trách nhiệm chất lượng mã trong nhóm, tức là một nhà phát triển cá nhân không thể đổ lỗi nếu một vấn đề nghiêm trọng phát sinh sau đó. Sử dụng nó để tìm các vấn đề, sử dụng nó để có được lời giải thích từ nhà phát triển ban đầu của những thứ kỳ lạ trong trường hợp cuối cùng bạn phải duy trì nó. Cá nhân, tôi quan tâm hơn đến việc nhận được phản hồi tiêu cực. Khách hàng không quan tâm đến sự mát mẻ của mã của bạn, chỉ có điều nó làm những gì họ muốn.

Để lại dấu gạch chéo đến quán rượu.

Nó có vấn đề với tôi. Tôi không muốn bình luận lộn xộn hoặc tích cực vì lợi ích tích cực. Nếu tất cả các mã tôi đã viết là crappy, bạn cho tôi biết lý do và hãy sửa nó và tìm hiểu. Nhưng nếu tôi làm điều gì đó đúng, thật tốt khi nghe nó một lần và một lúc. Tôi không cần củng cố tích cực cho tất cả mọi thứ tôi đã làm là "chính xác", nhưng ngay cả khi đó là "hãy cải thiện X, Y và Z, nhưng phần còn lại có vẻ tốt".

Không gần như quan trọng như phản hồi trung thực. Tôi làm việc cho một tập đoàn tài chính lớn và khách hàng của chúng tôi không quan tâm nếu lập trình viên đang cố gắng hay là một người tốt, hay thường viết mã tốt! Họ yêu cầu phần mềm hoạt động.

Tôi nghĩ điều quan trọng là phải hoàn toàn khách quan. Cố gắng thúc đẩy tinh thần bằng cách đưa ra những bình luận tích cực là một sự lãng phí thời gian đối với tâm trí của tôi.

Điều này có thể có nghĩa là các đánh giá mã là quá quan trọng - nhưng sau đó không phải là vấn đề. Chúng ta cũng nên chỉ trích chính mình. Tôi thấy rằng giả định rằng mã mà tôi đã viết có lẽ là rác hoàn toàn và chắc chắn có thể được cải thiện thúc đẩy tôi cải thiện mã và trình độ kỹ năng của mình.

Nếu bạn không nhận được ý kiến ​​thì bạn có thể xem xét bạn đã hoàn thành tốt công việc.

Thần chú rất đơn giản: Nếu một người muốn có Mã chất lượng (ít có trong thực tế) thì phải thực hiện các phương pháp xem xét thích hợp. Phải nói rằng, phản hồi tích cực giúp nhà phát triển / lập trình viên suy nghĩ và đưa ra ý tưởng / giải pháp / sửa lỗi. Đừng quá khắc nghiệt, nhưng hãy kiên quyết. Người quản lý hỏi đáp nên nhận thức được các phương pháp và thực hành tốt để anh ấy / cô ấy có thể hướng dẫn nhóm (hoặc một thành viên) đi đúng hướng. Điều này dẫn đến chất lượng. Giai đoạn = Stage.

Khi mã dành cho một cuộc thi hoặc được gửi cho một cuộc phỏng vấn xin việc (nói cách khác, mã được viết và không thể viết lại), thì những bình luận tích cực là bắt buộc. Trên thực tế, bạn nên đảm bảo rằng có phản hồi tích cực (nếu có thể!) Cũng như tiêu cực. Bằng cách đó, lập trình viên biết điểm mạnh và điểm yếu của mình nằm ở đâu, và có thể bù đắp.

Tuy nhiên, dường như bạn đang nói chuyện trong môi trường công sở, nơi mã có thể được viết lại. Trong trường hợp đó, bạn đang cố gắng để thoát khỏi hệ thống của bạn. Vì vậy, trong tình huống đó, chỉ có các lỗi tiêu cực là có giá trị.

Nếu bạn cảm thấy không thoải mái về điều đó, hãy có một cuộc họp đánh giá mã hàng tuần, nơi mọi người có thể thảo luận về cả mã tốt và mã xấu.

EDIT: Mặc dù tôi sẽ nói rằng, nếu điều gì đó đủ gây ấn tượng với bạn, không có gì ngăn cản bạn thể hiện sự khen ngợi của bạn. Trình theo dõi, tuy nhiên, dường như chỉ để xem xét mã sản xuất.