Tư duy review code

Lời người dịch

Bên cạnh việc viết code, việc review code cũng là một công việc thường xuyên của bất cứ developer nào. Từ việc tự review code của bản thân, sau đó đến review code cho các member cùng trong nhóm, review cho các đàn em mà mình dẫn dắt,… khi trách nhiệm tăng lên thì cũng đồng nghĩa với việc số lượng code phải review càng lớn và ta càng phải chịu trách nhiệm nặng nề hơn với những review đó. Hiểu được trách nhiệm đó, bản thân mình cũng rất trăn trở trong việc reivew code cho các đàn em, không thể qua loa đại khái như khi đang làm việc dưới sự chỉ bảo của leader, nhưng cũng không thể dành quá nhiều thời gian để review để tránh ảnh hưởng đến công việc của bản thân mình.

Trong lúc tìm kiếm lời giải cho vấn đề này, mình đã tìm thấy một bài viết khá hay về quy trình cũng như mindset cần có trong quá trình review code. Mình sẽ chia sẻ lại bài viết dưới đây, hy vọng có thể giúp được những người đã, đang và sẽ gặp phải những vấn đề như mình. Lưu ý là nhân vật “tôi” trong bài viết là chỉ tác giả bài viết gốc.

Link bài gốc: Code reviewing as a mindset

Lời nói đầu

Một vài năm trước, tôi có chia sẻ một vài công cụ giúp review code tự động. Các công cụ này rất hữu hiệu trong việc tìm ra các lỗi cú pháp, indent, định nghĩa biến… Trong bài này, tôi muốn tập trung hơn vào những thứ mà không dễ gì có thể tự động được.

Phương pháp của tôi chịu ảnh hưởng lớn bởi các hướng dẫn của Alex Gaynor về review code hiệu quả. Các tiếp cận của Alex hướng đến các công trình mã nguồn mở và những người đóng góp và duy trì cho nó nhiều hơnm nhưng tôi nghĩ rằng các quy tắc cơ bản có thể áp dụng cho bất cứ software project nào (kể cả khi chỉ có một developer). Ngoài ra, tôi còn cho thêm vào một số ý kiến cá nhân, dựa vào các phần mềm mà tôi đã từng phát triển. Khi bạn viết một bản hướng dẫn review code của riêng mình, chắc chắn rằng bạn cũng sẽ làm như vậy.

Tôi rất yêu thích việc review code, trên cả cương vị người review và người được review. Tôi cho rằng cả hai vị trí đều cho ta thêm cơ hội để hiểu thêm về phần mềm đang viết, các nghiệp vụ nó hỗ trợ, và các kiến thức lập trình mà ta đã học. Tôi biết có nhiều người rất ngại review code, luôn gõ “Look good to me” ngay sau khi liếc nhìn code một cái. Và yêu cầu review code có thể gây ra nhiều lo âu và sợ hãi hơn nữa, vì sợ rằng hội chứng kẻ mạo danh của ai đó sẽ bị bại lộ.

Để làm dịu bớt căng thẳng cần có sự hợp tác từ hai phía. Nếu bạn là người submit pull request, bạn cần hiểu rõ tại sao bạn lại tạo pull request này. Nếu có một phần code bạn không chắc chắn, cần thông báo cho người review biết. Coi đó là một cơ hội học tập. Nếu bạn là người review, đừng xem nhẹ yêu cầu này. Derek Prior chia sẻ một số kĩ thuật để review code một cách lịch sự trong một bài trình bày ở RailsConf 2015. Các mẹo nhỏ này có thể áp dụng cho bất cứ ai trong project, kể cả người viết code và review code. Bạn có thể bất ngờ trước những góc nhìn của người khác về project và những thứ họ có thể dạy cho bạn.

Luôn tâm niệm rằng người ở đầu kia của pull request chỉ muốn những điều tốt nhất cho toàn bộ code, và cho và nhận các feedback một cách khiêm tốn. Bây giờ chúng ta sẽ đi qua các bước mà tôi đã làm khi reivew code. Các bước này vẫn có hiệu quả ngay cả khi tôi là developer duy nhất trong project.

Mục đích

Khi nhìn vào code, bước đầu tiên chính là hiểu được tại sao đoạn code này được viết lên, và tại sao phải tạo pull request này để thêm vào code gốc. Điều này quan trọng đối với tôi ngang với người tạo pull request. Cả hai chúng tôi đều cần phải hiểu được đoạn code này nhằm giải quyết vấn đề gì. Nếu có thể nắm được mục đích, tôi có thể tiếp tục hướng đến một lần review code hoàn hảo. Nếu không, tôi vào người tạo pull request cần một cuộc trao đổi về vấn đề này.

