Chuyện Review Code - Còn cái nịtttt ???

What's up guys....

Bạn có thể đọc bài viết này tại trang blog cá nhân của mình: https://tienvm.com/chuyen-review-code-tinh-nghia-anh-em-chac-co-ben-lau

Chợt một ngày mùa hè nóng oi ả, nóng tỉnh cả ngủ không có việc gì làm thì thôi lại lôi máy ra viết bài blog cho đỡ buồn vậy. Hôm nay mình sẽ tán gẫu với anh em về một chủ đề chúng ta chắc chắn sẽ gặp khi đi làm. Đó là chuyện "Review Code" hay "Code Review". Thôi tiện gọi là "Review code" rồi thì anh em đừng bắt bẻ mình phải gọi là gì nhé, tội mình lém :v Giờ thì bắt đầu thôi

Cứ theo nguyên tắc 7 vợ 1 chồng(7W-1F) thì chúng ta sẽ có khung sườn cho bài hôm nay như sau:

1. What? Review code là gì?
2. Why? Tại sao phải review?
3. When? Khi nào thì thực hiện review?
4. Whose? Review code của ai?
5. Where? Review code ở đâu?
6. Who? Ai là người chịu trách nhiệm review code?
7. Which? Review những cái gì?
8. How? Review như thế nào?
9. Chúng ta học được gì từ việc review code?
10. Chuyện bên lề

À từ khoá hôm nay là "Review code" nên có thể sẽ lặp từ hơi nhiều thì anh em thông cảm nhé, mình sẽ cố gắng hạn chế. Khổ chủ đề nó thế thì phải đề cập thôi, chứ mình có cố tình đâu :v Anh em đừng gạch đá mình nhớ

Okayy, hòm hòm rồi, giờ thì bắt đầu thôi

1. What? Review code là gì?

Theo Wikipedia: Code review is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the persons must not be the code's author.

Về cơ bản thì anh em hiểu đơn giản như này: Review code là một hoạt động đảm bảo chất lượng code, trong đó thì một hoặc nhiều người sẽ review bằng cách xem và đưa ra nhận xét về một đoạn code nào đấy để đảm bảo đúng requirement, chất lượng code và sản phẩm.

Ví dụ thực tế như này:

Dev A code xong và tạo pull request -> Dev B, C, D vào review code phần thay đổi và review 1 vài case như:

1. thằng devA code có bị sai logic không?
2. Nhìn vào requirement, nó đã cover tất cả các case hay chưa?
3. Code nó có đảm bảo tuân thủ theo checklist hay không?
4. Tại sao lại dùng cái này, mà không dùng cái kia???

Và còn rất nhiều câu hỏi khác...

Nếu thấy có vấn đề thì dev B, C, D sẽ để lại những comment kiểu như "Code như sh**", "Phần này sai spec, check lại em nhó", "Tại sao lại đặt tên biến như này?", "Chú chưa viết test case cho code logic à? Bổ sung thêm đi em"...abc, xyz...Nói đến đây chắc anh em hiểu rồi nhỉ :v

2. Why? Tại sao phải review code?

Như anh em đã thấy ở phần 1, một vài lý do và lợi ích đi kèm của việc review code có thể kể đến như sau:

1. Đầu tiên là việc làm đúng, đủ requirement của khách hàng, chủ sản phẩm, tránh bị miss.
2. Chất lượng code tốt hơn: dev A junior, dev B, C là senior vào comment thì có phải chất lượng code của dev A có phải được cải thiên không :v
3. Tuân thủ theo flow, style, checklist của team, dự án.
4. Giảm thiếu bug không đáng có(devA thấy code okay nhưng dev B, C comment đoạn code này có thể gây ra bug...Lại cùng nhau ngồi mổ xẻ phân tích)
5. Chia sẻ kiến thức cho đồng nghiệp

Và còn rất nhiều lợi ích khác nữa....

3. When? Khi nào thì thực hiện review code?

Việc review code sẽ được thực hiện khi anh em làm xong task và tạo Pull Request(Hay viết tắt là PR). Sau khi tạo PR thì anh em cứ vứt lên chat channel như teams, slack, skype..v.v hoặc assign cho ai chịu trách nhiệm để thực hiện review code thôi :v Mỗi lần tạo PR mình lại đi vận động hành lang "Anh H chị T eii, review e cái PR. E vừa tạo rồi đấy" :v It's easy

4. Whose? Review code của ai?

Tất nhiên là đi review code của người tạo Pull Request rồi :v

5. Where? Review code ở đâu?

Anh em sẽ review ngay tại Pull Request trên Github, GitLab, Bitbucket ..v.v. rồi. Anh em muốn confirm hay góp ý dòng nào thì cứ comment trực tiếp tại dòng đấy thôi, giờ mấy cái source management đều hỗ trợ phần này hết rồi.

Thêm cái ảnh cho anh em dễ hình dung.

6. Who? Ai là người chịu trách nhiệm review code?

Sau khi tạo PR thì dev khác sẽ vào review, tất nhiên là mình đang nói trên khía cạnh của dev. Còn nếu tester, PM, PO, BrSE ..v.v đọc được code thì vẫn có thể vào review bình thường chứ không cố định chỉ có mỗi anh em dev nhé. Cái này thì sẽ tuỳ thuộc vào quy trình của team quy định ai sẽ là người review code ở FE, BE, một người hay là cả team review...

