8 lợi ích của review code
review code
2
pair programming
1
White

Lê Anh viết ngày 20/11/2015

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 leader review. Trong bài này mình chỉ bàn về lợi ích của việc review do cả team đảm nhiệm vì theo mình đây là phương pháp review hiệu quả nhất. Một số lợi ích có thể kể đến dưới đây như :

1. Đảm bảo clean code

Review code là một trong số các phương pháp giữ code luôn sạch. Khi cả team cùng review cho nhau sẽ phát hiện ra chỗ này có thể viết ngắn hơn mà hiệu năng cao hơn, hay chỗ kia có thể áp dụng design pattern XYZ gì đó, rồi là chức năng A, module B đang bị lặp lại code quá nhiều….tất tần tật những vấn đề đó ai cũng có thể mắc phải, kể cả lập trình viên có kinh nghiệm nhưng nó không thể thoát được dưới cả chục con mắt của đội ngũ phát triển.

2. Phát hiện lỗi sớm

Đã bao giờ bạn tự tin rằng chức năng mà bạn phát triển đã hoạt động tốt, test rất nhiều lần rồi nhưng không phát hiện thêm lỗi nào cả. Nhưng rất có thể là bạn đang test thiếu testcase mà thôi. Nếu cả team nhìn vào đoạn code mà bạn viết, rất có thể một ai đó trong team sẽ phát hiện ngay ra lỗi nằm ở đoạn lệnh này hay lệnh kia mà chẳng cần phải test gì cả.

3.Nâng cao kỹ thuật cho lập trình viên

Cái này thì quá rõ ràng rồi. Bạn đã nghe nhiều đến những lời khuyên như “Muốn code giỏi thì hãy đọc code của người khác” và review code thì chính là như vậy. Bạn học hỏi cái hay của người khác và người khác chỉ ra những điểm dở của bạn. Dù rơi vào trường hợp nào thì kỹ năng của bạn sẽ tăng lên một cách chóng mặt.

4. Đồng bộ hóa công việc cho nhóm phát triển

Mình đã từng gặp trường hợp 2 người cùng phát triển một dự án nhưng họ lại chẳng hiểu gì về công việc của nhau, chức năng cho anh A phát triển thì anh B không biết sử dụng dẫn đến hậu quả là bug của ai thì người đó fix, họ không giúp đỡ được nhau nhiều trong công việc và tệ nhất là 1 trong 2 người đó mà nghỉ đột xuất thì sẽ không có người thay thế. Nếu ta áp dụng review code vào thì hiển nhiên điều này sẽ không xảy ra, ai cũng sẽ hiểu hết nội dung công việc của nhau và có thể hỗ trợ khi cần thiết.

5. Góp ý xây dựng chương trình

Anh lập trình A đang tự phát triển một phân hệ X nào đó (anh ý nhận yêu cầu từ khách hàng rồi tự phân tích thiết kế, lập trình…), hẳn là anh ấy rất tự hào và tâm huyết nhưng đến khi đưa cho khách hàng thì bị chê thậm tệ . Nếu như team tổ chức một buổi review code thường xuyên trong quá trình phát triển thì sẽ nhận được nhiều lời góp ý từ mọi người hơn. Và đương nhiên chức năng đó sẽ hoạt động tốt hơn cả về UX lẫn UI.

6. Tiết kiệm thời gian

Nghe thì có vẻ hơi thiếu logic vì làm sao mà tiết kiệm thời gian được. Khi cả team đang vắt chân lên cổ để kịp deadline, rồi giờ lại thêm cái task review này nữa thì bao giờ cho xong dự án. Nhưng hãy loại bỏ ngay suy nghĩ đó ra khỏi đầu bạn vì review code cũng gần giống như câu chuyện cái rìu “Nếu cho tôi 10 giờ để chặt cây thì tôi sẽ dành 8 giờ để mài rìu sắc”.

alt

Bởi lẽ code sạch giúp làm việc hiệu quả hơn, tránh được nhiều bug hơn và như vậy thì giảm thiểu được thời gian test và sửa lỗi. Code sạch khiến việc lập trình trở nên đơn giản và thoải mái vì vậy mà năng suất cao hơn. Chưa kể đến việc trình độ của team sẽ ngày càng tăng sau mỗi lần review, sẽ tránh gặp phải những lỗi mà trước đó đã mắc rất nhiều lần. Có thể thời gian đầu áp dụng bạn mất đến vài tiếng để review nhưng lâu dần mọi người tiến bộ nhiều về kỹ năng thì thời gian này sẽ giảm xuống.

7. Đánh giá chất lượng lập trình viên

Nếu bạn là người quản lý như PM, Technical leader, trường phòng…mà tham gia cùng review code thì đây cũng là một cơ hội để bạn nhìn nhận một cách khách quan năng lực các lập trình viên trong nhóm. Ai code dở, ai góp ý hay thì đều rõ ràng cả.

8. Thể hiện năng lực bản thân

Nếu bạn muốn thể hiện rõ năng lực của bản thân thì trong những buổi review chính là đất cho bạn dụng võ. Bạn tha hồ góp ý về kỹ thuật, design, UI/UX cho đồng nghiệp. Tuy nhiên việc góp ý phải khéo léo nếu như không muốn bị người khác đánh giá là lố, rất dễ gây mất lòng đồng nghiệp.

Đây là một bài viết trên blog apollo13.vn của mình. Rất cảm ơn các bạn đã đọc

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

Lê Anh

4 bài viết.
5 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
8 0
1. Viết code trước Những người mới bắt tay vào làm TDD thường mắc phải 1 sai lầm cơ bản đó là viết code trước sau đó mới viết test. Khi được hỏi là...
Lê Anh viết 2 năm trước
8 0
White
7 1
Chắc hẳn bạn đã từng phát ngấy khi viết media queries trong css theo kiểu này h2 { fontsize: 16px; } @media (minwidth: 768px) and (maxwidth: 1...
Lê Anh viết 2 năm trước
7 1
White
3 0
Trước đây mình có một bài viết về phương pháp (Link). Hôm nay mình sẽ giới thiệu với các bạn một phương pháp khác là startfish, tạm dịch là sao biể...
Lê Anh viết 2 năm trước
3 0
Bài viết liên quan
White
15 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 gần 3 năm trước
15 7
{{like_count}}

kipalog

{{ comment_count }}

bình luận

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


White
{{userFollowed ? 'Following' : 'Follow'}}
4 bài viết.
5 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á!