Code reviews - how to make it awesome part 1

Hàng ngày chúng ta review rất request change code (hay gọi là pull request github hay merge request gitlab) từ team member. Chúng ta có thể nhận ra việc review này thường tập trung vào tìm bug trong các request change từ team member. Có khi nào bạn quan tâm đến việc truyền đạt các issue mình tìm ra hơn là tập trung vào tìm các issue đó không? bạn có băng khoăn về các cách mình sẽ tiếp cận để người gởi các request change cảm thấy thoải mái hay không. Chúng ta hay tìm hiểu một số vấn đề giúp cải thiện kỹ năng review code nhé.

Thuật ngữ code review có thể hiểu nó bao gồm một loạt các hành động nối tiếp nhau, đơn giản thì đọc vài dòng code của team member cho đến những buổi discuss code giữa toàn team 5 - 10 members mà chúng ta sẽ đi sâu đến tận ngóc ngách. Hiểu một cách đơn giản thì code review sẽ như hình dưới đây. Những người tham gia vào code review bao gồm author, đây là người viết code và gởi nó cho team review, thành phần còn lại là reviewer - người sẽ đọc và xem code đã đúng, đủ chuẩn để merge vào codebase của team hay chưa. Reviewer có thể là một hoặc vài người tuỳ theo yêu cầu chung của team. Để bắt đầu code review, author phải tạo một list các thay đổi chứa các thay đổi trong code base và gởi cho reviewer. Code review diễn ra theo từng lượt: author gởi các thay đổi cho reviewer, reviewer đọc code change và gởi feedback lại cho author. Có thể có một hoặc nhiều lượt review như thế này với một change request. Quá trình review kết thúc khi reviewer approve request change từ author.

Khi một coder gởi một change request mà họ nghĩ nó tốt, bạn với vai trò là reviewer phản hồi bằng một list các lý do tranh luận ngược lại với luồng suy nghĩ của author. Đó thật sự là những phản hồi khá là khó nuốt đối với người được review. Rất nhiều author sẽ dễ dàng nhìn nhận các phản hồi về code người đó viết như là hàm ý trình độ code của author còn kém, nhất là đối với các developer nhiều tuổi. Code review là cơ hội để cho team member có thể chia sẻ kinh nghiệm và đưa ra các quyết định về kĩ thuật cho dự án. Nhưng những việc trên có thể không thể tiến hành nếu author cứng nhắc hoặc có cái tôi quá lớn và hiểu code review theo hướng tiêu cực. Chúng ta đều là developer, việc trình bày suy nghĩ bằng văn viết đôi khi sẽ gặp khó khăn, Nếu gặp dự án nào yêu cầu review bằng tiếng anh nữa thì sẽ gặp rất nhiều hạn chế, khi đó việc misscommunication giữa team member sẽ rất lớn. Author và reviewer sẽ mất kênh liên kết trục tiếp nên nếu vấn đề quan trọng cần bàn bạc thì reviewer cần cẩn thận trong việc nêu vấn đề. Một số điều sau đây sẽ giúp quá trình trên được diễn ra một cách êm đềm hơn, cả author và reviewer đều win-win.

Let computer do the boring parts

Trong công việc hàng ngày như implement feature, fix bugs, trao đổi confirm giữa team member, độ sẵn sàng để tập trung cho việc đọc code khá là khan hiếm. Sức chịu đựng về tinh thần còn kém hơn. Việc review code bắt buộc bạn phải tạm hoãn các công việc đang làm, ngắt dòng suy nghĩ vì đây là một việc yêu cầu sự tập trung cao nếu bạn thực sự là reviewer có tâm. Nhưng đôi khi chúng ta phải tốn sức vào những việc như check code convention thay vì review logic và business của code. Điều đầu tiên, hãy để máy tính làm phần việc chán ngắt này 1 cách tự động, chính xác đến tuyệt vời và đỡ hại mắt cho chúng ta. Dưới đây là so sánh nếu reviewer phải đi review code convention và để máy tính làm việc đó: Chúng ta chỉ cần dùng các công cụ giúp format code trong quá trình code là đã cover được vấn này. Hoặc các công cụ hỗ trợ continuous integration cũng giúp ích rất nhiều trong việc phát hiện các lỗi về convention. Author phải fix các lỗi này trước khi gọi review. Automation tool giúp reviewer có thể tập trung vào những phần thú vị hơn như check logic của code, các lỗi về business, độ ổn định của code ... Một điều nữa nếu các vấn đề được check và report bởi tool thì sẽ dễ dàng được fix từ hướng của author hơn là nghe feedback từ reviewer.

Apply code convention

