Vận hành và bảo trì phần mềm

ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG THÁI NGUYÊN KHOA CÔNG NGHỆ THÔNG TIN BÀI BÁO CÁO VẬN HÀNH VÀ BẢO TRÌ PHẦN MỀM Chủ đề Xét duyệt mã nguồn Source code review Thái Nguyên 2022 Mục lục Bảng Phâ.

ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG THÁI NGUYÊN

KHOA CÔNG NGHỆ THÔNG TIN

BÀI BÁO CÁO VẬN HÀNH VÀ BẢO TRÌ PHẦN MỀM Chủ đề: XÉT DUYỆT MÃ NGUỒN - SOURCE CODE REVIEW

Thái Nguyên 2022 Mục lục Bảng Phân Công Công Việc 3

CHƯƠNG 1: TỔNG QUAN VỀ CODE REVIEW 4

1.1 Code Review là gì? 4

1.1.1 Giới thiệu 4

1.1.2 Tại sao cần review ? 7

1.2 Git/GitHub là gì? 8

1.3 Lý do chọn đề tài 9

1.4 Phạm vi đề tài 9

CHƯƠNG 2 ĐẢM BẢO CHẤT LƯỢNG MÃ NGUỒN 10

2.1 Thanh tra mã nguồn 10

2.2.2 Các loại code smell thường gặp 12

2.3 Các tiêu chí/tiêu chuẩn Review Code 16

2.3.1 Code Standards 16

2.3.2 Các nguyên tắc lập trình 19

2.4 Giới thiệu công cụ review code 22

2.4.1 Review Code thủ công sử dụng pull request 22

2.4.2 Review Code tự động sử dụng công cụ Codacy 26

CHƯƠNG 3: DEMO QUÁ TRÌNH REVIEW CODE 34

3.1 Các bước review code tự động 34

3.2 Các bước review code thủ công 40

Bảng Phân Công Công Việc

 Lập kế hoạch phân công công việc, giám sát, theo dõi tiến độ dự án

 Tham gia xây dựng demo

 Nghiên cứu, tổng hợp tài liệu

 Xây dựng tài liệu, đưa ra các chuẩn

để review code

 Giới thiệu công cụ Codacy

 Tham gia review code thủ công

 Tham gia xây dựng demo reviewcode tự động

 Tham gia xây dựng demo reviewcode thủ công

CHƯƠNG 1: TỔNG QUAN VỀ CODE REVIEW 1.1 Code Review là gì?

1.1.1 Giới thiệu

Code Review là quá trình mà các lập trình viên xem xét và đánh giá code của một thành

viên khác trong nhóm Đó cũng là quá trình thảo luận với nhau trên các dòng code, qua

đó đưa ra những góp ý hữu ích làm cho các dòng code thêm chất lượng hơn

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

Các cách thực hiện code review hiệu quả

sẵn lòng chia sẻ kiến thức của mình với người khác

đưa ra những góp ý mang tính xây dựng

không lợi dụng code review vào mục đích công kích người khác

luôn muốn tiếp thu những góp ý hữu ích của người khác để hoàn thiện mình hơn

biết trân trọng những đóng góp của các thành viên khách trong nhóm

Các lỗi thường gặp trong code review

Cú pháp code: Một trong những bước code review cơ bản là kiểm tra cú lỗi cú pháp Các

issue chẳng hạn như thò thụ không đúng, căn lề, thừa dấu cách, thiếu dấu chấm phẩy, thiếu đóng ngoặc dường như không đủ nhưng cũng giúp đóng góp vào chất lượng code

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

Grammar: Có lỗi typo, lỗi chính tả trong code? Ngữ pháp viết có chuẩn không? Sử dụng

tiếng Anh đúng đắn phải được đảm bảo Tên file, tên biến, tên class đã có nghĩa chưa?

Gợi ý lỗi code tiềm tàng: Gợi ý là xử lý của một chương trình sẽ phân tích code để đưa

ra các lỗi tiềm tang Nếu code của bạn được triển khai trên editor có các trình phân tihcs code sẽ check với bất cứ lỗi nào bởi developer Có nhiều thư viện có sẵn cho các loại ngôn ngữ khác nhau giúp thông báo những lỗi tiềm tàng trong code của bạn Ví

