Reviewer - Công việc không dễ dàng
review code
3
White

Văn Đức Thái viết ngày 23/07/2018

1. Tản mạn ngoài lề

Có một câu hỏi mà chả biết hỏi ai. Cứ hỏi đây xem ai trả lời được không thì trả lời. Hoặc may thì gặp được admin :)).

Tình hình 2 bài gần nhất của mình bị rớt hạng trên Bài viết hay sau 2 đến 3 ngày đầu lọt vào. Lúc đầu cũng ko để ý nhưng cả 2 bài đều rớt hạng.

https://kipalog.com/posts/Ban-thuoc-loai-Dev-nao
https://kipalog.com/posts/Send-mail-with-Laravel--gmail

Mình cũng ko rõ lắm cách tính xếp hạng hay mình có vi phạm luật lệ nào không. Hoang mang quá. :o

Chủ đề hôm nay mình xin chia sẻ là về vấn đề Review code trong dự án.

- Thế nào là review code cho nhau, khó khăn, thuận lợi.
- Làm thế nào để cải thiện các vấn đề để việc Review thật sự hiệu quả.

2. WHAT: Khó khăn và thuận lợi khi Review code.

Trước hết là thế nào là Review code. Nói nôm na là một Dev code xong thì ko phải là xong. Không phải thích code gì thì code. Viết gì thì viết. Một đoạn code viết xong thì phải có người Review, kiểm tra lại code đã đúng Coding convension chưa, Logic đã chuẩn chưa, Có ảnh hưởng tiềm ẩn gì không, bla, bla.

Code thì Dev code. Vậy ai Review? Là Dev cùng dự án (Review chéo). Hoặc PM, CTO trong dự án (Người có trình cao hơn).

a. Khó khăn

  • Review code làm mất thời gian.

Đừng nghĩ việc Review code nó đơn giản. Không chỉ là xem kiểu Cưỡi ngựa xem hoa. Phải hiểu specs đó làm gì, tính năng ra sao. Hướng đi của Dev đã chuẩn chưa. Cách làm đã tối ưu chưa. Có ảnh hưởng logic đến các phần khác không? Bla bla

Thông thường thì với một phần code khoảng 500 dòng thì mất khoảng vài tiếng để Review.

  • Tăng thêm quy trình, rắc rối trong dự án.

Thêm một phần Review thì chắc chắn quy trình của dự án sẽ to thêm rồi. Mỗi tội không có Review thì cũng ko được.

  • Bất hoà trong team

Vấn đề này thì đúng là như cơm bữa trong team.

Bố code chuẩn vãi cả chưởng. Cứ hay bắt lỗi này nọ. Cùng một vấn đề nhưng giữa 2 Dev có 2 cách giải quyết khác nhau. Bất đồng quan điểm, thế là cãi nhau thôi. Mà vụ này còn to hơn Vụ cãi nhau giữa Tester và DEV

Vậy nguyên nhân xuất phát từ đâu? Là ... do

  • Sự lười và lạc quan của developer

Một Dev khi code thì đôi lúc cũng tự tin thái quá về cách làm của mình, nghĩ cách của mình là chuẩn. Nên sẽ có trường hợp đứng ở view của cá nhân mà review cách làm của người khác. Xem nhẹ cách làm của người khác.

Còn một nhóm nữa là: Lười Review. Thật ra sếp bắt Review code, thế ra cũng mở Pull Request của đồng nghiệp ra. Ậm ừ gật gật rồi cho pass. Đọc khá dài, logic thì chả hiểu méo gì. Thành ra lười.

Vậy tại sao lại Review code. Là vì...

b. Ưu điểm, lợi ích

  • Cùng nhau tìm ra bugs trước khi tester và khách hàng thấy nó

Thật ra cùng đội Dev với nhau thì cùng nhau Review để tìm ra Bug rồi Đóng cửa bảo nhau thì vẫn tốt hơn nhiều để đội Tester biết. Bách nhục lắm. Tệ hơn nữa để Bugs lên Khách hàng thì thôi rồi. Ăn đủ.

  • Nâng cao chất lượng mã nguồn

