Vậy là code của bạn chạy được, không báo lỗi, và cho ra kết quả mong muốn? Tuyệt! Nhưng điều đó không có nghĩa là nó tốt. Thực tế, nó vẫn có thể rất tệ.
Viết code chỉ để nó chạy được là mức tối thiểu. Nếu nó khó đọc, khó bảo trì hoặc không thể mở rộng, bạn (và đồng nghiệp) sẽ gặp rắc rối trong tương lai. Hãy cùng xem một số dấu hiệu cho thấy code của bạn chưa tốt và cách khắc phục.
Dấu hiệu Code của bạn chưa tốt
1. Khó đọc
Code khó đọc là cơn ác mộng khi cần debug và bảo trì. Nếu một lập trình viên khác (hoặc chính bạn trong tương lai) không thể nhanh chóng hiểu code đang làm gì, thì nó cần được cải thiện.
VD code tệ:
function x(a, b) { if (b > 0) { return a + b; } else { return a - b; }
}
x là gì? a và b đại diện cho cái gì? Thật khó hiểu!
Nên code theo cách này:
function calculateTotal(price, tax) { return tax > 0 ? price + tax : price - tax;
}
Bây giờ bạn đã biết rõ chức năng của hàm và ý nghĩa của từng tham số.
2. Lặp lại quá nhiều (Vi phạm nguyên tắc DRY)
Lặp lại cùng một logic ở nhiều nơi sẽ khiến code khó cập nhật và bảo trì hơn.
VD về code tệ:
def calculate_area_circle(radius): return 3.14159 * radius * radius def calculate_area_square(side): return side * side def calculate_area_rectangle(length, width): return length * width
Nên sửa lại theo cách này:
def calculate_area(shape, *args): formulas = { "circle": lambda r: 3.14159 * r ** 2, "square": lambda s: s ** 2, "rectangle": lambda l, w: l * w } return formulas.get(shape, lambda: None)(*args)
Bây giờ, việc thêm một shape mới chỉ yêu cầu sửa đổi một từ điển thay vì tạo một hàm mới.
3. Không dễ mở rộng
Logic được viết cứng nhắc có thể hoạt động tốt ngay bây giờ, nhưng khi yêu cầu tăng lên, code của bạn có thể trở thành một mớ hỗn độn.
VD về code tệ:
if (userRole.equals("admin")) { showAdminDashboard();
} else if (userRole.equals("editor")) { showEditorDashboard();
} else if (userRole.equals("viewer")) { showViewerDashboard();
}
Nên code lại theo cách này:
Map<String, Runnable> roleActions = Map.of( "admin", this::showAdminDashboard, "editor", this::showEditorDashboard, "viewer", this::showViewerDashboard
);
roleActions.getOrDefault(userRole, this::showDefaultDashboard).run();
Bây giờ, việc thêm vai trò mới chỉ yêu cầu cập nhật bản đồ.
4. Không có kiểm thử (Test)
Bạn nghĩ code của mình chạy ổn. Nhưng nếu không có test, làm sao bạn chắc chắn điều đó?
Luôn viết các bài test:
def add(a, b): return a + b def test_add(): assert add(2, 3) == 5 assert add(-1, 1) == 0 assert add(0, 0) == 0
Các bài test đảm bảo những thay đổi trong tương lai không gây ra lỗi không mong muốn.
5. Không hiệu quả
Code của bạn có thể đúng nhưng lại chạy chậm do lựa chọn thuật toán kém tối ưu.
VD về code tệ:
def find_duplicates(arr): duplicates = [] for i in range(len(arr)): for j in range(i+1, len(arr)): if arr[i] == arr[j] and arr[i] not in duplicates: duplicates.append(arr[i]) return duplicates
Nên code lại theo cách này:
def find_duplicates(arr): seen = set() duplicates = set() for num in arr: if num in seen: duplicates.add(num) seen.add(num) return list(duplicates)
Phiên bản này nhanh hơn đáng kể đối với các tập dữ liệu lớn.
Cách viết Code tốt hơn
✅ Tuân thủ quy tắc coding – Sử dụng PEP8 (Python), ESLint (JavaScript), v.v.
✅ Đặt tên có ý nghĩa – Biến và hàm nên tự giải thích được chức năng của chúng.
✅ Viết code theo hướng module – Chia nhỏ hàm lớn thành các phần nhỏ, có thể tái sử dụng.
✅ Tránh số "ma thuật" (Magic Numbers) – Sử dụng hằng số thay vì những giá trị không giải thích được.
✅ Liên tục refactor – Cải thiện code thay vì chỉ làm cho nó chạy được.
✅ Viết test – Kiểm thử tự động giúp đảm bảo tính ổn định.
Kết luận
Code chạy được không phải là đích đến — đó chỉ là điểm khởi đầu. Bằng cách cải thiện khả năng đọc, khả năng mở rộng, hiệu suất và kiểm thử, bạn có thể viết code không chỉ chạy mà còn chạy tốt.
💡 Thói quen code tệ nhất mà bạn từng thấy (hoặc từng mắc phải) là gì? Hãy thử chia sẻ nhé!