7. Which? Review những cái gì?

Anh em sẽ review tất cả những phần code thay đổi so với version gần nhất xem có vấn đề gì không. Ví dụ tên biến, tên hàm, logic này đã ổn chưa, tại sao không dùng pattern này mà lại đi dùng pattern kia, viết như này có ảnh hưởng đến performance không, vân vân và mây mây..

8. How? Review code như thế nào?

Thường thì mỗi team sẽ có một checklist riêng quy định những rule mà anh em cần tuân theo. Ở đây mình ví dụ cho anh em một vài rule như:

1. Có push nhầm public key lên không?
2. Đặt tên biến, function như này đã đúng chưa?
3. Đoạn này performance như này đã ổn chưa, có tối ưu được không?
4. Đoạn này tại sao lại theo pattern này mà không phải là pattern kia?
5. Tại sao không sử dụng method có sẵn của framework mà lại đi xử lý rối rắm như này?

Và còn rất nhiều phần cần phải review khác nữa.Anh em có thể tham khảo ảnh dưới đây:

9. Chúng ta học được gì từ việc review code?

Câu trả lời là học được rất nhiều. Hồi mình mới đi làm, mỗi khi tạo PR mình lại đi vận động hành lang nhờ những anh chị có kinh nghiệm review code cho mình. Khi mình còn non và xanh mà lại được những anh chị có kinh nghiệm comment góp ý thì có phải là mình sẽ được mở mang tầm mắt không :v

Như đề cập ở phần 2. Why? Tại sao phải review code?. Việc review sẽ giúp anh em tránh miss spec, nâng cao kiến thức và đôi khi cải thiện cả logic vì những đoạn code mình xử lý quá rối rắm, trong khi đơn giản chỉ cần xử lý abc, xyz là xong. Code của mình mình nghĩ nó okay, chắc là gút chóp rồi nhưng khi để người khác review thì đúng là "Ối dồii ôi" :v

Nhiều cái đầu ngồi review thì chắn chắn sẽ hơn 1 cái đầu rồi :v

Thỉnh thoảng sẽ lại có conflict quan điểm về một đoạn code nào đấy. Anh em lại comment loạn xạ mổ xẻ ra tìm ra phương án tối ưu nhất để xử lý. Nhiều khi là cũng khua tay khua chân đấy, nhưng mà anh em phải bình tĩnh để thảo luận nhé. Đừng có *** ABC, *** XYZ, Code như ****, bố *** review nữa. Anh em phải thật sự bình tĩnh nhé, chắc chắn anh em sẽ gặp chuyện này trong quá trình review code. Đấy, học được cả tính nhẫn nại rồi đấy :v

10. Chuyện bên lề

Minh xin chia sẻ một vài câu chuyện của mình liên quan đến chuyện review code.

1. Bị comment về một vấn đề quá nhiều lần: Sẽ có dự án ngoài review code bên team dev bên mình, push code sang phía khách hàng mà việc bị khách comment đi comment lại về 1 vấn đề trong nhiều PR thì chắc chắn là sẽ bị sấy tóc đấy. Đặc biệt nếu anh em làm cho khách hàng Nhật thì họ yêu cầu việc tỉ mỉ và chuyên nghiệp cũng sẽ cao hơn. => Bài học: Team có thể xây dựng 1 file excel để note lại thành lessons learned những phần nào bị KH comment nhiều lần để lần sau không gặp lại nữa hoặc đơn giản là bổ sung vào checklist khi team coding/review code.

2. Coi việc review có cũng được, không có cũng chẳng sao: Nhiều anh em rất ngại việc comment code vì nó mất thời gian, mình hoàn toàn đồng ý về điều này. Việc review code có khi mất cả 30 phút - 1 tiếng hoặc lâu hơn nếu có nhiều logic, code chỉnh sửa hoặc có team còn quy định việc người review phải checkout branch local để test qua xem có vấn đề gì không. Nhưng anh em chỉ cần nghĩ như này: => Việc review code sẽ nâng cao chất lượng sản phẩm của mình, của team mình. Nâng cao trình độ, bổ sung kiến thức cho cả mình và người được review. Anh em hiểu đơn giản là cho đi và nhận lại ý, nhiệt tình comment đóng góp ý kiến thì người khác cũng nhiệt tình lại với mình :v Mà chưa biết chừng sau chẳng may có bug thì lại chính mình đi fix cái đoạn code đấy. Thế nên là thà comment cho nó clean code từ đoạn tạo PR còn hơn để sau đọc lại 1 lố bùi nhùi chả hiểu m** gì :v

Hôm nay ngồi chia sẻ với anh em chút về chuyện "Review Code" mình đã từng trải thế thôi. Rất mong có thể chia sẻ một chút kinh nghiệm bé nhỏ của mình đến mọi người và chúng ta có cái để thảo luận :v Bạn hãy like và up vote bài viết nếu thấy nó cần thiết nhé. Nó sẽ là động lực để mình có các bài viết và các series tiếp theo. Đừng ngại để lại comment để chúng ta có thể tương tác và học tập lẫn nhau nhé :v

Đừng quên đọc blog của mình ở trang https://tienvm.com/ nhé. Bạn có thể mời mình 1 cốc coffee trên blog cá nhân của mình để mình có động lực ra thêm những bài mới :v

Thank you for reading and see you next posts :v