Trong bài review Clean Architecture tuần trước, mình có nhắc đến bộ ba tư duy — hệ thống — kiến trúc mà mọi backend engineer nên đọc. Hôm nay mình sẽ bắt đầu từ cuốn đầu tiên trong bộ ba đó: The Pragmatic Programmer: Your Journey to Mastery (bản 20th Anniversary Edition).
Cuốn sách này ra mắt lần đầu năm 1999, ngay trước thời điểm bong bóng dot-com vỡ. Vậy mà hơn 25 năm sau, nó vẫn được coi là một trong những cuốn sách lập trình có ảnh hưởng nhất mọi thời đại. David Thomas và Andrew Hunt — cũng chính là hai tác giả của Agile Manifesto — đã viết một cuốn sách không dạy bạn một ngôn ngữ hay framework cụ thể, mà dạy bạn cách suy nghĩ như một lập trình viên chuyên nghiệp.
Cuốn sách này nói về điều gì?
Không giống những cuốn sách kỹ thuật khác đi sâu vào từng công nghệ, The Pragmatic Programmer là tập hợp 100 mẹo thực hành (tips) xuyên suốt 9 chương, bao trùm từ quy trình làm việc cá nhân đến thiết kế phần mềm và quản lý dự án.
Điểm đặc biệt là các mẹo này không hề lỗi thời. Dù công nghệ thay đổi, nhưng triết lý về tính chủ động, trách nhiệm với code, và đầu tư vào bản thân vẫn còn nguyên giá trị.
Những nguyên tắc mình tâm đắc nhất
DRY — Don’t Repeat Yourself
Nguyên tắc nổi tiếng nhất từ cuốn sách này, nhưng ít người hiểu đúng. DRY không chỉ là “đừng copy-paste code”. Nó có nghĩa là mỗi piece of knowledge trong hệ thống phải có một và chỉ một đại diện duy nhất. Điều này bao gồm cả kiến thức trong database schema, API contract, documentation, deployment script, và business logic.
Mình từng làm một dự án mà cùng một business rule — “thuế VAT là 10%” — nằm ở 3 chỗ: frontend validation, backend business logic, và stored procedure. Khi luật thuế thay đổi, team mất gần 2 ngày để tìm hết các chỗ cần sửa. Đó là hậu quả của việc vi phạm DRY ở cấp độ tri thức, chứ không phải code.
Trực giao (Orthogonality)
Đây là khái niệm mình thấy cực kỳ giá trị. Hai module được gọi là trực giao nếu thay đổi một cái không ảnh hưởng đến cái kia. Hệ thống có tính trực giao cao thì dễ thay đổi, dễ test, và dễ deploy.
Một ví dụ đơn giản: tách biệt business logic khỏi giao diện người dùng. Nếu bạn đổi từ REST sang GraphQL, code xử lý nghiệp vụ không cần thay đổi — đó là trực giao. Còn nếu mỗi lần thay đổi UI bạn phải sửa cả backend, thì bạn đang gặp vấn đề.
Tracer Bullet vs Prototype
Một trong những mẹo thú vị nhất của cuốn sách là tracer bullet development — lấy ý tưởng từ cách quân đội bắn đạn vạch đường: thay vì thiết kế chi tiết toàn bộ hệ thống rồi mới code, hãy xây dựng một luồng hoàn chỉnh từ đầu đến cuối ngay từ những ngày đầu, dù nó còn sơ sài. Điều này giúp bạn phát hiện sớm các vấn đề về tích hợp và đưa ra feedback nhanh hơn.
Tracer bullet khác với prototype ở chỗ: prototype là thử nghiệm rồi bỏ, còn tracer bullet là code thật — nó sẽ tiến hóa thành sản phẩm cuối cùng.
Chịu trách nhiệm
Mẹo số 7 trong sách: “Provide Options, Don’t Make Lame Excuses”. Khi có sự cố, đừng đổ lỗi cho công cụ hay deadline. Hãy đưa ra giải pháp. Nghe có vẻ đơn giản, nhưng đây là điều phân biệt một kỹ sư chuyên nghiệp với một người chỉ biết gõ code.
Thomas và Hunt cũng nói về việc đầu tư vào knowledge portfolio của bạn — giống như đầu tư tài chính: đa dạng hóa, đầu tư đều đặn mỗi ngày, và cân bằng giữa rủi ro và lợi nhuận. Học một ngôn ngữ mới mỗi năm, đọc sách kỹ thuật, theo dõi các công nghệ mới.
Cảm nhận của mình
Khác với DDIA (dạy bạn cái gì) hay Clean Architecture (dạy bạn tổ chức thế nào), The Pragmatic Programmer dạy bạn tư duy — thứ quan trọng hơn bất kỳ ngôn ngữ hay framework nào.
Điểm yếu duy nhất của bản 20th Anniversary Edition là một số ví dụ về công nghệ cũ (UML, CORBA, hay vài tool cụ thể) có thể khiến bạn đọc lướt qua. Nhưng phần cốt lõi về tư duy và triết lý thì vẫn hoàn toàn không lỗi thời.
Mình nghĩ đây là cuốn sách dành cho:
- Developer mới muốn xây dựng thói quen tốt ngay từ đầu
- Developer 3-5 năm kinh nghiệm đang tìm cách nâng tầm
- Bất kỳ ai muốn hiểu “kỹ sư phần mềm thực thụ” khác gì “thợ code”
“The greatest of all weaknesses is the fear of appearing weak.” — một trong những câu mình tâm đắc nhất, nhắc rằng thừa nhận không biết và sẵn sàng học hỏi là dấu hiệu của một lập trình viên trưởng thành.
Chấm điểm: 9/10 — sách xứng đáng nằm trên bàn của mọi lập trình viên, đọc lại mỗi năm một lần để nhắc mình về những nguyên tắc cơ bản.
Bài review sách liên quan