Thiết kế

Đây là bước thực sự bắt đầu nhìn vào code thực tế. Thường thì tôi sẽ bắt đầu nhìn vào tổng thể các thay đổi, các điểm khác biệt so với code cũ, để biết được trọng tâm các thay đổi được cài đặt ở đâu. Sâu thêm một chút nữa, tôi sẽ nhìn đến các phần unit test, để biết được phần mềm sẽ phản ứng thế nào với các thay đổi này. Nếu không có các bộ test mới, tôi sẽ note lại để review kỹ hơn, hoặc yêu cầu người tạo pull request giải thích vì sao việc tạo bộ test lại không cần thiết, hoặc quá tốn công sức để cài đặt.

Sau đó, tôi sẽ quan sát vị trí của các thay đổi trong toàn bộ cấu trúc của phần mềm. Có thay đổi nào trong controller hay không, hay thay đổi trong một model? Thay đổi có ảnh hưởng đến việc vận hành của các thư viện ngoài hay không? Có thể cải tiến cấu trúc code hay không? Các vấn đề gặp phải cần được đưa ra trao đổi với team để code đẹp hơn.

Tìm hiểu những case study Code Review điển hình với chuyên gia đến từ Bloomberg vào ngày 28/08 tại Tp.HCM. Đăng kí ngay!

Cài đặt

Bây giờ tôi đã hiểu được đoạn code đó định làm gì, và biết được người cài đặt định cho code làm việc ở đâu. Câu hỏi cần được trả lời bây giờ là đoạn code đó có hoạt động đúng như dự định, không có tác dụng phụ hay không? Hay nó có gây ra bug mới, hoặc ảnh hưởng đến performance? Code có nghĩa hay không? Sau ba tháng nữa khi nhìn lại code có thể hiểu được hay không? Code documentation có tác dụng gì không? Phần viết test đã bao quát các trường hợp thực thế chưa?

Bảo mật

Sự quan tâm đến vấn đề bảo mật có thể được hợp nhất với phần cài đặt, nhưng tôi nghĩ đây cũng là một tiêu chí quan trọng cần được đưa ra và review riêng biệt (có thể là cả performance, nhưng vấn đề bảo mật cần được đưa lên đầu). Phần code thay đổi cần phải có câu trả lời thỏa đáng cho các câu hỏi: Phương pháp sử dụng để authentication và authorization có phù hợp không? Phần thay đổi của code có mở ra lỗ hổng bảo mật nào không? Có dữ liệu nhạy cảm nào được lưu trực tiếp trong code thay vì lấy biến môi trường không? Một số câu trả lời có thể được tìm thấy ở một số máy thử tự động, nhưng phần còn lại yêu cầu sự am hiểu nhất định về quy luật vận hành của phần mềm.

Cú pháp

Theo lý tưởng, là một code reviewer, ta không cần phải tốn nhiều thời gian để check indent hay số dòng của mỗi method. Các thao tác đó có thể được làm tự động, và khi một developer cần được review, ta cần cố hết sức để không cần phải review những lỗi này. Thay vào đó, ta có thể quan sát và nhắc nhở trực tiếp developer để sửa trước khi review, tránh làm loãng các review quan trọng.

Documentation

Ứng dụng của bạn có thể có một vài yêu cầu đặc biệt cần có sự chú ý trong khi review code. Ví dụ, một trong những phần mềm tôi đã từng làm, chúng tôi có một hệ thống hỗ trợ online cho user. Các developer có trách nhiệm giữ cho hệ thống này hoạt động. Để làm được điều này, mỗi khi review code, chúng tôi lại đặt ra câu hỏi documentation cho phần chức năng mới hoặc chỉnh sửa đã được update theo chưa. Kể cả khi phần mềm của bạn không có những chức năng sử dụng đến documentation như thế này, bạn vẫn có thể thử đặt ra câu hỏi này để kiểm tra lại xem các thay đổi này sẽ ảnh hưởng đến người dùng cuối như thế nào, hoặc kiểm tra lại các yêu cầu đặc biệt của phần mềm.

Tổng kết

Review code là một mindset, không phải là một quá trình. Để review code hiệu quả, bạn và nhóm của bạn cần phải quyết định xem điều gì là quan trọng để bạn và phần mềm cùng được phát triển. Tôi mong rằng cách tiếp cận này của tôi có thể giúp bạn và nhóm của bạn có thể có được một mindset về review code của riêng mình.

Techtalk via viblo