dụ ESLint cho Javascript hay Rubocop cho Ruby…

Tính sử dụng lại code và lỗi trùng lặp code: DRY (Don’t Repeat Yourself) là một

nguyên tắc giúp loại bỏ sự lặp lại trong code Các phương thức đã có có được sử dụng hiệu quả? Nếu code tương tự được sử dụng trong nhiều file, hãy làm cho nó có thể dùng chung đi Vậy thì tất cả code mới nên được viết với tư duy có thể dùng cho sau này Điều này giúp code của chúng ta nhỏ đi và dễ bảo trì hơn

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: Code luôn có sai sót Trong thực tế code sẽ output ra một kết quả tuy

nhiên khi nó có lỗi, thì cơ chế xử lý lỗi là cần thiết Error handling sẽ bắt một lỗi và chuyển nó sang đoạn code khác mà bạn muốn thay vì tắt luôn chương trình Ví dụ: API trả về message và status code

Testing: TDD (Test Driven Development) là một phần cơ bản của lập trình Tất cả các

developer đều sẽ phải tìm hiểu về nó không sớm thì muộn Đảm bảo rằng chương trình chdứa các đoạn code test cho tất cả code là điều cần thiết Test giúp bắt và giảm thiểu bugxảy ra nếu có, kiểm tra các hành vi đã có trên code được thay thế và có thể tạo các tài liệutốt cho các tính năng có sẵn Nó cũng giúp tập hợp các developer để tìm hiểu vào các đoạn code có sãn Luôn check nếu tất cả các test đều pass

Review được chia làm 2 loại chính:

Review thủ công: Do chính các developer của dự án hoặc các thành viên được phân công

review được gọi là reviewer thực hiện review code các pull request do các thành viên khác gửi lên Khi pull request đáp ứng đủ các tiêu chí/tiêu chuẩn đã đề ra thì mới được accept merge Chủ yếu là các vấn đề về thuật toán, code standards,… Nếu không đạt sẽ bịignore và người gửi pull request sẽ phải code lại sau đó thực hiện pull request và quá trình được lặp lại cho đến khi pull request đạt yêu cầu

Review tự động: Review code tự động là phương pháp dùng các công cụ tự động được

tích hợp sẵn để thực hiện việc review code tự động Ví dụ như tìm lỗi cú pháp, indent,… Việc review code tự động thường được thực hiện trước khi review code thủ công, nhằm

ra soát lại các lỗi mà review tự động không thể phát hiện

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ả 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ắcphả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.

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ả

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

1.2 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

System – DVCS) là một trong những hệ thống quản lý phiên bản phân tán phổ biến nhất hiện nay, nó cung cấp các lệnh giúp quản lý mã nguồn dễ dàng hơn

DVCS là hệ thống giúp mỗi máy tính có thể lưu trữ nhiều phiên bản khác nhau của một

mã nguồn được nhân bản (clone) từ một kho chứa mã nguồn (repository), mỗi thay đổi vào mã nguồn trên máy tính sẽ có thể ủy thác (commit) rồi đưa lên máy chủ nơi đặt kho chứa chính Và một máy tính khác (nếu họ có quyền truy cập) cũng có thể clone lại mã nguồn từ kho chứa hoặc clone lại một tập hợp các thay đổi mới nhất trên máy tính kia.Git là một trong những DVCS phổ biến nhất hiện nay, được nhiều tổ chức, dự án lớn sử dụng như Google, Facebook, Microsoft,… Sử dụng git như một kỹ năng bắt buộc đối vớimột lập trình viên khi tham gia vào các dự án có nhiều thành viên Git đang dần chở nên thông dụng và dần thay thế các SVN truyền thống

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ụ máy chủ repository công cộng, mỗi người có thể tạo tài khoản trên

đó để tạo ra các kho chứa của riêng mình để có thể làm việc

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

CHƯƠNG 2 ĐẢM BẢO CHẤT LƯỢNG MÃ NGUỒN 2.1 Thanh tra mã nguồn

