Nội dung từ một bài viết nước ngoài – tác giả Vlad Batushkov hiện đang là Giám đốc kỹ thuật tại Agoda, hoạt động năng nổ ở cộng đồng Neo4j bên cạnh đó cũng đăng các bài viết với nhiều chủ đề khác nhau. Nội dung lần này giải thích về văn hóa review và phương pháp giao tiếp – một trong những việc quan trọng nhất đối với nhà phát triển.
Bài viết chia sẻ tóm tắt về văn hóa review code, giao tiếp và kỹ thuật của người review. Nhưng không phải là nội dung hướng dẫn từng giai đoạn review code cụ thể.
Xin chào, tên tôi là Vlad và tôi đang đảm nhận vị trí quản lý kỹ thuật tại Agoda. Trong khoảng thời gian làm việc từ khi là kỹ sư phần mềm đến khi trở thành người chịu trách nhiệm kỹ thuật tại Agoda, mỗi năm tôi đã viết các bài đánh giá hơn 1100 lần. Nên có thể nói kinh nghiệm review code của tôi được tích lũy khá nhiều.
Review code là cuộc hội thoại giữa người viết code và người review. Khi các bạn giao tiếp hiệu quả có thể tạo ra cơ hội học tập tuyệt vời trong quá trình review code thông thường. Việc này khả thi như thế nào chúng ta cùng tìm hiểu nhé?
Thông báo đánh giá code
Người viết code khi yêu cầu review thường có tâm lý mong được chấp nhận. Nhưng nếu là người hỗ trợ đánh giá thao tác code của tác giả thì bạn nên chắc chắn giữa việc chấp nhận hay từ chối. Từ quá trình đưa ra quyết định mang tính hệ nhị phân đơn giản này bạn sẽ tích lũy được kinh nghiệm đánh giá chất lượng code với những thao tác mang tính xây dựng của hai bên.
Đừng thỏa hiệp
Lời khuyên thứ nhất: hãy quyết định một cách dứt khoát đưa ra chấp nhận hay từ chối(yêu cầu thay đổi). Những đánh giá bằng bình luận không giúp ích được gì cho bạn hay tác giả. Comment có thể chỉ là một tín hiệu cho thấy bạn là không chắc chắn hoặc không sẵn sàng chịu trách nhiệm.
Đừng lãng phí thời gian. Nếu bạn thấy không có vấn đề gì cần sửa hãy chấp nhận. Đương nhiên hầu hết các trường hợp sẽ đưa ra một số đề xuất sửa code. Nếu bạn nghĩ rằng đề xuất của mình đưa ra không phải là yêu cầu thay đổi bắt buộc hãy phê duyệt code. Hoặc khi bạn cho rằng thực ra tác giả có thể bỏ qua tất cả bình luận của bạn, cũng hãy chấp nhận. Còn không ở những trường hợp này bạn nên yêu cầu sửa đổi.
Là người review các bạn có quyền từ chối. Hãy sử dụng nó mỗi khi bạn muốn thay đổi bất cứ điều gì. Bạn yêu cầu thay đổi điều gì không quan trọng. Là thay đổi hình thức hay refactoring phức tạp cũng không vấn đề gì. Khi bạn muốn bất kỳ thay đổi nào được thực hiện hãy yêu cầu những điều đó. Đơn giản.
Giao tiếp
Mục đích của việc yêu cầu thay đổi là để cải thiện codebase[2], ngăn ngừa lỗi và chia sẻ kiến thức. Nếu việc từ chối review làm quá trình phát triển chậm lại bạn nên cải thiện kỹ năng giao tiếp. Bản chất việc từ chối tuy không là vấn đề nhưng có thể là yếu tố dẫn đến tốc độ và chất lượng giao tiếp giữa các bên với nhau.
Bạn không nên có suy nghĩ rằng yêu cầu thay đổi xong là không bận tâm về vòng review code tiếp theo. Sau khi từ chối hãy luôn sẵn sàng trả lời tác giả bất cứ lúc nào để tạo trải nghiệm tốt nhất cho họ. Họ sẽ nhận được sự chấp thuận của bạn sau khi tất cả những cân nhắc của bạn được giải quyết. Bạn có trách nhiệm phải ứng đáp nhanh về đánh giá code.
Đừng chỉ kiểm tra một dòng code mà không xác nhận hết phần còn lại hay chỉ yêu cầu thay đổi đúng một chỗ. Bạn nên xác nhận tất cả các diff[3] và yêu cầu thay đổi toàn bộ những vấn đề cần thiết trong một lần. Đừng biến quá trình này trở thành trò chơi pingpong(bóng bàn).
Sáng tạo
Nếu bạn tham gia một dự án lớn cùng với các đồng nghiệp hãy thử tiến hành bằng cách thảo luận thao tác review code. Cung cấp “dịch vụ review code” cho những người khác. Bạn có thể sử dụng các kênh liên lạc dành riêng cho các yêu cầu review code và nhiệm vụ gọi với sự giúp đỡ của bot hay quá trình tự động hóa. Tôi thực sự khuyên bạn nên chọn SLA[4] hợp lý cho thời gian phản hồi review code. Vì kiểm soát/ tiến hành việc kiểm tra code và thu thập data theo thời gian cũng giúp ích hiệu quả trong việc cải thiện kết quả.
Kỹ năng review code
Giờ chúng ta sẽ thử nói về kỹ thuật tốt nhất của việc review code nhé?
Kết quả review code toàn bộ phụ thuộc vào tính chuyên môn và kỹ năng cá nhân của người review. Mặc dù cung cấp tin nhắn hay review code về bất cứ Pull Request[5] nào là việc khó khăn nhưng bạn nên tập luyện thường xuyên. Chìa khóa thành công nằm ở kiến thức codebase tốt, khả năng ghi nhớ tốt, tâm trạng tốt. Vậy, chúng ta cùng tìm hiểu theo từng cái một nhé.
Trở thành chuyên gia
Nghe có vẻ hơi quá nhưng bạn phải hiểu đầy đủ về những vấn đề xảy ra trong codebase. Có nghĩa, bạn nên biết các khía cạnh của ngôn ngữ lập trình, hiểu rõ nền tảng framework cộng với kiến trúc dự án và cuối cùng là kiến thức nghiệp vụ. Hiểu được những vấn đề này cũng cần có sự hiểu biết sâu sắc. Vì đấy không phải là việc dễ dàng.
Muốn trở thành chuyên gia codebase, mỗi ngày bạn hãy làm việc một cách chân thành.
Dừng lại và phân tích
Thật không may là không phải tất cả nhà phát triển đều có sự hiểu biết đầy đủ về codebase hiện tại. Khi bạn cẩn thận đến từng chi tiết và có khả năng ghi nhớ tốt, những điều này sẽ giúp đỡ bạn rất nhiều trong việc trở thành chuyên gia giỏi. Trong quá trình review code, một mặt bạn có thể thấy được nội dung code đã thay đổi, còn toàn bộ codebase bị che khuất khỏi tầm mắt của người review bạn có thể dựa vào trí nhớ. Theo đó, bạn phải lưu ý đến những phần chủ chốt ở trong dự án và nhớ ai đã làm những gì để đồng bộ những ý kiến.
Bạn không cần thức khuya để học thuộc codebase của một dự án cụ thể. Hãy rèn luyện trí não hằng ngày. Thử thách bằng cách đọc nhiều sách và phân tích chơi các trò boardgame giống như cờ vua. Học ngôn ngữ mới(chẳng hạn như tiếng nhật) cũng là một phương pháp rất hữu dụng trong việc luyện tập trí nhớ.
Tôn trọng
Tuyệt đối không viết review code với ngữ điệu mang tính tiêu cực, cảm tính hay phá hoại. Những điều này khiến giao tiếp bị gián đoạn, làm nảy sinh mâu thuẫn, hơn nữa còn có thể gây tổn thương cho người khác (mất ý chí, bực bội, tức giận). Mọi người thường bị ảnh hưởng bởi các bình luận đánh giá về bản thân, nên dùng ngữ điệu trịnh trọng, mang tính xây dựng và tích cực sẽ tốt hơn.
Khi bạn đề xuất một sự thay đổi, bạn cần giải thích lý do tại sao. Hãy sử dụng các đoạn code, ví dụ và tài liệu tham khảo. Hoàn hảo hơn nếu bạn có thể chia sẻ link nguyên tắc code và tiêu chuẩn code.
Bonus
Một thói quen tốt của người đóng góp là code của họ sẽ được xem xét. Review code chỉ là công việc đánh giá, các bạn không nên tỏ ra ngạo mạn. Review code mang ý nghĩa hợp tác và cởi mở. Hãy nhớ rằng cả hai bên đều quan tâm đến kết quả tốt hơn và chia sẻ kiến thức với nhau.
Kết lại
Các bạn hãy học tập mỗi ngày, tập trung theo dõi các nội dung được yêu cầu trong dự án, mang thái độ khiêm tốn và tích cực đối với công việc luyện tập review code đều đặn. Khi làm được vậy nhất định bạn sẽ sớm nhận ra xung quanh bạn đều là những kỹ sư hạnh phúc. Chúc may mắn.
[1] Software refactoring: cải tiến cấu trúc code nhưng không làm thay đổi đến sản phẩm. Chủ yếu nâng cao khả năng hiểu biết, cách bảo trì thuận tiện, đây không phải là hoạt động loại bỏ khiếm khuyết hay thêm chức năng mới.
[2] Codebase là tập hợp của source code được dùng để build hệ thống phần mềm, ứng dụng phần mềm, các yếu tố tạo nên phần mềm. Thông thường trong codebase chỉ bao gồm file source code của người viết.
[3] diff mô tả tính thiết thực so với file thông tin đầu ra về sự chênh lệch giữa 2 file. Thường được sử dụng trong trường hợp thay đổi giữa file version tương tự với file version khác. diff cho thấy sự thay đổi giữa nội dung file.
[4] SLA – thỏa thuận mức dịch vụ( Service Level Agreement), là sự hợp tác bằng văn bản ở dịch vụ được cấp giữa người cấp dịch vụ và người sử dụng, giữa số liệu và mục tiêu chất lượng dịch vụ. Các chỉ số dịch vụ có thể được bao gồm trong đây thông thường là giữa thời gian khả dụng của CPU, thời gian CPU trả về, thời gian helpdesk trả về, thời gian hoàn thành dịch vụ.
[5] Với chức năng quan trọng nhất lúc các thành viên thảo luận với nhau thì đây là trình tự nhận các review, comment trước khi tổng hợp.
The translated article above belongs to Vlad Batushkov author and Metacoders commits not to use this article for any commercial purposes
The topic: Code Review Culture
