01 Clean code theo các bậc thầy
Tác giả hỏi nhiều lập trình viên kỳ cựu "code sạch là gì?". Mỗi người một góc nhìn, nhưng các ý gặp nhau ở: đơn giản, lộ ý định, không trùng lặp, làm một việc.
Clean code đọc như một áng văn xuôi hay (well-written prose).
Grady BoochBjarne Stroustrup
Thanh lịch & hiệu quả (elegant, efficient); logic trực diện để lỗi khó ẩn nấp, phụ thuộc tối thiểu, xử lý lỗi đầy đủ. "Clean code làm tốt một việc."
Grady Booch
Đơn giản & trực tiếp, đọc như văn xuôi hay; không bao giờ che giấu ý định người thiết kế, đầy các trừu tượng rõ ràng (crisp abstractions).
"Big" Dave Thomas
Người khác (không phải tác giả) đọc & cải tiến được; có unit & acceptance test; tên có nghĩa; một cách làm một việc; phụ thuộc tối thiểu.
Michael Feathers
Luôn trông như được viết bởi một người thực sự quan tâm (someone who cares); chẳng còn gì hiển nhiên để cải thiện thêm.
Ron Jeffries
Theo quy tắc code đơn giản của Kent Beck: chạy mọi test, không trùng lặp (no duplication), thể hiện rõ mọi ý tưởng, tối giản số thực thể.
Ward Cunningham
Mỗi hàm bạn đọc hóa ra đúng như bạn mong đợi; code đẹp khi nó làm ngôn ngữ trông như được thiết kế riêng cho bài toán.
Bốn sợi chỉ đỏ xuyên suốt mọi định nghĩa — và cũng là toàn bộ cuốn sách: không trùng lặp · làm một việc · biểu cảm (expressiveness) · các trừu tượng nhỏ.
02 Cái giá của một mớ hỗn độn
Ai cũng từng nhìn đống bừa mình vừa tạo ra rồi tự nhủ "để hôm khác dọn". Nhưng có một định luật phũ phàng — Định luật LeBlanc (LeBlanc's Law): Later equals never (để sau = không bao giờ). Khi code rối lên, mỗi thay đổi lại làm hỏng vài chỗ khác; không thay đổi nào còn là chuyện nhỏ.
Vòng xoáy "thêm người"
Năng suất tụt
Mỗi thay đổi phá vài phần khác; đội từng chạy nhanh nay bò như sên.
Quản lý thêm nhân sự
Phản ứng duy nhất có thể: tăng người với hy vọng tăng sản lượng.
Mớ hỗn độn lớn nhanh hơn
Người mới không hiểu thiết kế, không phân biệt thay đổi đúng/sai ý đồ → tạo thêm hỗn độn, đẩy năng suất về 0 nhanh hơn.
03 "Grand Redesign in the Sky"
Đến lúc đội ngũ nổi loạn, đòi viết lại từ đầu. Câu chuyện kinh điển này gần như luôn diễn ra theo cùng một kịch bản — và kết thúc cay đắng.
Đội nổi loạn, đòi redesign
Không thể tiếp tục trên đống code kinh tởm. Quản lý miễn cưỡng đồng ý "đại tu trên trời".
Lập "tiger team"
Chọn những người giỏi nhất làm dự án green-field; ai cũng muốn vào. Số còn lại phải nuôi hệ thống cũ.
Cuộc đua hai đội
Hệ mới phải làm được mọi thứ hệ cũ làm, lại phải đuổi theo các thay đổi liên tục trên hệ cũ. Quản lý chỉ thay khi hệ mới ngang bằng hệ cũ.
Kết cục (có khi 10 năm)
Khi xong, thành viên tiger team ban đầu đã rời đi; đội hiện tại lại đòi thiết kế lại vì hệ "mới" cũng đã thành một mớ hỗn độn.
Bài học: dành thời gian giữ code sạch không chỉ tiết kiệm chi phí — đó là vấn đề sống còn nghề nghiệp (professional survival). Viết lại từ đầu hiếm khi cứu được bạn.
04 Nghịch lý & thái độ nghề nghiệp
Vì sao code tốt nhanh chóng mục thành code tồi? Ta hay đổ lỗi: yêu cầu đổi, lịch quá gấp, sếp dốt, marketing vô dụng… Nhưng — lỗi không nằm ở các vì sao, mà ở chính chúng ta.
Nghịch lý cơ bản (the primal conundrum)
Ai cũng biết mớ hỗn độn cũ làm mình chậm; vậy mà ai cũng chịu áp lực tạo mớ hỗn độn để kịp deadline. Người chuyên nghiệp thật sự biết vế sau là sai:
Cách duy nhất để kịp hạn — cách duy nhất để đi nhanh — là giữ code sạch nhất có thể, ở mọi thời điểm.
Diễn giải tinh thần Chương 1 · Clean CodePhép ẩn dụ bác sĩ: nếu bệnh nhân đòi bác sĩ bỏ rửa tay trước mổ cho nhanh, bác sĩ phải từ chối — vì hiểu rủi ro nhiễm trùng hơn bệnh nhân. Lập trình viên bẻ cong theo ý sếp (người không hiểu rủi ro của mớ hỗn độn) cũng thiếu chuyên nghiệp y như vậy.
Đọc : Viết > 10 : 1
Ta liên tục đọc lại code cũ để viết code mới. Vì tỷ lệ này quá cao, làm code dễ đọc thực ra khiến việc viết nhanh hơn — không có lối thoát khỏi logic này.
Chúng ta là tác giả
Trường @author nói ta là tác giả — mà tác giả thì có độc giả. Bạn có trách nhiệm giao tiếp tốt với những người đọc sẽ phán xét nỗ lực của bạn.
05 Quy tắc Hướng đạo (Boy Scout Rule)
Viết code tốt thôi chưa đủ — phải giữ nó sạch theo thời gian. Hội Hướng đạo Mỹ có một quy tắc đơn giản ta mượn được cho nghề:
Hãy rời khỏi khu trại sạch hơn lúc bạn mới đến.
The Boy Scout RuleNghĩa là: mỗi lần check-in, để code sạch hơn một chút so với lúc check-out — thì code sẽ không thể nào mục đi. Việc dọn không cần lớn; chương sách gợi ý đúng bốn việc nhỏ:
Đổi một tên biến cho tốt hơn
Một cái tên rõ nghĩa hơn là một bước dọn dẹp hợp lệ.
Chia nhỏ một hàm hơi dài
Tách một hàm quá lớn thành các phần nhỏ làm-một-việc.
Bỏ một chút trùng lặp
Mỗi lần lặp lại một ý là dấu hiệu một trừu tượng còn thiếu.
Dọn một điều kiện phức
Đặt tên cho điều kiện rối để câu lệnh tự kể ý định.
Một lần dọn trại, gói gọn cả bốn việc
RAG Trong hệ Hỏi–đáp tài liệu, đoạn lọc chunk theo độ liên quan là nơi quen "để sau dọn". Áp đúng bốn việc nhỏ ở trên cho một lần check-in:
def proc(d): # tên mơ hồ
r = []
for x in d: # gộp nhiều việc, ngưỡng 0.7 lặp lại
if x["s"] != None and x["s"] >= 0.7 and x["s"] <= 1:
r.append(x)
return r
RELEVANCE_THRESHOLD = 0.7 # hằng có tên
def keep_relevant(chunks): # tên rõ; hàm nhỏ
return [c for c in chunks if is_relevant(c)]
def is_relevant(chunk): # điều kiện phức → 1 hàm tự kể ý
return RELEVANCE_THRESHOLD <= chunk.score <= 1
Vì sao: đổi tên (proc/d/r → keep_relevant/chunks), chia nhỏ hàm, đặt tên hằng cho ngưỡng, và gói điều kiện phức thành is_relevant — đúng bốn việc dọn nhỏ Chương 1 gợi ý, làm trong một lần check-in.
06 Ghi nhớ nhanh
Clean code đọc như văn xuôi hay — đơn giản, lộ ý định, làm một việc, không trùng lặp.
Later equals never. Mớ hỗn độn kéo năng suất tiệm cận 0; thêm người chỉ làm nhanh hơn.
Viết lại từ đầu hiếm khi cứu được. Giữ code sạch là vấn đề sống còn nghề nghiệp.
Cách duy nhất để đi nhanh là đi cho sạch. Bạn là tác giả — và đọc:viết > 10:1.
Boy Scout Rule: để code sạch hơn lúc bạn nhận — mỗi lần một chút.