Thanh tra mã nguồn là một dạng của kiểm tra/kiểm thử phần mềm Đó là tiến trình dò

tìm lỗi tiềm ẩn bên trong mã nguồn phần mềm sau khi mã nguồn đã hết lỗi cú pháp và trước khi mã nguồn được biên dịch thành chương trình thực thi Tiến trình thanh tra đượccác công ty phần mềm áp dụng và linh động tùy theo điều kiện của mình Trong thực tế, mỗi nhóm thanh tra mã nguồn khoảng 4 – 6 người Thời gian cho mỗi lần họp nhóm không quá 2 giờ Thông thường, báo cáo lỗi của nhóm thanh tra được xem là tốt nếu có trên 70% mà tác giả của nó bắt buộc phải sửa (tức là lỗi thực sự mà tác giả của mã nguồn phải công nhận) Nếu đọc mã nguồn thủ công thì trung bình mỗi thanh tra viên có thể đọckhoảng 120 dòng mã nguồn mỗi giờ Mỗi buổi họp nhóm (khoảng 2 giờ) có thể duyệt quađược tối đa khoảng 1200 dòng mã nguồn

Lỗi trong mã nguồn rất đa dạng, năng suất phát hiện lỗi tùy thuộc nhiều vào kỹ năng phân tích mã nguồn của các thanh tra viên Lỗi cần thanh tra được phân chia thành từng nhóm tương ứng với đặc điểm của đối tượng lập trình Gồm các nhóm lỗi cơ bản sau:

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?

Code có phần nào gọi các thủ tục không cần thiết hay những đoạn unreachable code? Tất cả các đoạn code lặp có được đưa vào cùng một thủ tục hay chưa?

Lỗi tài liệu:

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ớ?

Lỗi chia 0?

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?

Lỗi nhập xuất:

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ớ:

Lỗi tham chiếu rỗng?

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?

2.2, Code Smell

2.2.1, Khái niệm

Code smells là một thuật ngữ rất phổ biến đối với các lập trình viên, vậy nó là gì, tại sao

chúng ta phải quan tâm đến code smells, và tại sao phải hạn chế code smell bên trong mã lệnh của bạn? Hy vọng bài viết này sẽ giải đáp được phần nào cho các bạn mới làm quen với thế giới lập trình

Theo Wikipedia, Code smells (code mà bốc mùi, hoặc có mùi lạ trong code) là bất kỳ triệu chứng bất ổn nào bên trong mã nguồn của một chương trình, mà vì nó có thể sẽ dẫn đến các vấn đề lớn hơn Code smells không phải là bugs (lỗi lập trình), nghĩa là chúng không làm sai chứ năng của ứng dụng Thay vào đó, chúng là biểu hiện của sự yếu kém trong thiết kế và sẽ làm cho quá trình phát triển ứng dụng bị chậm lại hoặc tăng nguy cơ của bugs hoặc lỗi trong tương lai

2.2.2 Các loại code smell thường gặp

Code smells bên trong class

Comments (ghi chú): không nên sử dụng comment tùy tiện, bạn nên comment khi thực

sự cần thiết Một comment phải giải thích được "tại sao", chứ không phải là "cái gì" Bạn

có thể cải tiến mã lệnh để không cần phải dùng comment được không? Khi đó tự mã lệnhgiải thích cho nó mà không cần đến comment Và lưu ý rằng, comment phải dễ hiểu, bởi

nó dành cho con người, không phải để dành cho máy

Long method (Phương thức có độ dài lớn): Phương thức ngắn thì dễ đọc, dễ hiểu và dễ

xử lý khi có lỗi xảy ra hơn Hãy cố gắng chia tách những phương thức dài thành những phương thức nhỏ hơn khi bạn có thể

Long parameter list (quá nhiều tham số cho một phương thức): Phương thức càng

nhiều tham số, nó càng phức tạp Hãy hạn chế số lượng tham số cho một phương thức, hoặc bạn cần phải sử dụng một đối tượng chứa các tham số đó

Conditional complexity (độ phức tạp của các lệnh điều kiện): hãy cẩn thận với các

