Mục Lục Bảng Phân Công Công Việc 2 CHƯƠNG 1 TỔNG QUAN VỀ CODE REVIEW 3 1 1 Code Review là gì? 3 1 1 1 Giới thiệu 3 1 1 2 Tại sao cần review ? 6 1 2 GitGitHub là gì? 7 1 3 Lý do chọn đề tài 8 1 4 Phạm.
TỔNG QUAN VỀ CODE REVIEW
Code Review là gì?
Code Review là bước quan trọng trong quy trình phát triển phần mềm, nơi các lập trình viên đánh giá và thảo luận về mã nguồn của đồng nghiệp Quá trình này không chỉ giúp cải thiện chất lượng code mà còn tạo cơ hội để chia sẻ ý kiến và góp ý hữu ích, từ đó nâng cao hiệu suất làm việc của cả nhóm.
Tầm quan trọng của code review:
Giảm số lượng bug trong code Đảm bảo tất cả các yêu cầu đã được thực hiện
Một cách hiệu quả để học hỏi lẫn nhau và làm quen với code base.
Giúp duy trì một style code chung cho toàn đội
Gắn kết đội ,khuyến khích các developer nói chuyện với nhau để tìm ra cách giải quyết tốt nhất
Để thực hiện code review hiệu quả, cần chia sẻ kiến thức với người khác và đưa ra những góp ý mang tính xây dựng Tránh lợi dụng code review để công kích cá nhân, đồng thời luôn sẵn sàng tiếp thu những góp ý hữu ích nhằm hoàn thiện bản thân Cuối cùng, hãy biết trân trọng những đóng góp của các thành viên trong nhóm.
Các lỗi thường gặp trong code review
Trong quy trình code review, kiểm tra lỗi cú pháp là một bước quan trọng Những vấn đề như thụ thụ không đúng, căn lề, thừa dấu cách, thiếu dấu chấm phẩy và thiếu đóng ngoặc, mặc dù có vẻ nhỏ nhặt, nhưng lại đóng góp đáng kể vào chất lượng tổng thể của mã nguồn.
Có vài đoạn code bị comment lại nếu không dung nữa cần được bỏ đi để gọn gàng hơn.
Kiểm tra ngữ pháp và chính tả trong mã nguồn là rất quan trọng Đảm bảo rằng việc sử dụng tiếng Anh trong code là chính xác và phù hợp Cần xác định xem tên file, tên biến và tên class đã có ý nghĩa rõ ràng hay chưa.
Gợi ý lỗi code tiềm tàng là quá trình mà chương trình phân tích mã nguồn để phát hiện các lỗi tiềm ẩn Nếu bạn sử dụng trình soạn thảo có tích hợp công cụ phân tích mã, nó sẽ tự động kiểm tra và thông báo các lỗi do lập trình viên gây ra Có nhiều thư viện hỗ trợ cho các ngôn ngữ lập trình khác nhau, giúp phát hiện lỗi tiềm tàng trong mã của bạn, chẳng hạn như ESLint cho Javascript và Rubocop cho Ruby.
Nguyên tắc DRY (Don’t Repeat Yourself) giúp loại bỏ sự lặp lại trong code, khuyến khích việc sử dụng các phương thức đã có một cách hiệu quả Nếu mã tương tự xuất hiện trong nhiều file, hãy biến nó thành mã dùng chung Việc này không chỉ giúp code trở nên gọn gàng hơn mà còn dễ dàng bảo trì trong tương lai Tất cả code mới nên được viết với tư duy có thể tái sử dụng, từ đó nâng cao tính hiệu quả và giảm thiểu lỗi trùng lặp.
Chất lượng kỹ thuật: Điểm này bao gồm một loại các yếu tốt Nhiều yếu tố đóng góp vào chất lượng kỹ thuật của Pull Request.
Cơ chế xử lý lỗi là một phần quan trọng trong lập trình, vì mã nguồn thường có thể chứa sai sót Khi một lỗi xảy ra, việc xử lý lỗi giúp chuyển hướng chương trình thay vì dừng lại hoàn toàn Ví dụ, khi API gặp sự cố, nó sẽ trả về thông điệp và mã trạng thái để thông báo cho người dùng về tình trạng lỗi.
TDD (Test Driven Development) là một phần quan trọng trong lập trình mà mọi developer đều cần phải nắm vững Việc đảm bảo rằng mã nguồn có đầy đủ các đoạn code test là cần thiết để phát hiện và giảm thiểu lỗi, kiểm tra hành vi của mã khi có sự thay đổi, và tạo tài liệu cho các tính năng hiện có TDD cũng giúp các developer hợp tác và hiểu rõ hơn về mã nguồn, vì vậy hãy luôn kiểm tra xem tất cả các bài test có được thông qua hay không.
Review được chia làm 2 loại chính:
Review thủ công là quá trình mà các developer hoặc reviewer được phân công sẽ xem xét mã nguồn trong các pull request do thành viên khác gửi lên Pull request chỉ được chấp nhận và merge khi đáp ứng đủ các tiêu chí và tiêu chuẩn đã đặt ra, chủ yếu liên quan đến thuật toán và chuẩn mực mã nguồn Nếu không đạt yêu cầu, pull request sẽ bị bỏ qua và người gửi cần phải chỉnh sửa mã trước khi gửi lại, quá trình này sẽ lặp lại cho đến khi pull request đạt được tiêu chuẩn.
Review tự động là phương pháp sử dụng công cụ tự động tích hợp để kiểm tra mã nguồn, giúp phát hiện các lỗi cú pháp và vấn đề định dạng Quá trình này thường diễn ra trước khi thực hiện review code thủ công, nhằm kiểm tra và phát hiện các lỗi mà review tự động có thể bỏ sót.
1.1.2 Tại sao cần review ? Đả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ả đội cùng nhau thực hiện việc review mã nguồn, họ sẽ phát hiện ra những điểm có thể viết ngắn gọn hơn nhưng vẫn hiệu quả, áp dụng các design pattern phù hợp, và nhận ra rằng một số chức năng hay module đang bị lặp lại quá nhiều Những vấn đề này có thể xảy ra với bất kỳ ai, kể cả những lập trình viên dày dạn kinh nghiệm, nhưng sẽ dễ dàng được phát hiện dưới sự giám sát của toàn bộ đội ngũ phát triển.
Phát hiện lỗi sớm là rất quan trọng trong quá trình phát triển phần mềm Dù bạn có tự tin rằng chức năng của mình hoạt động tốt và đã thực hiện nhiều lần kiểm tra, nhưng có thể bạn vẫn bỏ sót một số testcase cần thiết Khi cả đội cùng xem xét đoạn code, có khả năng một thành viên sẽ nhanh chóng phát hiện lỗi mà bạn không nhận ra, mà không cần phải thực hiện thêm bất kỳ bài kiểm tra nào.
Nâng cao kỹ thuật cho lập trình viên Đồng bộ hóa công việc cho nhóm phát triển
Góp ý xây dựng chương trình Đánh giá chất lượng lập trình viên
Thể hiện năng lực bản thân
Git/GitHub là gì?
Git là tên gọi của một hệ thống quản lý phiên bản phân tán (Distributed Version Control
Hệ thống quản lý phiên bản phân tán (DVCS) là một trong những công cụ phổ biến nhất hiện nay, giúp quản lý mã nguồn một cách hiệu quả và dễ dàng thông qua các lệnh linh hoạt.
Hệ thống Quản lý Phiên bản Phân tán (DVCS) cho phép mỗi máy tính lưu trữ nhiều phiên bản khác nhau của mã nguồn được nhân bản từ kho chứa mã nguồn Mỗi thay đổi vào mã nguồn trên máy tính có thể được ủy thác và đưa lên máy chủ chứa chính Các máy tính khác, nếu có quyền truy cập, có thể clone mã nguồn từ kho chứa hoặc nhận các thay đổi mới nhất từ máy tính khác.
Git là một trong những hệ thống quản lý phiên bản phân tán (DVCS) phổ biến nhất hiện nay, được nhiều tổ chức và dự án lớn như Google, Facebook, và Microsoft sử dụng Kỹ năng sử dụng Git trở thành yêu cầu thiết yếu cho lập trình viên khi tham gia vào các dự án có nhiều thành viên Git ngày càng trở nên thông dụng và đang dần thay thế các hệ thống quản lý phiên bản truyền thống như SVN.
Có nhiều hệ thống dự trên nền tảng Git như github, gitlab, ra đời nhằm giải quyết vấn đề lưu trữ và quản lý mã nguồn trực tuyến.
GitHub là một dịch vụ lưu trữ kho mã nguồn công khai, cho phép người dùng tạo tài khoản và xây dựng kho chứa riêng của mình để phục vụ cho công việc phát triển phần mềm.
Github cho phép tạo remote repository mà không cần mua sever.
Cung cấp nhiều tính năng giúp quản lỹ dự án tốt hơn
Lý do chọn đề tài
Trong lĩnh vực lập trình, code review đóng vai trò quan trọng trong việc nâng cao chất lượng mã nguồn Là sinh viên công nghệ thông tin, việc nắm vững kỹ năng review code là cần thiết để đảm bảo mã nguồn đạt tiêu chuẩn Tìm hiểu về quy trình code review không chỉ giúp đánh giá chất lượng mã nguồn mà còn cải thiện hiệu quả làm việc nhóm.
Phạm vi đề tài
Code review đóng vai trò quan trọng trong quy trình đảm bảo chất lượng mã nguồn, giúp phát hiện lỗi và cải thiện hiệu suất Việc hiểu rõ về Code review và các phương pháp đánh giá sẽ nâng cao khả năng phát triển phần mềm hiệu quả hơn.
Demo triển khai quá trình review code thủ công và tự động.
ĐẢM BẢO CHẤT LƯỢNG MÃ NGUỒN
Thanh tra mã nguồn
Thanh tra mã nguồn là một phương pháp kiểm tra phần mềm nhằm phát hiện lỗi tiềm ẩn trong mã nguồn sau khi đã loại bỏ lỗi cú pháp và trước khi biên dịch thành chương trình thực thi Các công ty phần mềm thường áp dụng quy trình này với đội ngũ thanh tra từ 4 đến 6 người, và thời gian họp nhóm không quá 2 giờ Một báo cáo lỗi được coi là tốt nếu trên 70% lỗi phải được tác giả sửa chữa Trung bình, mỗi thanh tra viên có thể đọc khoảng 120 dòng mã nguồn mỗi giờ, cho phép nhóm duyệt qua tối đa 1200 dòng mã trong mỗi buổi họp.
Lỗi trong mã nguồn rất đa dạng và việc phát hiện chúng phụ thuộc vào kỹ năng phân tích của các thanh tra viên Các lỗi cần thanh tra được phân chia thành nhiều nhóm dựa trên đặc điểm của đối tượng lập trình, bao gồm các nhóm lỗi cơ bản.
Lỗi cấu trúc: Các lỗi liên quan đến cấu trúc code, các thành phần có đúng như convention, có dúng như design
Code có thực thực hiên hoàn toàn và chính xác theo thiết kế? • Code có tuân theo chuẩn đã đặt ra hay không?
Kiểm tra xem mã nguồn có chứa các thủ tục không cần thiết hoặc các đoạn mã không thể truy cập hay không Đồng thời, xác định xem tất cả các đoạn mã lặp có được tổ chức trong cùng một thủ tục hay chưa.
Code có rõ ràng và đầy đủ comment, cùng một cấu trúc đễ dàng để maintain
Tất cả các comment có phù hợp với code?
Lỗi dữ liệu: Các lỗi liên quan đến xử lý dữ liệu và kiểu dữ liệu.
Tính toán trên các biến không phải kiểu số?
Tính toán kiểu dữ liệu hỗn hợp?
Tính toán trên các biến có độ dài khác nhau?
Vùng nhớ có kích thước nhỏ hơn giá trị gán?
Kết quả tức thời tràn bộ nhớ?
Trình biên dịch ngầm hiểu các biểu thức logic không?
Lỗi cấu trúc điều kiện:
Rẽ nhiều nhánh có vượt qua?
Mỗi vòng lặp dừng hay không?
Chương trình dừng hay không?
Vòng lặp có bị bỏ qua vì điều kiện đầu vào?
Vòng lặp có thể bỏ qua có chính xác không?
Các thuộc tính tệp tin chính xác không?
Các câu lệnh mở tệp tin chính xác không?
Các chỉ định định dạng phù hợp với câu lệnh nhập, xuất? Các điều kiện kết thúc tệp tin được xử lý?
Kiểm tra tính hợp lệ cho các đầu vào?
Lỗi giao tiếp giữa các hàm, thủ tục:
Số các đối số được truyền tới mô-đun gọi bằng số tham số?
Hệ thống đơn vị của các đối số được truyền tới các mô-đun gọi bằng hệ thống đơn vị của các tham số?
Thuộc tính, thứ tự và số các tham số trong các hàm xây dựng sẵn là chính xác?
Tham chiếu tới các tham số không phù hợp với điểm vào hiện tại?
Tham chiếu tới các tham số không phù hợp với điểm vào hiện tại?
Các hằng số truyền như các đối số?
Lỗi sử dụng bộ nhớ:
Các thuộc tính lưu trữ chính xác?
Các biến đã được khai báo?
Sự khởi tạo phù hợp với các lớp lưu trữ?
Các biến có tên giống nhau?
Code smells là thuật ngữ quan trọng trong lập trình, đề cập đến những vấn đề tiềm ẩn trong mã lệnh Việc nhận diện và hạn chế code smells giúp cải thiện chất lượng mã, dễ dàng bảo trì và phát triển phần mềm Bài viết này sẽ giúp những người mới bắt đầu hiểu rõ về code smells và tầm quan trọng của việc quản lý chúng trong lập trình.
Theo Wikipedia, code smells là những triệu chứng bất ổn trong mã nguồn của một chương trình, có thể dẫn đến các vấn đề lớn hơn Chúng không phải là lỗi lập trình, vì không làm sai chức năng của ứng dụng, mà là dấu hiệu của sự yếu kém trong thiết kế Code smells có thể làm chậm quá trình phát triển ứng dụng và tăng nguy cơ xuất hiện bugs trong tương lai.
2.2.2 Các loại code smell thường gặp
Code smells bên trong class
Khi sử dụng comment trong mã lệnh, bạn nên chỉ thực hiện khi thật sự cần thiết và đảm bảo rằng comment giải thích được lý do chứ không chỉ là nội dung Cố gắng cải tiến mã lệnh để nó tự giải thích mà không cần đến comment Ngoài ra, comment cần phải dễ hiểu, vì chúng phục vụ cho con người chứ không phải cho máy móc.
Phương thức có độ dài lớn thường khó đọc và khó xử lý lỗi hơn so với phương thức ngắn Để cải thiện khả năng hiểu và quản lý mã, hãy chia tách những phương thức dài thành những phương thức nhỏ hơn khi có thể.
Danh sách tham số dài có thể làm cho phương thức trở nên phức tạp hơn Để giảm độ phức tạp, hãy hạn chế số lượng tham số trong một phương thức Nếu cần thiết, bạn có thể sử dụng một đối tượng để chứa các tham số này, giúp quản lý và tổ chức mã nguồn tốt hơn.
Độ phức tạp của các lệnh điều kiện có thể gia tăng theo thời gian, vì vậy cần cẩn trọng với các khối lệnh điều kiện lớn Để giảm thiểu vấn đề này, bạn có thể áp dụng các phương pháp lập trình hướng đối tượng như mẫu decorator, strategy hoặc state để thay thế.
Sự bùng nổ tổ hợp xảy ra khi bạn có nhiều mã lệnh thực hiện các công việc tương tự nhau, chỉ khác nhau một chút về dữ liệu hoặc hành vi Mặc dù việc cải thiện tình huống này không dễ dàng, bạn có thể cân nhắc sử dụng generics hoặc interpreter để tối ưu hóa mã lệnh.
Lớp có lượng mã lệnh lớn thường gây khó khăn trong việc đọc và hiểu Nếu lớp bạn xây dựng đảm trách quá nhiều vai trò, hãy cân nhắc tái cấu trúc nó thành nhiều lớp nhỏ hơn để cải thiện tính rõ ràng và khả năng bảo trì.
Khi đặt tên cho phương thức, nếu tên phương thức chứa kiểu dữ liệu trả về, bạn nên xem xét việc sửa đổi Điều này là cần thiết vì khi bạn thay đổi kiểu dữ liệu trả về, bạn sẽ phải thay đổi tên phương thức tương ứng.
Tên phương thức không rõ ràng hoặc khó hiểu có thể gây nhầm lẫn về mục đích sử dụng của nó Để cải thiện tính khả dụng và dễ hiểu, bạn nên xem xét việc đổi tên những phương thức như vậy.
Để đảm bảo tính nhất quán trong lập trình, bạn nên thống nhất cách đặt tên cho các phương thức Ví dụ, nếu bạn sử dụng phương thức Open(), thì phương thức tương ứng nên là Close().
Mã lệnh không sử dụng, hay còn gọi là dead code, nên được xóa bỏ để tối ưu hóa mã nguồn Nếu bạn lo ngại về việc cần sử dụng lại những đoạn mã này trong tương lai, hãy yên tâm vì các công cụ quản lý phiên bản sẽ lưu trữ các phiên bản cũ cho bạn.
Các tiêu chí/tiêu chuẩn Review Code
Mỗi ngôn ngữ đều có các chuẩn mã nguồn riêng, ở đây ta đề cập đến PHP Standards Recommendations (PSR), một chuẩn mã nguồn cuả ngôn ngữ PHP.
Chuẩn PSR-0, PSR-4 : Chuẩn về Autoloading
Những mô tả dưới đây là bắt buộc phải tuân theo
Một namespace và class đầy đủ điều kiện (fully qualified) phải có cấu trúc như sau \
\(\)*
Mỗi namespace phải có một top-level namespace (“Vendor name”), tạm gọi là namespace gốc
Mỗi namespace có thể có nhiều sub-namespace (namespace con)
Từ PHP 5.3 khi khai báo class bạn BUỘC PHẢI khai báo namespace
Chuẩn PSR-1 là những quy tắc cơ bản trong việc viết mã, với những nguyên tắc đơn giản, dễ hiểu và dễ nhớ Sau khi tìm hiểu, bạn sẽ nhận ra rằng những quy tắc này thực sự rất quen thuộc, vì chúng ta đã áp dụng chúng trong quá trình lập trình mà không biết chúng có tên gọi chính thức.
Code phải được viết trong cặp thẻ và nên sử dụng cặp thẻ ngắn thay cho echo
Code chỉ được sử dụng UTF-8 không có BOM (Byte Order Mark là các chuỗi EF,BB,BF ở đầu file cho phép phần mềm biết đây là 1 file UTF-8)
Namespace phải tuân theo chuẩn PSR “autoloading” (PSR-0, PSR-4)
Tên class phải viết theo quy tắc PascalCase hay còn được biết với cái tên khác là
Các hẳng số phải viết hoa tất cả và phân cách nhau bằng dấu gạch chân
Tên phương thức viết theo quy tắc camelCase
Mỗi file PHP nên đảm nhiệm một nhiệm vụ duy nhất để tránh hiện tượng chồng chéo, hay còn gọi là side effect Ví dụ dưới đây cho thấy việc thực hiện nhiều tác vụ trong một file là không đúng cách.
Chuẩn PSR-2: Chuẩn viết code
Code phải tuân thủ PSR-1 & PSR-0
Sử dụng 4 khoảng trắng để thụt dòng trong văn bản, tuyệt đối không sử dụng phím tab Bạn có thể cấu hình trong PHPStorm để khi nhấn tab, nó tự động thụt vào 4 khoảng trắng.
Các kí tự trên 1 dòng không vượt quá 120 kí tự, tốt nhất nên nhỏ hơn hoặc bằng 80 kí tự, ko nên có kí tự trắng ở cuối dòng
Phải có 1 dòng trắng sau khi khai báo namespace và phải có 1 dòng trắng sau các khai báo use
Thẻ đóng và mở của 1 hàm {} phải nằm riêng biệt trên một dòng
Trước thẻ mở & đóng hàm {} thì không được có 1 dòng trắng
Khi khai báo chuỗi không chứa biến trong lập trình, cần sử dụng dấu nháy đơn ‘ Nếu chuỗi cần chứa kí tự ‘, bạn có thể sử dụng dấu nháy kép để bao bọc bên ngoài.
Sử dụng dấu chấm (.) để nối các chuỗi, lưu ý rằng cần có khoảng trắng trước và sau dấu chấm Nếu chuỗi quá dài, hãy tách thành nhiều dòng và đảm bảo rằng dấu chấm được đặt ở đầu dòng ngang với dấu "=".
Các tham số truyền vào hàm cần có một dấu cách trước dấu phẩy và có thể được tách thành nhiều dòng nhưng phải thụt lề một đơn vị Đối với khối lệnh switch case, các case phải lùi 4 khoảng trắng so với switch, và các lệnh trong case cũng phải thụt lề 4 khoảng trắng so với case Ngoài ra, cần phải có từ khóa break hoặc return; nếu không có, cần phải thêm chú thích //no break.
Nếu phải sử dụng abstract và final hay static để khai báo hàm thì bạn phải khai báo theo thứ tự như sau
Phải có 1 khoảng trắng trước và sau phép toán, khi ép kiểu thì phải có 1 khoảng trắng ngăn cách giữa kiểu dữ liệu và biến được ép kiểu.
2.3.2 Các nguyên tắc lập trình Đây là các nguyên tắc lập trình mà đã được các lập trình viên đi trước rút ra từ quá trình trải nghiệm của bản thân và được hầu như tất cả các lập trình viên hiện tại làm theo để có thể có được những mã nguồn “đẹp”.
Nguyên tắc code sao cho đơn giản (simple)
Khi code lúc nào cũng nghĩ đến việc làm sao cho nó đơn giản nhất có thể Code đơn giản sẽ có các lợi ích:
Các thành viên trong team có thể tuân theo dễ dàng.
Sau này người mới cũng dễ dàng tiếp nhận
Bản thân chúng ta sau này đọc lại để improve, maintain cũng dễ dàng. Đặc biệt, khi chúng đơn giản thì hỏng hóc sẽ dễ dàng sửa chữa.
Để đơn giản hóa quá trình lập trình, mặc dù tác giả không có câu trả lời cụ thể, nhưng chúng ta có thể tránh những yếu tố dẫn đến mã nguồn phức tạp.
Chia nhỏ hàm lớn thành nhiều hàm nhỏ hơn để cải thiện khả năng đọc hiểu Tránh viết các thuật toán phức tạp hay giải thuật tối ưu hóa, vì điều này có thể khiến mã nguồn trở nên khó hiểu và khó bảo trì.
Nguyên tắc code sao cho gọn gàng, sạch sẽ (clear & clean)
Để có thể viết code gọn gàng và sạch sẽ, bạn cần chú ý đến việc tổ chức mã nguồn một cách hợp lý, sử dụng quy tắc đặt tên biến rõ ràng và nhất quán, cũng như thường xuyên kiểm tra và làm sạch mã của mình Việc này không chỉ giúp bạn dễ dàng quản lý và bảo trì code mà còn tạo điều kiện thuận lợi cho những người khác khi đọc và hiểu mã của bạn Một mã nguồn sạch sẽ sẽ giúp giảm thiểu lỗi và tăng hiệu suất làm việc.
Hãy tạo cho mình một bộ nguyên tắc (Coding Convention)
Hãy bắt đầu bằng việc đặt tên biến gọn gàng, dễ hiểu
Hãy thiết kế các function có tên dễ đọc, dễ hiểu
Hãy làm cho các function có input và output rõ ràng
Bên trong các function hạn chế if/else/for một cách quá so deep
Hãy kiên nhẫn theo đuổi các nguyên tắc đã đề ra, vì việc làm mọi thứ trở nên gọn gàng và sạch sẽ không hề đơn giản Bạn cần trải qua nhiều lần cải thiện, rút kinh nghiệm và tự kiểm điểm để thiết lập những kỹ năng cần thiết nhằm duy trì thói quen này.
Nguyên tắc việc code sao cho có thể dễ dàng tái sử dụng (reusable)
Nếu không tái sử dụng các đoạn mã lặp lại, việc sửa chữa hoặc thay đổi có thể dễ dàng dẫn đến lỗi do quên các phần khác nhau, và điều này làm cho việc đọc hiểu mã nguồn trở nên khó khăn hơn.
Việc viết mã để tái sử dụng là một thách thức lớn, vì thường thì lập trình viên chỉ tập trung vào việc làm cho nó hoạt động mà không nghĩ đến việc phát triển mã cho người khác sử dụng trong tương lai Suy nghĩ về sự bền vững và khả năng tái sử dụng của mã là điều thường bị xem nhẹ, và điều này có thể dẫn đến những khó khăn trong việc bảo trì và nâng cấp sau này.
Viết code tái sử dụng không chỉ giúp bạn cải thiện kỹ năng lập trình mà còn phát triển khả năng suy nghĩ thấu đáo về vấn đề Khi bạn tập trung vào việc này, bạn đang cô lập và phân tích các vấn đề của mình, từ đó giúp bạn nhìn nhận và giải quyết chúng một cách hiệu quả hơn.
Nguyên tắc chia tách code theo class/module/package độc lập (decoupling)
Mỗi class nên chỉ làm một việc duy nhất, do vậy chia tách chương trình thành nhiều class khác nhau.
Mỗi module/package cũng chỉ nên làm các công việc thuộc về domain của nó.
Bên trong mỗi class/module/package hide đi các implement không cần thiết phải public ra.
Hiện nay, các ngôn ngữ lập trình đều tích hợp các công cụ quản lý gói như Composer cho PHP, npm cho Node.js, và Go Module cho Go Những công cụ này không chỉ hỗ trợ quản lý mã nguồn mà còn giúp tổ chức toàn bộ môi trường phát triển, từ kiến trúc công ty đến việc chia sẻ mã nguồn dưới dạng open source, góp phần vào cộng đồng lập trình.
Nguyên tắc theo composition hơn là thừa kế (composition over inheritance)
Giới thiệu công cụ review code
2.4.1 Review Code thủ công sử dụng pull request
Pull Request (PR) cho phép bạn thông báo cho người khác về những thay đổi mà bạn đã thực hiện trong kho Github Khi một pull request được gửi đi, những người quan tâm có thể xem xét các thay đổi, thảo luận về các sửa đổi tiềm năng, và thực hiện các commit bổ sung nếu cần thiết.
Pull Request là công cụ quan trọng trong các team hoặc tổ chức làm việc hợp tác trên mô hình kho chia sẻ như GitHub, nơi mỗi thành viên có thể phát triển các tính năng trên các nhánh riêng biệt (topic branch) nhằm tách biệt các thay đổi khỏi nhánh chính (master) Nhiều dự án trên GitHub áp dụng Pull Request để quản lý các thay đổi từ người đóng góp, giúp thông báo cho người bảo trì dự án về các thay đổi và khởi đầu giai đoạn code review, cũng như thảo luận về các thay đổi trước khi chúng được hợp nhất 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.
Trong quá trình phát triển phần mềm, mã nguồn chính thường được lưu trữ trong nhánh master Để phát triển tính năng mới mà không làm ảnh hưởng đến mã nguồn của nhánh master, lập trình viên sẽ tạo các nhánh con như feature_A, feature_B Mã nguồn mới sẽ được thêm vào các nhánh con này, giúp nhánh master duy trì trạng thái ổn định và phần mềm vẫn hoạt động bình thường trong suốt quá trình phát triển.
Khi lập trình viên hoàn thành việc viết code cho các tính năng, họ sẽ tạo Pull Request (PR) nhằm mục đích gộp mã nguồn mới vào mã nguồn cũ, một quy trình được gọi là merge source PR không chỉ là công cụ kỹ thuật mà còn thông báo cho các thành viên trong nhóm rằng họ đã hoàn thành công việc và sẵn sàng tích hợp mã nguồn mới vào phần mềm đang chạy, góp phần 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 tạo một Pull Request (PR) để yêu cầu hợp nhất mã nguồn, bạn chỉ hoàn thành một nửa quá trình, vì PR cần được "xác nhận" lần cuối trước khi lệnh merge được kích hoạt trên git Trên GitHub, việc "xác nhận" này thực hiện bằng cách nhấn nút MERGE trên PR Tại bước này, bạn có thể nhờ một thành viên trong nhóm, người có kinh nghiệm, kiểm tra lại mã để đảm bảo tính năng mới hoạt động đúng, đạt hiệu suất cao và bảo mật Khi các tiêu chí chất lượng mã nguồn được xác nhận, tính năng mới sẽ chính thức được hợp nhất vào sản phẩm Công việc kiểm tra này được gọi là review.
PR thể hiện kiến thức và kỹ năng của bạn Nhờ người khác nhận xét và kiểm tra giúp bạn hạn chế lỗi trong quá trình viết code, đồng thời rút ra nhiều bài học mới và nhận diện các vấn đề 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 các PR được hợp nhất vào nhánh chính của sản phẩm, thông tin liên quan sẽ được lưu trữ vĩnh viễn Phần mềm quản lý mã nguồn ghi lại mọi thay đổi chi tiết về mã nguồn, cho phép truy vấn lại thông tin về các PR sau này Nhờ vậy, quá trình phát triển sản phẩm được ghi chép một cách rõ ràng và chi tiết thông qua các PR.
Tất cả mọi người lớn đều từng là trẻ con, và cũng như vậy, mọi phần mềm phức tạp đều bắt nguồn từ những điều đơn giản Mỗi Pull Request (PR) giống như một bài học quý giá trong quá trình trưởng thành Những PR từ quá khứ mang lại nhiều bài học hữu ích về phát triển phần mềm mà bạn có thể học hỏi và áp dụng.
Là cơ hội giúp bạn học hỏi từ người khác
Để phát triển kỹ năng lập trình, việc thực hành viết code thường xuyên là rất quan trọng Tuy nhiên, khi bạn còn ít kinh nghiệm, việc được giao phụ trách các tính năng lớn và phức tạp từ cấp trên có thể gặp khó khăn.
Khi không được giao vai trò chính trong phát triển và tạo ra các PR, bạn vẫn có thể học hỏi thông qua việc đóng góp những commits nhỏ.
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 các nhóm lớn, số lượng PRs (pull requests) được tạo ra trong quá trình phát triển sản phẩm sẽ rất nhiều Những PRs này không chỉ chứa đựng các giải pháp cho những vấn đề bạn có thể chưa biết mà còn là nguồn tài liệu quý giá giúp bạn học hỏi thêm nhiều điều mới mẻ và bổ ích cho sự phát triển cá nhân.
2.4.2 Review Code tự động sử dụng công cụ Codacy
Codacy là công cụ phân tích mã tự động giúp cải thiện chất lượng phần mềm cho các nhà phát triển Nó cung cấp phân tích tĩnh, đánh giá độ phức tạp chu kỳ, kiểm tra trùng lặp và thay đổi trong phạm vi kiểm tra đơn vị mã cho mỗi yêu cầu cam kết và kéo Sử dụng Codacy, bạn có thể vận chuyển phần mềm nhanh chóng và hiệu quả hơn.
Codacy là công cụ lý tưởng để thực thi tiêu chuẩn chất lượng mã, giúp tiết kiệm thời gian trong việc đánh giá mã và áp dụng các thực tiễn bảo mật tốt nhất, đồng thời hỗ trợ các nhà phát triển nhanh chóng làm quen với dự án Bằng cách tích hợp với kho GitHub, Codacy cung cấp phân tích chất lượng cho mọi yêu cầu kéo trong GitHub, giúp quy trình code review trở nên hiệu quả hơn.
, đẩ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 mã là điều quan trọng, giúp bạn có cái nhìn tổng quan về chất lượng dự án và dễ dàng sửa chữa các lỗi kỹ thuật theo thời gian Codacy hỗ trợ hơn 20 ngôn ngữ, đáp ứng đa dạng nhu cầu của các dự án khác nhau.
Bao phủ mã là yếu tố quan trọng trong quản lý chất lượng dự án Với việc tích hợp CI, Codacy hỗ trợ bạn nâng cao phạm vi bao phủ mã, giúp cải thiện chất lượng dự án 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.
DEMO QUÁ TRÌNH REVIEW CODE
Các bước review code tự động
Bước 1: Truy cập trang web: https://github.com/ và đăng kí tài khoản thực hiện đăng nhập vào hệ thống GitHub
Bước 3: Đẩy source code lên repository vừa tạo
Bước 4: truy cập trang: https://github.com/marketplace/category/code-review và click vào biểu tượng logo của công cụ Codacy
Bước 5: tiến hành cài đặt codacy
Bước 6: Add project cần review code
Bước 7: Thống kê và phân loại các vấn đề mã nguồn
Bước 8: Phân tích chi tiết vấn đề
Bước 9: Sau khi xác định được vấn đề ta tiến hành về trang quản lí GitHub để sửa đổi mã nguồn
Bước 10: Đánh giá kết quả review
Các bước review code thủ công
Bước 1: tạo tài khoản git/github
Bước 2: Tạo Repositories và set quyền cho các Branch+ Tạo 1 Repositories
Bước 3: Thêm các thành viên vào dự án
Bước 4: Code và push code lên Github.
Bước 6: Các thành viên review code và cho đánh giá.
+ Nếu code được chấp nhận thì nhấn Mege pull request.
+nếu code không được chấp nhận thì review và sửa đến khi nào được chấp nhận thì dừng.
