Khi code tối ưu quá mức thành… khó đọc

Code one-liner siêu tối ưu, nhưng team đọc xong muốn nghỉ việc!

Một team phát triển app logistics Việt Nam, dev viết code siêu tối ưu, nén logic 50 dòng thành one-liner. Kết quả? Không ai maintain được, sửa 1 dòng gây bug mới, team mất 2 tuần refactor.

Case thực tế: Code “clever” gây thảm họa

• Context: App logistics, tính phí vận chuyển, 500 dòng code. 
• Quyết định sai: Viết one-liner tối ưu performance, dùng bitwise, regex phức tạp. 
• Vấn đề: 
  • Code khó đọc: One-liner 200 ký tự, không comment. 
  • Maintain khó: Sửa 1 dòng, bug lòi ra ở 3 chỗ khác. 
  • Dev mới mất 1 tháng để hiểu code.

Hậu quả: 

• Bug mới: Sửa code gây lỗi tính phí sai. 
• Chậm tiến độ: Refactor mất 2 tuần, delay feature. 
• Team nản: Dev mới ngán maintain, xin nghỉ.

Phân tích: Tại sao sai?

• Ưu tiên clever hơn readable: Code tối ưu 5% nhưng khó hiểu gấp 10 lần. 
• Thiếu comment: One-liner không giải thích logic. 
• Không ưu tiên maintainability: Team nhỏ, cần code dễ sửa.

Bài học: Readable > Clever

1. Viết code dễ đọc: Tách logic thành hàm nhỏ, đặt tên rõ ràng. 
2. Comment đầy đủ: Giải thích ý định của code phức tạp. 
3. Test trước tối ưu: Chỉ tối ưu khi performance thực sự là vấn đề.

Code mẫu: Code readable (Node.js)

function calculateFee(distance, weight) {
    const baseFee = 10;
    const extraFee = distance * 0.5 + weight * 2;
    return baseFee + extraFee;
}

Code “clever” không làm bạn “xịn”. Viết readable, comment rõ, chỉ tối ưu khi cần, để team không nghỉ và bug không “mọc” như nấm!

Checklist code readable: 

• Tách logic thành hàm nhỏ, tên rõ ràng. 
• Comment ý định của code phức tạp. 
• Test performance trước khi tối ưu. 
• Audit code readability định kỳ.

🎯 Tóm lại: Code one-liner siêu tối ưu là “tự bắn vào chân”. Viết readable, dễ maintain, để team không “khóc” và bug không thành “nấm”!