khối lệnh điều kiện lớn, vì chúng thường sẽ phình to theo thời gian, bạn có thể tìm kiếm các cách khác theo lập trình hướng đối tượng để thay thế như các mẫu decorator, strategy,hoặc state

Combinitorial explosion: bạn có rất nhiều mã lệnh thực hiện phần lớn các công việc gần

giống như nhau, nhưng chỉ khác nhau một xiu về dữ liệu hoặc hành vi Trường hợp này không dễ để cải thiện, tuy nhiên, bạn có thể thử dùng generics hoặc interpreter

Large class (lớp có lượng mã lệnh rất lớn): các lớp có lượng mã lệnh lớn thường khó

để đọc và hiểu Liệu lớp bạn xây dựng có đảm trách nhiều vai trò quá không? Nếu vậy, bạn nên tái cấu trúc lớp đó thành nhiều lớp nhỏ hơn

Type embedded in name (tên phương thức có chứa tên kiểu dữ liệu trả về): Nếu

phương thức của bạn có tên chứa tên kiểu dữ liệu trả về, bạn nên sửa lại, bởi vì khi bạn thay đổi kiểu dữ liệu trả về, bạn phải thay đổi tên của phương thức

Uncommunicative name (tên lạ, tên khó hiểu): Đây là trường hợp tên của phương thức

không diễn tả được mục đích của phương thức, và tên khó đọc Bạn nên đổi tên các phương thức kiểu như vậy

Inconsistent names (cách đặt tên không nhất quán): bạn nên thống nhất cách đặt tên

nhất quá cho các phương thức Ví dụ nếu bạn có phương thức Open(), bạn nên có phươngthức Close()

Dead code (mã lệnh không sử dụng): Hãy xóa các mã lệnh không còn sử dụng Nếu

bạn lo rằng tới một ngày kia bạn sẽ cần phải sử dụng nó, bạn đừng lo, bởi nếu có sử dụngcác công cụ Version Controls, chúng sẽ lưu lại các phiên bản cũ cho bạn

Speculative generality: hãy viết code để giải quyết vấn đề hiện tại, và chỉ quan tâm đến

các vấn đề tương lai nếu chúng thực sự cần thiết, nếu không hãy bỏ qua Bạn cần tuân thủnguyên tắc YAGNI (You Ain’t Gonna Need It) Tôi sẽ sớm có bài viết về YAGNI

Oddball Solution (inconsistent solution – giải pháp không nhất quán): Bạn chỉ nên

dùng một cách duy nhất để xử lý một vấn đề bên trong mã lệnh của bạn nếu không bạn đãmắc phải code smell Oddball Solution

Temporary Field (trường tạm): Đừng để quá nhiều trường tạm, không cần thiết trong

mã cài đặt các đối tượng của bạn

Code smells giữa các class với nhau

Các class tương tự nhau nhưng bề ngoài khác nhau: Nếu hai lớp giống nhau bên

trong, nhưng lại khác nhau ở bên ngoài, thì bạn nên sửa chúng để chúng cùng chung một interface

Primitive Obsession (nỗi ám ảnh về kiểu dữ liệu nguyên thủy): đối với những người

mới làm quen với lập trình hướng đối tượng, đôi khi họ lưu những thông tin của đối tượng bên trong đối tượng khác bằng cách sử dụng các kiểu primitive Nếu dữ liệu đủ phức tạp, bạn nên sử dụng một lớp để thể hiện nó

Data class: các lớp dữ liệu, có chứa các trường lưu dữ liệu, các getters và setters, nhưng

ngoài ra không còn gì cả Code smell ở đây là các lớp này chỉ chứa dữ liệu và được khởi tạo một cách quá chi tiết bởi các lớp khác Cần phải đảm bảo tính đóng gói của các lớp này

Data clumps: Nếu bạn thấy các phần tử dữ liệu hay đi kèm với nhau tại nhiều nơi, ví dụ

như các trường bên trong một vài lớp, là tham số của nhiều phương thức, bạn nên gộp chúng lại thành đối tượng

Refused Bequest: Bạn sử dụng kế thừa, nhưng lại hầu như không sử dụng các phương

thức được kết thừa, vậy liệu có nên sử dụng kế thừa không?

