Clean Code là gì? Nguyên tắc và kỹ thuật viết code sạch dễ bảo trì

1. Clean code là gì? Tại sao lại quan trọng?

Định nghĩa clean code

“Clean code” là thuật ngữ mô tả phong cách viết mã nguồn rõ ràng, dễ đọc, dễ hiểu và dễ mở rộng. Một đoạn code được xem là “clean” khi người khác (hoặc chính bạn sau này) có thể đọc và chỉnh sửa mà không gặp khó khăn, không cần phải “giải mã” logic hoặc đoán ý tác giả.

Lợi ích thực tiễn khi áp dụng clean code

• Dễ bảo trì: Khi code rõ ràng, việc sửa lỗi, thêm tính năng mới trở nên dễ dàng, giảm nguy cơ phát sinh bug ngoài ý muốn.
• Hỗ trợ teamwork: Code sạch giúp đồng đội nắm bắt logic nhanh hơn, code review diễn ra hiệu quả hơn, tiết kiệm thời gian giao tiếp.
• Giảm technical debt: Clean code giảm bớt “nợ kỹ thuật”, tránh phải refactor lớn về sau.
• Tiết kiệm thời gian dài hạn: Đầu tư viết clean code ngay từ đầu giúp giảm chi phí vận hành, bảo trì hệ thống về sau.

Hệ quả khi code không “sạch”

• Khó bảo trì, khó mở rộng: Mỗi lần thêm tính năng hoặc fix bug là một lần “đau đầu”, dễ phát sinh lỗi dây chuyền.
• Tốn thời gian onboarding: Người mới khó đọc hiểu, mất nhiều thời gian làm quen với codebase.
• Tăng rủi ro bug tiềm ẩn: Code lộn xộn dễ gây ra lỗi khó phát hiện, tốn kém khi phải vá sau này.

2. Nguyên tắc cốt lõi khi viết clean code

KISS, DRY, YAGNI là gì?

• KISS (Keep It Simple, Stupid): Giữ cho code đơn giản nhất có thể, tránh phức tạp hóa vấn đề không cần thiết.
• DRY (Don’t Repeat Yourself): Tránh lặp lại logic hoặc đoạn code ở nhiều nơi, hãy tái sử dụng code thông minh.
• YAGNI (You Aren’t Gonna Need It): Không viết những thứ “có thể sẽ cần” nhưng thực tế chưa chắc dùng đến.

Đặt tên biến/hàm/class sao cho “clean”

• Tên biến/hàm nên rõ nghĩa: Ví dụ, thay vì đặt tên là a, b, nên đặt là userAge, orderTotal.
• Hạn chế viết tắt không rõ ràng: Không nên đặt prm thay cho parameter nếu không thực sự phổ biến.
• Hàm/class nên thể hiện đúng chức năng: Ví dụ, hàm xử lý gửi mail nên đặt là sendEmailNotification() thay vì processData().

Ví dụ:

// Bad
function c(a, b) {
    return a + b;
}

// Good
function calculateTotalPrice(price, quantity) {
    return price * quantity;
}

Giải thích: Tên hàm và biến rõ ràng giúp ai cũng hiểu được mục đích và logic.

Comment đúng cách, không lạm dụng

• Chỉ comment khi cần làm rõ ý đồ, giải thích logic phức tạp.
• Không comment những gì code đã thể hiện rõ ràng (VD: không cần ghi // tăng i lên 1 sau dòng i++).
• Ưu tiên viết code rõ ràng thay vì phụ thuộc vào comment.

Sắp xếp cấu trúc file/folder

• Tách biệt các module, tính năng rõ ràng, không gom hết vào 1 file dài.
• Đặt tên folder, file nhất quán, dễ tra cứu.
• Chia nhỏ chức năng theo domain hoặc feature nếu dự án lớn.

3. Cách nhận biết code “bẩn” (bad code)

Dấu hiệu phổ biến của code bẩn

• Đặt tên biến/hàm/class khó hiểu hoặc không rõ ý nghĩa.
• Logic lặp đi lặp lại ở nhiều nơi.
• Hàm hoặc class quá dài, làm quá nhiều việc (God Function/Class).
• Quá nhiều comment giải thích cho những đoạn code phức tạp.
• Dùng hardcode giá trị “ma thuật” (magic number).

Code smell là gì?

• Code smell là thuật ngữ chỉ những “mùi” đặc trưng cho đoạn code có vấn đề, dễ gây bug hoặc khó bảo trì về sau.
• Ví dụ: Duplicated code, long function, large class, nhiều điều kiện lồng nhau (deep nesting), nhiều magic number…

Các ví dụ thực tế

Ví dụ bad code:

function x1(a, b, c) {
    if (a == 1) {
        b = b + 1;
    } else if (a == 2) {
        c = c + 1;
    }
    // ...
}

Các vấn đề:

• Tên hàm và biến không rõ ràng
• Magic number (1, 2) không có ý nghĩa
• Logic lồng nhau khó đọc, không có comment

Sau khi refactor:

function updateUserScore(userType, currentScore, bonusPoint) {
    if (userType === "guest") {
        return currentScore + 1;
    }
    if (userType === "member") {
        return bonusPoint + 1;
    }
}

Giải thích: Đặt tên rõ ràng, thay magic number bằng giá trị có ý nghĩa.

4. Các kỹ thuật refactor để làm sạch code

Refactor là gì? Khi nào nên refactor?

• Refactor là quá trình chỉnh sửa lại code để cải thiện cấu trúc, tăng chất lượng mà không thay đổi chức năng bên ngoài.
• Nên refactor khi:
  • Code bắt đầu khó đọc, khó hiểu, khó test hoặc phát sinh bug lặp lại
  • Sau mỗi lần thêm tính năng lớn, tích hợp module mới
  • Chuẩn bị review code hoặc làm việc nhóm

Một số kỹ thuật refactor phổ biến

• Extract Method: Tách một đoạn code lặp lại/logic phức tạp thành một hàm riêng biệt.
• Rename: Đặt lại tên biến/hàm/class cho rõ nghĩa, dễ hiểu hơn.
• Remove Duplication: Loại bỏ các đoạn code trùng lặp, dùng chung function hoặc module.
• Replace Magic Numbers with Constants: Đưa các giá trị “ma thuật” thành hằng số (constant).
• Simplify Conditional: Đơn giản hóa các câu điều kiện phức tạp, tránh lồng quá sâu.

Minh họa refactor một đoạn code “bẩn”

Trước khi refactor:

def process(a, b):
    if a == 1:
        print("Admin user")
        b = b * 2
    elif a == 2:
        print("Normal user")
        b = b + 5
    print(b)

Sau khi refactor:

def print_user_type(user_type):
    if user_type == 1:
        print("Admin user")
    elif user_type == 2:
        print("Normal user")

def calculate_score(user_type, score):
    if user_type == 1:
        return score * 2
    if user_type == 2:
        return score + 5
    return score

def process(user_type, score):
    print_user_type(user_type)
    final_score = calculate_score(user_type, score)
    print(final_score)

Giải thích: Đoạn code được chia nhỏ theo từng chức năng rõ ràng, dễ mở rộng, dễ test.

5. Clean code trong teamwork và review code

Lợi ích clean code trong làm việc nhóm

• Dễ dàng chia sẻ, bàn giao code cho đồng đội mà không cần giải thích nhiều.
• Giảm thời gian onboarding cho thành viên mới.
• Tăng hiệu quả review code, giảm nguy cơ bug “ẩn”.
• Duy trì phong cách code thống nhất xuyên suốt dự án.

Làm sao để truyền thông và giữ codebase sạch qua code review?

• Thiết lập guideline (quy tắc, convention) về naming, cấu trúc thư mục, comment…
• Luôn thực hiện review code đôi (code review 2 người trở lên).
• Tạo checklist cho từng pull request: kiểm tra naming, logic lặp lại, magic number, comment thừa, v.v.
• Đưa ra feedback cụ thể, giải thích lý do đề xuất thay đổi để mọi người cùng học hỏi.
• Sử dụng các công cụ hỗ trợ review tự động (lint, CI).

6. Công cụ và checklist hỗ trợ clean code

Công cụ lint, formatter, CI hỗ trợ kiểm tra code

• Lint: Công cụ phát hiện vấn đề về cú pháp, style, và convention (VD: ESLint, Pylint…)
• Formatter: Tự động format lại code cho đồng nhất (Prettier, Black…)
• CI/CD: Tích hợp kiểm tra code tự động trước khi merge, phát hiện lỗi sớm (VD: Github Actions, Gitlab CI…)

Checklist tự kiểm tra trước khi submit code

• Tên biến, hàm, class rõ ràng chưa?
• Có lặp code ở đâu không? (DRY)
• Hàm/class có làm quá nhiều việc không?
• Có giá trị “magic number” nào không?
• Đã có test case hoặc thử chạy với dữ liệu thực tế?
• Có comment thừa hoặc mô tả lại những gì code đã thể hiện không?
• Cấu trúc file, folder đã hợp lý, nhất quán chưa?

7. FAQ: Các câu hỏi thường gặp về clean code

8. Tài liệu và nguồn học thêm về clean code

Sách, video, tài nguyên nên đọc

• Sách “Clean Code” của Robert C. Martin: Tác phẩm kinh điển, rất nên đọc.
• Refactoring Guru (https://refactoring.guru/): Trang web tổng hợp lý thuyết và ví dụ thực tế về clean code, code smell, refactor.
• YouTube – Clean Code (Traversy Media, TechLead, Fireship…): Nhiều video chia sẻ thực tiễn, hướng dẫn refactor, code review thực tế.

Link tham khảo cho dev Việt

• Viblo: Clean Code thực chiến
• Github: Awesome Clean Code
• Blog takidev.com: Luôn cập nhật các bài viết thực tiễn về kỹ thuật clean code, refactor, best practices.

Xem thêm: thiết lập ngưỡng rate-limit hiệu quả