Review Code: Một số tips để đạt được hiệu quả.

Khi comment vào Pull Request (PR) của người khác, việc thể hiện sự tôn trọng và hỗ trợ là chìa khóa để xây dựng một môi trường hợp tác và phát triển tích cực trong nhóm. Review code cũng là một cách để chúng ta truyền đạt những kinh nghiệm của bản thân tới cho người khác, vì thể hãy đưa nó về đúng với bản chất, target mà chúng ta mong muốn.

Trong mọi hoàn cảnh hãy thử đặt mình vào vị trí người khác chúng sẽ dễ có cách giải quyết đúng đắn và thuyết phục, dưới đây là một vài lời khuyên “không cụ thể”.

1. Đưa ra góp ý xây dựng:

  • Tập trung vào vấn đề: Chú ý vào các phần của code hoặc logic cần cải thiện hoặc có vấn đề.
  • Đề xuất cải thiện: Đưa ra ý kiến xây dựng, gợi ý cách để cải thiện mã nguồn, thay vì chỉ nhấn mạnh vấn đề.
  • Đánh nhãn nếu có thể: Hãy tập trung vào những điểm High cần phải thay đổi, Middle nên thay đổi, Low thay đổi càng tốt

2. Sử dụng ngôn ngữ tích cực và tôn trọng:

  • Lời khuyên thay vì chỉ trích: Sử dụng ngôn ngữ tích cực để gợi ý cách sửa đổi hoặc cải thiện.
  • Tôn trọng ý kiến: Đề xuất ý kiến của bạn một cách lịch sự và tôn trọng, tránh ngôn từ hoặc cách diễn đạt có thể bị hiểu là chỉ trích.

3. Giải thích rõ ràng và minh bạch:

  • Minh bạch: Giải thích tại sao bạn đề xuất thay đổi hoặc cần sửa đổi để người khác hiểu rõ lý do.
  • Ví dụ cụ thể (nếu có thể): Nếu có thể, cung cấp ví dụ cụ thể để minh họa vấn đề hoặc cải thiện đề xuất của bạn.

4. Tránh mâu thuẫn và xung đột:

  • Hỏi trước khi giả định: Nếu có điều gì không rõ ràng, hãy hỏi trước khi đưa ra giả định hoặc nhận xét.
  • Tránh tranh cãi: Tránh tranh cãi không cần thiết và tập trung vào giải quyết vấn đề.

5. Đề xuất giải pháp:

  • Đề xuất sửa đổi cụ thể: Nếu có thể, đề xuất cách thức cụ thể để sửa đổi vấn đề đã được xác định.
  • Hỗ trợ người gửi PR: Nếu bạn có kiến thức hoặc kinh nghiệm để giúp người gửi PR hoàn thiện mã nguồn, hãy chia sẻ.

6. Theo dõi và phản hồi:

  • Theo dõi và phản hồi: Theo dõi sự phản hồi từ người gửi PR và trả lời các câu hỏi hoặc bất kỳ yêu cầu giải thích nào.
  • Hiểu và thấu hiểu: Đôi khi, người gửi PR có lý do riêng cho cách họ viết mã nguồn. Hiểu và cân nhắc trước khi yêu cầu thay đổi, có câu hiểu người khác là khôn ngoan, hiểu được chính mình là giác ngộ!!!

Cám ơn mọi người đã vào và đọc được dòng chữ này!!!!

0 Shares:
Leave a Reply

Your email address will not be published. Required fields are marked *

You May Also Like
Read More

SOLID Principles

Table of Contents Hide Single-responsibility PrincipleOpen/Closed Principle (OCP)Liskov Substitution Principle (LSP)Interface Segregation Principle (ISP)Dependency Inversion Principle (DIP)Advantages of…