Inappropriate Intimacy: Các lớp không nên xử liệu quá nhiều công việc của nhau Các

lớp nên biết về nhau càng ít càng tốt

Indecent Exposure: Các lớp không nên "show" quá nhiều nội tình bên trong nó Khi bạn

công khai một trường hoặc một phương thức của một class, bạn cần phải có lý do thực sựhợp lý, nếu không, hãy giấu chúng đi

Feature Envy: Đây là trường hợp một lớp có một phương thức được sử dụng nhiều hơn

bởi lớp khác hơn là chính lớp đó Nếu trường hợp như vậy xảy ra, bạn nên di chuyển phương thức đó sang lớp kia

Lazy Class (lớp lười nhác): Không nên tồn tại những lớp không thực hiện việc gì cả

Việc có càng nhiều lớp, sẽ càng làm phức tạp cho dự án của bạn Nếu một lớp được sinh

ra chả để làm gì cả, bạn có thể nghĩ đến việc xóa nó, hoặc hợp nó với một lớp khác

Message Chains (chuỗi thông điệp): Có những trường hợp, code của bạn gọi mỗi chuỗi

các phương thức từ các đối tượng để lấy dữ liệu nào đó, ví như var

().getAnotherThing().getAnotherThing2…

Middle Man (lớp trung gian): nếu một lớp trung gian chỉ có mặt để truyền lời gọi đến

các lớp khác, thì lớp đó không nên tồn tại

Divergent Change: nếu bạn đổi một phần này của lớp và kéo theo phải đổi các phần

khác của lớp, thì có thể nó đang mang trong mình nhiều thứ không liên qua Hãy nghĩ đến việc cô lập các phần có thể gây ảnh hưởng và chuyển qua một lớp khác

Shotgun Surgery: Nếu thay đổi của một lớp gây sự thay đổi đến nhiều lớp khác, thì bạn

nên nghĩ đến việc cải tổ code để hạn chế sự thay đổi chỉ ảnh hưởng đến bên trong lớp đó

Parallel inheritance hierarchies: code smell này là hiện tượng khi bạn thêm một lớp

con của một lớp này, thì bạn cũng phải tạo thêm lớp con của một lớp khác

Incomplete Library Class: đây là code smell khi chúng ta cần thêm một phương thức

vào một lớp trong thư viện, nhưng chúng ta không thể thay đổi thư viện để thêm phương thức đó vào

Solution Sprawl: để thực hiện một việc gì đó, bạn cần quá nhiều các lớp khác nhau tham

gia (trên 5 lớp), thì đó là dấu hiệu của code smell Solution Sprawl Hãy nghĩ tới việc đơn giản hóa thiết kế của bạn

2.3 Các tiêu chí/tiêu chuẩn Review Code

2.3.1 Code Standards

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 \

<Vendor Name>\(<Namespace>\)*<Class Name>

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 : Các chuẩn cơ bản

Đây là các chuẩn dùng để viết code, có một vài quy tắc đơn giản dễ hiểu dễ nhớ như sau Thậm chí đọc xong các bạn sẽ thấy nó hiển nhiên vì lâu nay mình vẫn áp dụng mà giờ mới biết tên của nó là gì

Code phải được viết trong cặp thẻ <?php ?> và nên sử dụng cặp thẻ ngắn <?= ?> thay choecho

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à

StudlyCaps

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 một file PHP chỉ nên làm 1 nhiệm vụ duy nhất, tránh chồng chéo (gọi là side effect), như ví dụ dưới đây là sai vì nó thực thi quá nhiều task vụ trong 1 file

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(spaces) để thụt dòng, tuyệt đối không dùng tab (bạn có thể khai báo trong PHPStorm để khi ấn tab nó tương đương với việc thụt vào 4 spaces)

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

Phải dùng dấu nháy đơn ‘ để khai báo chuỗi không chứa biến, nếu chuỗi có chứa kí tự ‘ thì có thể dùng dấu nháy kép để bọc bên ngoài (Mình mới bị anh chị nhắc nhở vấn đề nàyxong)