Cái này chính là lợi ích lớn nhất của việc Review code. Việc trong dự án có nhiều Dev cùng code là chuyện bình thường. Dev A code về phần Resgiter User giỏi chẳng hạn. Khi review code của Dev B code về phần này. Có thể góp ý những cách hay. Những cách giải quyết vấn đề bảo mật, send mail, ... Mỗi ông góp những cách hay cho mỗi phần một ít thành ra cả mã nguồn ngon nghé ngay.

c. Học cái hay của người khác

Dev B ở trên được Dev A góp ý cho hướng giải quyết rất hay về việc Send mail. Thế là từ đó được thêm một kiến thức mới nữa.

d. Tránh được các lỗi qua các lỗi của người khác

Lại Dev B review code lại cho Dev A. À, cu A mắc lỗi ở logic thanh toán hóa đơn. Lần sau chắc mình cũng tránh được lỗi này thôi.

Review code giúp trình độ của developer ngày càng tăng

Và đây chính là WorkFlow của việc Review code

alt text

OKIE, chúng ta đã hiểu về Review code. Những khó khăn, thuận lợi của việc Review. Câu hỏi đặt ra là làm thế nào để giải quyết những vấn đề xung quanh Review. Làm thế nào để Review code thật sự hiệu quả.

3. HOW: Review phải thực sự hiểu quả.

Review code: Có 2 đối tượng là ReviewerSubmitter. Mỗi ông hoàn thành tốt phần mình thì Review code sẽ hiệu quả thôi. Easy như một trò đùa.

a. Reviewer

  • Đưa ra lời nhận xét rõ ràng và lịch sự.

Khi review thì bạn sẽ phải comment trên Pull Request của người khác, chứ cũng chả ai phải đến tận bàn mà nói đâu.

Trước hết phải rõ ràng. Ví dụ thay vì

Chỗ này sai rồi.

thì phải

Trong trường hợp User quên Pass thì phải redirect đến trang quên pass. 
Trong ô nhập mail thì phải xác nhận xem mail đó có trong DB chưa. 
Chưa thì báo lỗi, chuyển về trang đăng ký. Rồi thì send một link về mail để User có thể đổi pass.

Đến nữa là phải lịch sự. Biết là đang ức chế lắm vì thằng này code ngu *** tả nổi. Nhưng cũng phải

Theo mình thì đoạn này nên xử lý thế này, xử lý thế nọ.

Đấy, thế người được Review cảm thấy nhẹ lòng hơn không.

  • Thực hiện việc review sớm, không ngâm quá 2 ngày

Khi được assgin để Review code người khác thì đừng để quá lâu rồi Review. Review sớm, nếu có bug thì còn sửa sớm. Nếu pass thì cũng cho nó gọn để yên tâm làm phần khác.

  • Hãy là người review có tâm

Cái này thì cực kỳ cực kỳ quan trọng. Đôi khi một phút yếu lòng mà ta quên đi mình phải là một Reviewer có tâm. Thành ra cũng chỉ ậm ừ gật gật. Rồi cũng Cưỡi ngựa xem hoa. Hãy đóng góp tích cực những hướng giải quyết hay. Kiểm tra coding convension kỹ càng. Tính logic, chức năng của tính năng này. ....

  • Khi chấp nhận code, hãy comment và bấm nút approved để mọi người biết: LGTM (Look good to me)

Review xong mà pass cũng comment khen đểu vài câu, mất gì. Kiểu Làm giỏi thế mày (LGTM) =))

b. Submitter

  • Bạn chính là người reviewer đầu tiên, hãy tự review chính mã nguồn của mình

Thì mình code xong thì cũng phải review lại xem có ổn không đã, ngon nghé lại để người khác review. Đừng chủ quan. Đừng để người khác review chỉ ra những lỗi rất ngớ ngẫn như Sai text Thừa chấm thừa phẩy, ... Ăn chửi đó.

  • Không push code rác

Đừng push những code mà chả liên quan đến tính năng đang làm. Nếu là phần khác, hãy tạo Pull Request khác.

Hoặc là những code kiểu
alt text

  • Giữ cho mỗi Pull Request dưới 500 LOCs

Thế thôi, dài quá chả ma nào dám đọc đâu.

  • Ghi title và description của PR cẩn thận, giải thích để reviewer hiểu