Tranh cãi về code convention là cuộc chiến không hồi kết. Nếu bạn còn nhớ một câu đùa rất thú vị.

Trên thế giới chỉ có 2 loại dev
If {
}
và 
If 
{
}

Cách tốt nhất để tránh việc này là nên áp dụng 1 chuẩn chung cho team. Cả team phải follow convention. Một bộ convention tốt sẽ bao gồm tất tần tật từ naming, spacing, indent đến việc sử dụng hàm, biến trong ngôn ngữ. Nếu bộ convention của bạn không nhắc đến vấn đề khi team gặp phải là lúc thảo luận để update bộ convention để tránh các tranh cãi xảy ra sau này.

Start your review immediately

Nếu có thể, hãy review code ngay khi author yêu cầu. Khi review code và cho phản hồi đến author hãy làm nó một cách cẩn thận, nhưng hãy start nó ngay khi bạn có thể. Khi chúng ta review ngay lập tức, chúng ta sẽ tạo ra được thói quen, team member cũng sẽ ước chừng được số lượng code trong 1 change list mà team có thể review dễ dàng nhất. Thử tưởng tượng nếu một chức năng cần 1000 line code, nếu submit 1 pull request gồm 1000 line thì thời gian review cho cả team là nửa ngày. Nếu break nhỏ chức năng ra làm 3 hoặc 4 lần thì thời gian review sẽ giảm xuống, kéo theo tốc độ của team cũng sẽ tăng lên vì reviewer không tốn thời gian dài để đọc các thay đổi, người author cũng không phải chờ các feedback quá lâu mà có thể làm tiếp.

Start high level and work your way down

Đối với các bạn junior có thể mỗi lần review số lượng comment, feedback rất nhiều, nó có thể làm choáng ngợp người viết. Cách tốt nhất trong trường hợp này là chúng ta nên chia nhỏ các round review. Ở một, hai lần đầu chúng ta sẽ tập trung vào logic của code, sự phức tạp của function. Khi các feedback trên đc fix thì chúng ta sẽ review kĩ hơn đến những thứ lặt vặt như tên hàm hay tên biến, comment code. Các comment suggest nên đưa vào round sau để tránh author sẽ tập trung tranh luận mà ít quan tâm đến những vấn đề logic, độ phức tạp của code. Kĩ thuật này sẽ giúp cả author và review tiếp cận change list một cách khoa học hơn.

Be generous with code examples

Code author nếu là một người cởi mở, dễ tiếp thu thì mọi việc sẽ dễ dàng hơn. Review code sẽ là dịp để họ học hỏi và tránh khỏi những sai sót sau này. Nhưng trong thực tế, có nhiều yếu tố sẽ tác động và author sẽ hiểu feedback từ bạn một cách tiêu cực, kèm theo là sự phản kháng sau đó. Có thể áp lực deadline hoặc mối quan hệ giữa 2 người không tốt đẹp lắm nên author sẽ không tin tưởng vào review của bạn. Một cách hay để tiếp cận và author thoải mái hơn khi đọc feedback là thay vì nhận xét không hãy gởi kèm code example, pesudo code, giúp cho họ hình dung được mình nên làm gì, sửa như thế nào để có thể so sánh code hiện tại và feedback từ reviewer. Điều này giống như bạn đang trao cho họ một món quà. Khi bạn viết ra một vài gợi ý, bạn đang cho thấy mình là một reviewer cực kỳ có tâm với đối phương. lấy ví dụ author submit đoạn code sau

urls = []
for path in paths:
  url = 'https://'
  url += domain
  url += path
  urls.append(url)

Nếu chúng ta chỉ nhận xét như: " Khởi tạo array với các element như trên" thì author có thể không biết ngay được mục đích của bạn. Trường hợp này chúng ta có thể suggest như sau sẽ đạt hiệu quả cao hơn.

urls = ['https://' + domain + path for path in paths]

Nếu cần thiết thì bạn có thể new branch và refactor một lượng lớn code để author có cái nhìn rõ ràng hơn. Nhưng cũng cần phải thận trọng, không nên viết kĩ quá author sẽ có cảm giác bạn đang code giùm người khác, có vẻ hơi thể hiện quá đà. Mình nghĩ 2 đến 3 đoạn pesudo code là vừa phải nếu cần thiết.

Hàng ngày chúng ta phải làm việc với cả code của chính chúng ta và teammate thế nên hãy tạo ra bầu không khí thân thiện, mọi người cùng tranh luận một cách khoa học. Để review code không là nơi thể hiện trình độ cá nhân một cách thái quá mà hãy là nơi mọi người cùng học thêm những điều mới, biết thêm các best pratice và cùng nhau tiến bộ mỗi ngày.