Dùng dấu để nối chuỗi, chú ý rằng trước & sau dấu chấm phải có khoảng trắng Nếu chuỗi quá dài thì tách làm nhiều dòng và dấu chấm được đặt đầu dòng ngang với dấu bằng

Các tham số truyền vào hàm phải có 1 dấu cách trước dấu phẩy, bạn có thể tách thành nhiều dòng nhưng phải thụt lề 1 đơn vị

Đối với khối lệnh switch case thì 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 lùi 4 khoảng trắng so với case Phải có từ khóa break hoặc return, trong trường hợp nào không có thì phải comment //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

Vậy làm thế nào để code cho đơn giản, cái đó tác giả cũng không biết, nhưng chúng ta có thể tránh đi một điều có dẫn đến code phức tạp

Hãy chia cái hàm to thành nhiều hàm nhỏ hơn

Đừng viết các thuật toán, giải thuật gì đó kiểu như optimize cái này cái kia, tiết kiệm cái này cái khác, rồi làm mớ code trở nên khó hiểu

Nguyên tắc code sao cho gọn gàng, sạch sẽ (clear & clean)

Nói chung thế nào bạn cũng thích những người gọn gàng sạch sẽ, những nơi gọn gàng sạch sẽ, không ai thích code nhìn lộn xộn và nhức đầu Làm thế nào để có thể code gọn gàng và sạch sẽ:

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

Và hãy kiên nhẫn để theo đuổi triệt để các nguyên tắc mình đưa ra, hãy nhớ rằng nó không hề đơn giản để làm mọi thứ trở nên gọn gàng và sạch sẽ, phải trải qua nhiều lần cảithiện, rút kinh nghiệm, kiểm điểm bạn mới thiết lập cho mình một bộ các kỹ năng cần thiết để duy trì các thói quen đó

Nguyên tắc việc code sao cho có thể dễ dàng tái sử dụng (reusable)

Nếu không được reuse các đoạn mã cứ lặp đi lặp lại, mỗi lần sửa chữa, hay thay đổi bạn lại dễ dàng tạo ra bug, bởi vì quên chỗ này chỗ kia, và tất nhiều đọc code rất khó hiểu.Việc code để tái sử dụng cũng là việc rất khó, vì ban đầu bạn chỉ cố viết để nó work, chứ không phải viết code cho ngày mai, cho thằng khác nó dùng, lo nghĩ cho ngày mai là chuyện hết sức tiểu thuyết hư cấu và giả tưởng

Nhưng viết code để tái sử dụng, giúp bạn các kỹ năng về suy nghĩ thấu đáo vấn đế, có lợi cho bạn, khi bạn nghĩ tới điều này, có nghĩa là bạn đang cô lập các vấn đề của mình giúp cho bạn nhìn nhận ra các vấn đề tốt 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 classkhá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

Ngoài ra, ngày nay, các ngôn ngữ đều có các package management như Composer của PHP, npm của Nodejs, Go có Go Module v.v… Việc này, giúp cho không chỉ code, mà còn là tổ chức cho toàn bộ một môi trường lớn hơn, như kiến trúc cho công ty, thậm chí public chúng ta thành các open source để đóng góp cho người khác

Nguyên tắc theo composition hơn là thừa kế (composition over inheritance)

Việc thừa kế dẫn đến sự phức tạp bởi chúng phụ thuộc lẫn nhau, và để tránh phụ thuộc chúng ta lại phải liên tục tạo ra các thừa kế chồng lấn lên nhau Và chỉ có việc trace lại các tính năng từ ban đầu đã là sự phức tạp.

Bản thân thế giới máy tính được thiết kế từ điện tử, không phải sinh học, bản thân nó mình tin rằng có là một tổng thể các thành phần độc lập và được gắn lại với nhau Do do vậy, việc lập trình cơ bản cũng là các thành phần độc lập được gắn với nhau thông qua các interface, và giao tiếp qua các interface

Hãy quan sát các tiến bộ gần đây như React là các component được gắn với nhau

Hãy để ý rằng Go với việc embedded các struct

Hãy để ý rằng ngày nay, PHP có trait

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 đó, PRs cũng để thông báo với những người làm chung rằng: tôi đã làm xong và sẵn sàng