Báo cáo Vận hành và Bảo trì Phần mềm

Mục Lục


Bảng Phân Cơng Cơng Việc
Tên Sinh Viên
Cơng Việc
Nguyễn Văn Giang(nhóm trưởng)
− 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
Nguyễn Hùng Anh
Nguyễn Thế Long

Lương Văn Minh
Nguyễn Thế Long

−
−
−
−
−
−

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 review
code tự động
Tham gia xây dựng demo review

code 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à q 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.
ln muốn tiếp thu những góp ý hữu ích của người khác để hồ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 ln 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 ln 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 bug
xả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ệu
tố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 tố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à q
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 số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ắc
phải, kể cả lập trình viên có kinh nghiệm nhưng nó khơng thể thố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ới
mộ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
Có tính cơng cơngk
Tính năng Explore
1.3 Lý do chọn đề tài
Trong lĩnh vực lập trình, code review mang lại rất nhiều lợi ích về việc đảm bảo chất
lượng mã nguồn. Từ đó là một sinh viên công nghệ thông tin chúng ra cần phải biết cách
review code đảm bảo chất lượng mã nguồn. Tìm hiểu về Code review để biết cách đánh
giá mã nguồn đồng thời giúp làm việc nhóm trở nên hiệu quả hơn.
1.4 Phạm vi đề tài
Làm rõ được vai trị của Code review trong quy trình đảm bảo chất lượng mã nguồn.
Tìm hiểu về Code review, cũng như các cách để đánh giá nó.

Demo triển khai q trình review code thủ công và tự động.


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 được
cá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 q 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ể đọc
khoả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 hồn tồn và chính xác theo thiết kế? • Code có tn 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 tốn trên các biến khơng phải kiểu số?
Tính tốn kiểu dữ liệu hỗn hợp?
Tính tố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ệnh
giả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ị q 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 q 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ương
thứ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ụng
cá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 ngồ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
ngồ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" q 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 q 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 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à
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 q 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 q 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 ngồi (Mình mới bị anh chị nhắc nhở vấn đề này
xong)


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 q 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 tố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ải
thiệ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 đó.
Ngun 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 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.
Ngồ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 tồ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
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 q 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 q 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 khun 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: