Clean code thực dụng: viết code để người sau sửa được an toàn Trung cấp

Cụm này trả lời: “clean” nghĩa là gì khi đo bằng chi phí sửa code, và refactor một service thật từng bước ra sao mà không làm vỡ production.

Vấn đề

“Clean” không phải là đẹp hay ngắn. Định nghĩa vận hành của cụm này:

• Rẻ để sửa: một thay đổi nghiệp vụ chạm ít file, ít nhánh.
• An toàn để sửa: sửa xong có test bắt được hồi quy, lỗi không bị nuốt.
• Dễ review: người review hiểu ý định trong vài phút, không phải chạy code trong đầu.

Mọi quy tắc phải trả lời được: “nó làm thay đổi tiếp theo rẻ hơn hay an toàn hơn ở đâu?”. Không trả lời được thì đó là dogma, bỏ qua.

Clean Code (sách) không phải luật

Nhiều lời khuyên trong Clean Code của Robert Martin đang bị tranh luận công khai. Ousterhout (A Philosophy of Software Design) và Martin đã đối thoại về ba điểm: độ dài hàm, comment và TDD.

• Ousterhout: tách quá nhiều hàm nhỏ làm interface nông và rối.
• Martin chấp nhận sách thiếu hướng dẫn khi nào dừng tách.
• Cụm này đứng giữa: tách khi tên hàm mới giúp đọc nhanh hơn, không tách để đạt số dòng.

Đọc theo thứ tự nào

Đang tải diagram…

Trong cụm này

Phần	Câu hỏi nó trả lời
Refactor an toàn	Code “before” sai ở đâu? Làm sao refactor mà chứng minh được không đổi hành vi?
Hàm và side effect	Guard clause, bỏ flag, hằng số có đơn vị, tách lõi thuần khỏi I/O thế nào?
Lỗi, comment, DRY	Lỗi nào là kết quả, lỗi nào là exception? Comment gì? Khi nào trùng lặp tốt hơn abstraction?
Lỗi hay gặp	Các mẫu code BAD/GOOD dev hay viết, hậu quả cụ thể khi nào nổ

Tóm tắt quyết định

Triệu chứng trong code	Mặc định nên làm	Vì sao
if lồng 3-4 tầng	Guard clause, return sớm	Đường chính đọc thẳng một mạch
Tham số boolean (express, dryRun)	Tách hàm, hoặc union type	Call site checkout(x, true, false) không ai đọc được
Hơn ~3 tham số cùng đi với nhau	Parameter object	Thêm field không phá mọi call site
500000, 0.9, 12 trong logic	Hằng số có tên và đơn vị	Sửa một chỗ, grep được
Logic tính toán trộn với DB/HTTP/new Date()	Functional core, imperative shell	Test core không cần mock
catch (e) { console.log(e) }	Ném lại với context + cause, hoặc xử lý thật	Lỗi nuốt = dữ liệu sai âm thầm
Nhánh nghiệp vụ dự kiến (declined, hết hàng)	Trả về kết quả có kiểu	Exception dành cho điều bất thường
Hai đoạn code giống nhau	Chờ lần thứ ba	Abstraction sai đắt hơn trùng lặp
Comment kể lại code làm gì	Xoá, đặt tên tốt hơn; comment giải thích vì sao	Comment “what” nhanh lỗi thời

Checklist code review

1. Commit refactor và commit đổi hành vi có tách riêng không? Commit refactor có sửa test không (không nên)?
2. Có catch nào không ném lại, không xử lý thật, chỉ log không?
3. Lỗi ném ra có đủ context (id, số tiền, key) và giữ cause không?
4. Nhánh nghiệp vụ dự kiến có đang dùng exception làm luồng điều khiển không?
5. Có tham số boolean nào ở public method không? Call site có đọc được không cần mở định nghĩa?
6. Số và chuỗi nghiệp vụ có tên và đơn vị chưa? Có giá trị nào bị lặp ở nhiều nơi?
7. Logic quyết định có test được không cần mock DB/HTTP/đồng hồ không?
8. Có abstraction mới nào chỉ có một caller, hoặc hàm chung nào vừa bị thêm flag để “vừa” một caller mới không?

Tóm tắt

Tóm tắt

• “Clean” = rẻ để sửa, an toàn để sửa, dễ review; quy tắc nào không phục vụ ba điều này thì bỏ.
• Characterization test trước, refactor sau; commit refactor không đổi test, commit fix: đổi hành vi đi riêng.
• Guard clause, không flag argument, parameter object, hằng số có đơn vị: rẻ, áp dụng ngay.
• Lõi thuần, side effect ở rìa: test hàng nghìn case không mock.
• Lỗi dự kiến là kết quả có kiểu; lỗi hạ tầng là exception có context và cause; không bao giờ nuốt lỗi.
• Trùng lặp rẻ hơn abstraction sai; chờ lần thứ ba.

Tiếp theo: Refactor an toàn