CHƯƠNG 2 ĐẢM BẢO CHẤT LƯỢNG MÃ NGUỒN
2.4. Giới thiệu công cụ review code
2.4.1 Review Code thủ công sử dụng pull request
Pull Request(viết tắt là PR) sẽ để cho bạn nói với người khác về các thay đổi bạn đã đẩy lên kho Github (Github repository). Một khi pull request được gửi, người nào quan tâm có thể review (xem xét) lại các thay đổi, hoặc thảo luận các sửa đổi tiềm năng, và có thể theo đó đẩy tiếp các commit của họ nếu cần thiết.
Pull Request thường được sử dụng trong các team hoặc tổ chức mà các thành viên làm việc hợp tác sử dụng mô hình kho chia sẻ (như github), ở đó mỗi người chia sẻ các kho riêng lẻ của họ và các nhánh chủ đề (topic branch) để phát triển các tính năng và để tách biệt các thay đổi khỏi nhánh chính (master, kho chính thức mà code ổn định nhất). Nhiều dự án trên Github sử dụng pull request để quản lý các thay đổi từ các người đóng góp, việc áp dụng pull request giúp cho họ thông báo cho người bảo trì dự án về các thay đổi khi một người tạo ra và khởi đầu giai đoạn code review và các thảo luận chung về các thay đổi trước khi chúng được merge (trộn) vào nhánh chính.
Các điều kiện để tạo pull request:
Những điều dưới đây rất cần thiết cho việc giảm thiểu xung đột:
Đảm bảo rằng code build thành công.
Đọc và chú thích code.Build và chạy test.
Tất cả code trong phần codebase đều cần được test.
Lick ticket/issue vào pull request.
Không chuyển cho người review khi chưa đảm bảo được các điều kiện trên.
Thông thường, mã nguồn chính của sản phẩm thường được để trong nhánh (thuật ngữ là branch) có tên gọi là master. Khi phát triển một tính năng mới, nhưng lại tránh thay đổi gì mã nguồn đang có của nhánh master, lập trình viên sẽ tạo ra các nhánh con, ví dụ: nhánh feature_A, nhánh feature_B … Sau đó sẽ thêm mã nguồn mới vào các nhánh con này, trong khi họ làm tính năng mới thì nhánh master sẽ không bị thay đổi gì cả, vì thế mà trong lúc họ làm phần mềm vẫn chạy bình thường. Minh họa bằng sơ đồ sau:
Khi lập trình viên viết code xong cho những tính năng mình phụ trách, họ sẽ tạo những Pull Request (minh họa ở trên là PR-1 và PR-2) với mục đích kĩ thuật là để gộp mã nguồn mới vào mã nguồn cũ (thuật ngữ chuyên môn gọi là merge source). Bên cạnh đó,
gộp chung mã nguồn mới (của tính năng mới) vào phần mềm đang chạy, để bổ sung tính năng mới cho sản phẩm.
Những tác dụng của Pull Requests
Nhờ người khác kiểm tra lại mã nguồn (review)
Khi bạn tạo ra một PR để yêu cầu có một sự merge source, bạn mới thực hiện được một nửa quá trình, PR còn cần phải được “xác nhận” lại lần cuối trước khi lệnh merge được chính thức kích hoạt bởi phần mềm quản lí mã nguồn git. Trong github, việc “xác nhận”
này được thực hiện bằng việc nhấn vào nút MERGE trên PR.
Ở bước “xác nhận” này, bạn có thể nhờ một người khác trong nhóm của bạn -người có thể có nhiều kinh nghiệm – kiểm tra lại PR đó xem coi những đoạn mã lệnh bạn viết trong tính năng mới có ổn hay không, có thực thi đúng chức năng và nhiệm vụ không, có đạt hiệu suất cao hay không, có bảo mật hay không, … Khi những tiêu chí về chất lượng mã nguồn được kiểm tra và đảm bảo, tính năng mới (hay mã nguồn mới) mới chính thức được merge vào sản phẩm. Công việc kiểm tra này được gọi bằng thuật ngữ là review.
PR là một thứ thể hiện cho kiến thức và kĩ năng của bạn, việc nhờ người khác nhận xét và kiểm tra, bạn sẽ hạn chế được lỗi (nếu có) phát sinh trong quá trình viết code, cũng như sẽ rút ra được nhiều bài học mới và vấn đề mới cần cải thiện.
Lưu lại lịch sử phát triển của sản phẩm
Sau khi PRs được merge vào nhánh chính của sản phẩm, thông tin về nó sẽ không bị mất đi. Phần mềm quản lí mã nguồn sẽ tiếp tục lưu lại thông tin về những PRs trong dữ liệu của nó, những thông tin thay đổi về mã nguồn chi tiết tới từng dòng đều được lưu lại để thực hiện truy vấn lại sau này. Nói một cách khác, quá trình phát triển của sản phẩm được ghi lại một cách rõ ràng và chi tiết thông qua những PRs.
Tất cả mọi người lớn đều đã từng là những đứa trẻ, tương tự như thế, tất cả những phầm mềm dù lớn tới và phức tạp tới đâu cũng từng được tạo nên từ những thứ đơn giản ban đầu. Mỗi PR giống như một bài học bạn học được trong quá trình lớn lên và trưởng thành vậy. Bạn có thể học được rất nhiều bài học về phát triển phần mềm từ những PRs trong quá khứ.
Là cơ hội giúp bạn học hỏi từ người khác
Bạn vẫn luôn được những lập trình viên có kinh nghiệm khuyên rằng: cách tốt nhất để phát triển kĩ năng của mình là phải làm thật nhiều. Sự thật là vậy, bạn càng viết code nhiều, luyện tập thiết kế cách tính năng khác nhau thì sẽ càng mau giỏi. Nhưng vấn đề là, khi bạn còn chưa có nhiều kinh nghiệm, leader hoặc cấp trên của bạn nào dám đưa cho bạn phụ trách những tính năng lớn, những tính năng phức tạp.
Khi bạn không được trao vai trò chính trong việc phát triển và trở thành người tạo ra những PR, bạn vẫn có thể học hỏi từ nó, bằng cách đóng góp những commits nhỏ trong PR, trở thành người kiểm tra Pull Request (gọi là reviewer), hay đơn thuần chỉ là người đọc qua những sự thay đổi của mã nguồn từ những PRs.
Khi làm việc với những nhóm lớn, sẽ có rất nhiều PRs được tạo ra trong quá trình phát triển sản phẩm, những PRs chứa đựng giải pháp cho những điều bạn có thể chưa biết, tham khảo những PRs này cũng sẽ giúp bạn học thêm được rất nhiều điều mới mẻ và có ích cho sự phát triển của bạn.
2.4.2 Review Code tự động sử dụng công cụ Codacy
Codacy là một công cụ phân tích / chất lượng mã tự động giúp các nhà phát triển vận chuyển phần mềm tốt hơn, nhanh hơn. Với Codacy, bạn có được phân tích tĩnh, độ phức tạp chu kỳ, trùng lặp và thay đổi phạm vi kiểm tra đơn vị mã trong mỗi yêu cầu cam kết và kéo.
Bạn có thể sử dụng Codacy để thực thi tiêu chuẩn chất lượng mã của mình, tiết kiệm thời gian trong đánh giá mã, thực thi các thực tiễn tốt nhất về bảo mật và các nhà phát triển trên tàu nhanh hơn. Tích hợp với kho GitHub của bạn để có được phân tích chất lượng của mọi yêu cầu kéo bên trong GitHub.
Đặc điểm của Codacy:
Được tích hợp trong quy trình công việc : Codacy thích ứng với quy trình code review , đẩy kết quả dưới dạng nhận xét trong requests và commits vào quy trình công việc trong GitHub.
Theo dõi sự phát triển chất lượng : Có một cái nhìn về chất lượng mã của dự án và theo dõi sự phát triển chất lượng của nó theo thời gian, dễ dàng sửa đổi các sai sót kỹ thuật.
Đa ngôn ngữ : Với hơn 20 ngôn ngữ được hỗ trợ Codacy đáp ứng tất cả các nhu cầu dự án.
Bao phủ mã : Với phạm vi bao phủ mã được tích hợp với CI, Codacy sẽ giúp bạn quản lý các nhu cầu chất lượng dự án và giúp vượt qua từ 10% đến 80%.
Cài đặt chất lượng : Có thể xác định cài đặt chất lượng cho các requests và commits đóng vai trò là ngưỡng cho công việc.
Kiểm tra bảo mật : Bảng điều khiển bảo mật của chúng tôi nhanh chóng hiển thị các cảnh báo từ việc chạy hàng trăm kiểm tra phân tích bảo mật trong dự án.
Các mục Codacy trả về:
Chi tiết một số mục:
Security: vấn đề bảo mật, lỗ hổng tiềm ẩn, phụ thuộc không an toàn.
Code Style: liên quan đến kiểu mã, độ dài dòng, tab so với khoảng trắng.
Error Prone : các thực tiễn hoặc mô hình xấu khiến mã bị lỗi hoặc dễ bị lỗi .
Unused Code : mã không cần thiết không được sử dụng .
Compatibility : xác định mã có vấn đề với các hệ thống cũ hoặc hỗ trợ đa nền tảng . Performance : mã viết không hiệu quả .
Mức độ
Info : Loại vấn đề sẽ xuất hiện như là màu xanh
Ví dụ: các vấn đề về kiểu mã được hiển thị theo cách này.
Warning : Loại vấn đề này sẽ xuất hiện dưới dạng màu vàng . Bạn nên cẩn thận với những cái này vì chúng dựa trên các tiêu chuẩn và quy ước mã.
Error : Loại vấn đề nguy hiểm hơn sẽ hiển thị màu đỏ . Cần dành thời gian để khắc phục những điều này, mặc dù mã có thể chạy, những vấn đề này cho thấy mã rất dễ gặp sự cố. Những vấn đề này dễ bị lỗi hoặc có thể có vấn đề nghiêm trọng về bảo mật và khả năng tương thích.
Bỏ qua một vấn đề
Đối với một vấn đề bạn không đồng ý hoặc báo lỗi sai, bạn có thể bỏ qua trường hợp đó hoặc vô hiệu hóa mẫu trên toàn bộ dự án. Để làm như vậy, nhấp vào và chọn tùy chọn mong muốn.
Khôi phục vấn đề đã bỏ qua
Để phục hồi lại các vấn đề bỏ qua, click vào Current Issues và chọn Ignored Issues từ trình đơn thả xuống .
Sau đó chọn vấn đề cần khôi phục và chọn Unignore
Bỏ qua tập tin
Bạn có thể bỏ qua các tập tin cherry-pick để phân tích thêm. Để bỏ qua một tập tin, mở rộng vấn đề, nhấp vào , chọn Ignore file từ menu và xác nhận. WARNING: This file is now ignored across the entire project and for all patterns.
Quản lý tập tin bị bỏ qua
Các tập tin bị bỏ qua được quản lý thông qua Settings>Ignore Files.
Cách Codacy chỉ ra vấn đề
Codacy dùng các mẫu code để chỉ ra các vấn đề có trong chương trình . Một số công cụ Codacy tích hợp sẵn:
CSSLint là một công cụ giúp chỉ ra các vấn đề với mã CSS. Nó thực hiện kiểm tra cú pháp cơ bản cũng như áp dụng một bộ quy tắc cho mã tìm kiếm các mẫu hoặc dấu hiệu không hiệu quả. Các quy tắc đều có thể cắm được, vì vậy bạn có thể dễ dàng tự viết hoặc bỏ qua những quy tắc mà bạn không muốn.
ESLint là một công cụ để xác định và báo cáo về các mẫu được tìm thấy trong mã ECMAScript / JavaScript. Theo nhiều cách, nó tương tự như JSLint và JSHint với một vài ngoại lệ.
PHP_CodeSniffer là một bộ gồm hai tập lệnh PHP; tập lệnh phpc chính mã hóa các tệp PHP, JavaScript và CSS để phát hiện các vi phạm của một tiêu chuẩn mã hóa đã xác định và một tập lệnh phpcbf thứ hai để tự động sửa các vi phạm tiêu chuẩn mã hóa
PHPMD là một dự án phụ thuộc của PHP Depend và nhằm mục đích trở thành một PHP tương đương với công cụ Java nổi tiếng PMD. PHPMD có thể được xem như là một ứng dụng lối vào thân thiện với người dùng cho luồng số liệu thô được đo bởi Depend PHP PMD là một bộ phân tích mã nguồn. Nó tìm thấy các lỗi lập trình phổ biến như các biến không sử dụng, các khối bắt trống, tạo đối tượng không cần thiết, v.v. Nó hỗ trợ Java, JavaScript, Salesforce.com Apex, PLSQL, Apache Velocity, XML, XSL
Remark-lint là một kẻ nói dối phong cách mã markdown. Kẻ nói dối khác? Đúng. Đảm bảo việc đánh dấu mà bạn (và những người đóng góp) viết có chất lượng tuyệt vời sẽ cung cấp kết xuất tốt hơn trong tất cả các trình phân tích cú pháp đánh dấu khác nhau và đảm bảo rằng việc tái cấu trúc ít hơn là cần thiết sau đó. chú thích được xây dựng trên nhận xét, một bộ xử lý đánh dấu mạnh mẽ được cung cấp bởi các plugin
SQLint là một trình giả lập dòng lệnh đơn giản để đọc các tệp SQL của bạn và báo cáo bất kỳ lỗi cú pháp hoặc cảnh báo nào mà nó tìm thấy
Ngoài ra cũng có thể tự thêm các mẫu code hoặc tùy chỉnh các mẫu code trong các công cụ
Quy trình review code với Codacy
B1: truy cập https://www.codacy.com/ và thực hiện đăng nhập tài khoản B2: chọn project cần review code
B3: thống kê các vấn đề trong dự án
B4: sửa lỗi các vấn đề cấp độ warnning – error