Bạn có muốn tìm ra cách tốt nhất duy nhất để giảm đáng kể chi phí phát triển không? Bạn cũng muốn ứng dụng của mình có chất lượng tuyệt vời và có thể dễ dàng bảo trì thậm chí rất lâu sau khi phát hành? Có lẽ bạn muốn biết cách sử dụng một quy trình được phát minh bởi những người khổng lồ trong ngành, như IBM hay NASA, và thích nghi với phương pháp Agile? Nếu có thì hãy tìm hãy đọc tiếp bài này.
Trong bài viết này, cafedev muốn nói với bạn về quá trình Review code: nó là gì? và tại sao cafedev tin rằng sự hiện diện của nó là rất quan trọng để phát triển phần mềm thành công.
Nội dung chính
Cơ sở lý luận
Làm sai là do con người. Không có sản phẩm nào là hoàn hảo trong lần chạy đầu tiên của nó. Đó là lý do tại sao các tác giả luôn được hỗ trợ bởi các biên tập viên. Các kỹ sư phần mềm sẽ không thông minh khi tin rằng một người có khả năng một tay luôn tạo ra code mà không có lỗi. Bởi vì người đó được review code nên code của anh ta ít hoặc không có lỗi. Đây là một quá trình kiểm tra những người khác, kiểm tra code với mục đích tìm ra bất kỳ khiếm khuyết nào càng sớm càng tốt. Nó không thay thế đảm bảo chất lượng mà chỉ đóng vai trò là một phần không thể thiếu của quy trình tổng thể, cùng với Test thủ công và tự động.
CHÚ THÍCH:
Có nhiều cách khác nhau để thực hiện Reviews code, một số rất cổ xưa và tốn thời gian. Ở đây, chúng tôi sẽ chỉ đề cập đến review code không đồng bộ được thực hiện với sự trợ giúp của các công cụ chuyên dụng như Pull Request của GitHub. Đây là phù hợp nhất cho một môi trường Agile.
1. Nó tạo ra chất lượng đi kèm với giá cả.
Khi nói đến chủ đề reviews code và chi phí dự án, phần lớn các bài viết lấy lại cùng một dữ liệu cũ. Giả sử tìm và sửa lỗi trong giai đoạn đầu của chu kỳ phát triển phần mềm lên tới 1000 lần (một nghìn lần, vâng, bạn đọc đúng) rẻ hơn trong giai đoạn sau. Mặc dù sự gia tăng theo cấp số nhân như vậy là đúng đối với các dự án waterfall và ngay cả những dự án Agile được code lâu.
Hơn một nửa số lỗi được phát hiện thông qua đánh giá
Một vòng đời phát triển phần mềm đơn giản hóa trông như thế này: đặc tả, thiết kế, phát triển, thử nghiệm, thực hiện và bảo trì. Thông số kỹ thuật thường được chuẩn bị bởi khách hàng, vì vậy nơi sớm nhất mà nhóm phát triển có thể mắc lỗi là trong các giai đoạn thiết kế và phát triển. Việc review code xảy ra chính xác sau đó, trước khi bất kỳ tài liệu hoặc code nào được commits vào dự án.
Nghiên cứu cho thấy rằng hơn một nửa số lỗi được phát hiện thông qua các review. Con số chính xác rơi vào khoảng 60-85%. Hơn nữa, các review thường phát hiện ra các lỗi khó có thể tìm thấy thông qua bất kỳ phương tiện nào khác. Kết hợp điều đó với kiến thức từ các đoạn trước và rõ ràng có thể tiết kiệm được một khoản chi phí khổng lồ nhờ review code.
Đánh giá mã tiết kiệm thời gian và tiền bạc
Cho đến nay là tốt, nhưng người ta có thể hỏi xem bản thân review code chi phí bao nhiêu? Có đáng không? Rốt cuộc, nó chiếm thời gian quý giá (và tốn kém) của các nhà phát triển – chính xác là khoảng 10%. Điều này nghe có vẻ rất nhiều, nhưng hãy xem xét những điều sau đây. Tìm một lỗi trong đánh giá là một quá trình ngắn: đọc mã, tìm lỗi, chỉ ra và sửa nó. Tìm một lỗi trong quá trình kiểm tra hoặc thậm chí sau khi phát hành đòi hỏi nhiều bước hơn: tìm lỗi, cố gắng tái tạo nó, tìm nguồn của nó, sửa lỗi, kiểm tra và phát hành phiên bản mới. Thời gian lâu hơn = chi phí cao hơn.
Nói chung, không thể tranh cãi rằng việc review code giúp tiết kiệm thời gian và tiền bạc.
2. Nó có nhiều lợi ích cho việc bảo trì sau này
Từ quan điểm của một developer, có vài điều nản lòng hơn là phải tiếp quản và duy trì một dự án kém. Từ góc độ kinh doanh, có vài thứ tốn kém hơn việc phải viết lại toàn bộ ứng dụng vì nó đạt được trạng thái hầu như không thể cập nhật và hỗ trợ. Hãy nghĩ về nó như một động cơ thúc đẩy doanh nghiệp của bạn. Một động cơ theo nghĩa đen. Bạn có muốn nó gọn gàng và ngăn nắp, được bôi dầu tốt và dễ dàng sửa đổi hoặc một vật bất ly thân, quái dị, nơi bạn có thể chạm vào bất cứ thứ gì vì sợ thứ gì đó nổ tung?
Một ứng dụng không bao giờ hoàn thành đầy đủ. Có các bản cập nhật liên tục, sửa lỗi hoặc di chuyển sang các phiên bản mới của hệ điều hành. Đó là lý do tại sao một chương trình dễ bảo trì là rất quan trọng. Điều này được thực hiện thông qua việc áp dụng một hướng dẫn phong cách thống nhất và tuân thủ các nguyên tắc tốt chung, chẳng hạn như SOLID hoặc DRY. Review code là cách duy nhất để đảm bảo rằng tất cả các lập trình viên tuân theo các thực tiễn đã nói ở trên.
3. Học hỏi. Nó rất là tốt cho làm việc cùng nhau.
Một tác dụng phụ của Review code là, hay nói rộng hơn đó là giá trị giáo dục của nó. Mặc dù không dễ dàng chuyển đổi để giảm chi phí, nhưng lợi ích của nó cho toàn đội là vô giá. Chúng tôi tin rằng không cần phải giải thích tại sao có nhân viên tốt hơn lại tốt cho bất kỳ công ty nào. Review cho phép các nhà phát triển học hỏi lẫn nhau. Thông qua việc đọc mã khác, người ta có thể nghiên cứu các kỹ thuật và giải pháp mới. Điều này đặc biệt hữu ích với các thành viên mới của đội, những người có thể rút kinh nghiệm từ nhiều năm đồng nghiệp của họ.
Ngoài ra, phần mềm thường được viết bằng các mô-đun, với mỗi người chỉ chịu trách nhiệm cho một phần của sản phẩm. Kiểm tra code của người khác để đảm bảo rằng tất cả các nhà phát triển có sự hiểu biết thống nhất về tổng thể lớn hơn. Điều này rất quan trọng, vì nó giúp giảm sự phân táng các trong project và thống nhất của mọi người.
Một khía cạnh xã hội khác của review code là hiệu ứng Hawthorne. Trong thế giới phát triển phần mềm, có một tình huống phổ biến trong đó các lập trình viên viết code tốt hơn bởi vì họ biết rằng các đồng nghiệp của họ sẽ nhìn thấy nó và kiểm tra nó. Đó là một điều rất lành mạnh và tự nhiên, dẫn đến tăng chất lượng sản phẩm cuối cùng.
Phần kết
Nhiều người nói rằng review code là điều tốt nhất mà nhà phát triển có thể làm để cải thiện code của họ. Chúng tôi tin rằng nó được áp dụng theo cách tương tự cho phía doanh nghiệp của các ứng dụng. Ảnh hưởng của nó đến chất lượng và khả năng duy trì lâu dài là vô giá. Nó giúp giữ chi phí thấp và cho phép nhóm chia sẻ kiến thức liên tục.
Hy vọng rằng, bài viết này đã cho bạn thấy lý do tại sao mọi dự án phần mềm đều phải nên review code.
Cảm ơn các bạn đã đọc và tham khảo bài này, nếu bạn thấy hay và hữu ích, xin vui lòng like fanpage cafedev để ủng hộ, Cảm ơn các bạn nhiều.