Cái này rất quan trọng. Khi bạn ghi title và description của PR cẩn thận thì bạn để tiết kiệm 50% thời gian cho Reviewer. Chả ai muốn vào Reviewer lại đi lần mò tìm nó làm gì, chức năng ra sao. Việc ghi title và description cẩn thận thì cũng giúp Reviewer có hướng review chuẩn hơn.

Review code tạo ra một team mạnh mẽ

c. Những cái quan trọng khác

  • Dùng tool để quét, loại trừ các lỗi cơ bản: Lint, Sonarqube

Giờ các ngôn ngữ, các Framework hỗ trợ Tool nhiều. Hãy tận dụng nó. Đừng bắt Reviewer chỉ cho bạn những lỗi mà ngớ ngẩn. Ức chế rồi lại cãi nhau thôi.

  • Ban đầu review chi tiết, sau tiến tới review tổng thể

Reviewer kiểm tra chi tiết về coding convention, logic, ... Sau đó reviewer tổng thể xem đúng chức năng chưa. Có đúng luồng với các phần khác không.

  • Hãy đấu tranh cho những gì bạn tin là đúng nhưng cũng cần biết chấp nhận sự thật

Khi cảm thấy phần mình làm đúng, người reviewer chỉ ra cách mới mà chưa hay bằng thì cứ mạnh dạn đấu tranh. Đấu tranh chứ không phải chửi nhau nhé. Chia sẻ thẳng thắn để 2 bên cùng tiến lên. Mà quan trọng là đừng vì cái tôi cá nhân mà bảo thủ cho rằng code mình là bá, là thứ tồn tại duy nhất, thằng khác góp ý hay không không quan trọng. :D

  • Không có sự khác biệt về trình độ, junior và senior tất cả đều phải review.

Thường thì các dự án thì Trình độ cao review xuống Trình gà mờ. Nhưng không, review chéo hết.

Em gà, em biết cái qué gì mà review

Review cách làm người ta, cách họ coding convention. Mà đôi khi biết đâu Senior lại code lỗi. Mình sẽ bắt lỗi =)).

  • Không phụ thuộc vào senior => nút thắt cổ chai

Đôi khi trong dự án, nhiều Team quá phụ thuộc vào 1 Senior, tất cả code của Dev thành viên đưa cho 1 senior. Thành ra dẫn đến tình trạng Review không kỹ, không kịp review. Hãy để Review chéo trong team. Thứ nhất nâng cao trình độ thành viên, thứ nữa là giảm tải công việc cho nhau. Cùng nhau xây dựng một team mạnh.

Nguồn: Công ty

Hết mất rồi. :(

Hãy comment đóng góp ý kiến nhé mọi người. À, mà trả lời giúp mình Phần đầu của bài nhé. :D

Bài Bái

(。◕‿◕。) NyLaa (。◕‿◕。)

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Văn Đức Thái

17 bài viết.
93 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
25 18
1. Tản mạn ngoài lề (Ảnh) MySQL với DB thì có cái quần què gì chứ? Đọc thôi để thấy cũng vài cái hay ho và này nọ. 2. MySQL: MyISAM & InnoDB & ...
Văn Đức Thái viết 1 năm trước
25 18
White
24 13
1. Tản mạn ngoài lề Khuya vật vã. Chẳng ngủ được. Mà chẳng biết làm gì giữa cái lúc dở dở ương ương này. Viết blog vậy :(. Bài viết dành cho các...
Văn Đức Thái viết 1 năm trước
24 13
White
18 3
1. Tản mạn ngoài lề (Ảnh) Khi gặp một vấn đề trong cuộc sống bạn sẽ làm gì? Người yêu đá đít, cuối tháng hết tiền lương, sếp đì trên đi xuống, bl...
Văn Đức Thái viết 1 năm trước
18 3
Bài viết liên quan
White
17 7
Áp dụng code review trong quá trình phát triển dự án sẽ mang lại lợi ích to lớn cho nhóm lập trình cũng như cho từng thành viên trong nhóm. Bài viế...
Mido viết hơn 4 năm trước
17 7
White
8 2
Về cơ bản có 3 phương pháp review code là review chéo (giữa 2 lập trình viên với nhau), cả team ngồi họp cùng review và cuối cùng là technical lead...
Lê Anh viết hơn 3 năm trước
8 2
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
17 bài viết.
93 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!