Reviewer – Công việc không dễ dàng

Posted by

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

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ưaCó ả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

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à Reviewer và Submitter. 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

  • 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. 😀

  • 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.

Leave a Reply

Your email address will not be published. Required fields are marked *