Think Like a Programmer: Introduction — Tư duy khác biệt giữa học cú pháp và giải quyết vấn đề
📘 Think Like a Programmer: Introduction — Tư duy khác biệt giữa học cú pháp và giải quyết vấn đề
Ảnh: Alexandra — Pexels
Mở đầu
Chào mấy bạn, mình là Phong đây! 👋
Hôm nay mình bắt đầu một series mới trên blog: "Think Like a Programmer" của tác giả V. Anton Spraul. Đây là cuốn sách mà mình nghĩ bất kỳ lập trình viên nào — từ mới vào nghề tới đã có kinh nghiệm — đều nên đọc ít nhất một lần.
Không giống như mấy cuốn sách dạy lập trình thông thường chỉ chăm chăm vào cú pháp, câu lệnh, hay framework này nọ, cuốn này nói về một thứ sâu hơn nhiều: cách tư duy để giải quyết vấn đề. Nghe có vẻ trừu tượng ha? Nhưng mình cam đoan là sau khi đọc xong, mấy bạn sẽ nhìn nhận việc code hoàn toàn khác đó.
Mình sẽ viết cảm nhận từng chương một, mỗi ngày một bài. Nếu mấy bạn cũng đang muốn cải thiện kỹ năng problem solving của mình, hãy theo dõi series này nha!
Ảnh: Lukas Blazek — Pexels
Introduction — Lời mở đầu sâu sắc
Ngay từ những dòng đầu tiên của lời mở đầu, tác giả đã đặt ra một vấn đề rất thật: "Programming may be so mechanical in nature that your creativity is never tested." Lập trình có thể chỉ là công việc cơ học — gõ code theo mẫu có sẵn — nhưng đến một lúc nào đó, sự sáng tạo mới chính là thứ quyết định bạn có phải một lập trình viên giỏi hay không.
Spraul so sánh việc học lập trình với hai dạng hoạt động của não bộ:
- Học cú pháp, đọc code, nhớ API — là hoạt động "não trái" (phân tích, logic)
- Viết chương trình gốc, giải quyết vấn đề mới — là hoạt động "não phải" (sáng tạo)
Tác giả dùng một hình ảnh cực kỳ dễ hiểu: hãy tưởng tượng một cành cây rơi vào máng xối nước mưa trên mái nhà, mà cái thang của bạn không đủ dài để với tới. Bạn phải làm gì? Kéo dài thang? Kiếm đồ để khều cành cây? Leo lên từ chỗ khác? Đó chính là problem solving — và khi bạn thiết kế một chương trình, tư duy của bạn cũng y hệt như vậy.
Điểm nhấn: "Kobayashi Maru"
Một trong những khái niệm thú vị nhất của chương này là Kobayashi Maru — mượn từ phim Star Trek II. Kobayashi Maru là một bài tập mô phỏng trong Starfleet Academy, nơi các học viên phải đối mặt với một tình huống không thể thắng: giải cứu con tàu thương binh Kobayashi Maru đồng nghĩa với việc lao vào trận chiến chắc chắn thua. Captain Kirk đã "thắng" bằng cách sửa code của bài mô phỏng — nghĩa là ông không giải quyết vấn đề, mà né tránh nó.
Trong lập trình, Kobayashi Maru là chương trình chạy ra kết quả đúng nhưng vi phạm một hoặc nhiều ràng buộc (constraints) của bài toán. Ví dụ: "Bài toán yêu cầu xử lý tối đa 1000 records, mà code chỉ chạy được 100 thì hết bộ nhớ. Ủa nhưng test với 5 records thì vẫn pass mà!" — Đó là một Kobayashi Maru điển hình.
Tác giả cảnh báo: rất nhiều lập trình viên mới (và cả cũ) vô tình hoặc cố ý tạo ra Kobayashi Maru. Có thể là do không biết cách đáp ứng ràng buộc, có thể là do chạy deadline, hoặc tệ nhất là nhờ người khác code dùm. Dù lý do gì, đây là cạm bẫy phải luôn tránh.
Học nấu ăn hay học theo cookbook?
Một ẩn dụ nữa mình thấy cực kỳ sâu sắc: sách dạy lập trình kiểu "cookbook". Đầu bếp giỏi không cần cookbook — họ hiểu nguyên liệu, phương pháp chế biến và biết kết hợp chúng để tạo ra món ăn tuyệt vời. Tương tự, lập trình viên giỏi hiểu cú pháp, thuật toán, frameworks và biết cách kết hợp chúng. Cho họ một căn bếp đầy đủ (môi trường lập trình) và một danh sách yêu cầu, họ sẽ làm được những điều tuyệt vời.
Vấn đề là: phần lớn sách hiện tại không dạy cách kết hợp — họ chỉ dạy công thức. Và học theo công thức thì không bao giờ trở thành đầu bếp thực thụ được.
Ảnh: ThisIsEngineering — Pexels
Cảm nhận của mình
Phải nói thật là đọc xong Introduction của cuốn này, mình thấy hơi... "đau" một chút. Kiểu như ống kính soi đúng vào cái điểm yếu của mình vậy. Mình nhận ra rất nhiều lần trong quá trình học code và làm việc, mình từng rơi vào cái bẫy Kobayashi Maru mà không hề hay biết.
Nhớ hồi mới học, mình từng viết một cái script xử lý dữ liệu cho công ty — chạy ngon lành với file test trong 2 ngày. Rồi đưa lên production, 10 phút sau server crash vì memory leak. Hoá ra cái code mình viết chỉ xử lý được tối đa 500 records, còn thực tế có cả trăm ngàn. Lúc đó mình đâu biết đó gọi là Kobayashi Maru — mình chỉ biết tối hôm đó thức tới 3h sáng sửa bug. 😅
Cái mình tâm đắc nhất là cách Spraul nói về problem solving như một kỹ năng có thể học được. Nhiều bạn cứ nghĩ "người ta giải được bài khó vì người ta thông minh bẩm sinh" — nhưng thực ra không phải vậy. Problem solving cũng giống như chơi nhạc, vẽ tranh, hay viết lách: nó là một kỹ năng sáng tạo có thể rèn luyện một cách có hệ thống.
Trong hơn 10 năm làm nghề, mình thấy một sự thật là: những lập trình viên giỏi nhất thường không phải là người thuộc nhiều syntax nhất, mà là người biết cách giải quyết vấn đề nhất. Họ có thể không biết hết mọi thứ về ngôn ngữ họ đang dùng, nhưng họ biết cách suy nghĩ, cách chia nhỏ vấn đề, cách tiếp cận từ nhiều hướng — và trên hết, họ biết cách đáp ứng các ràng buộc.
Cuốn sách chọn C++ làm ngôn ngữ chính — và tác giả giải thích rất hay: "C++ là lập trình không có bánh tập (training wheels)". Học problem solving trên C++ rồi thì chuyển qua ngôn ngữ nào cũng dễ. Mình cũng đồng ý, dù mình không phải dân C++ chuyên nghiệp. Nhưng cái tư duy thì vẫn vậy, dù bạn code Python, JavaScript, hay Go.
Kết
Introduction đã đặt nền móng rất tốt cho toàn bộ cuốn sách: problem solving là một kỹ năng có thể học được, và cuốn sách này sẽ dạy bạn cách học nó một cách có hệ thống. Spraul không hứa sẽ cho bạn công thức để giải mọi bài toán — mà hứa sẽ giúp bạn phát triển khả năng tự tìm ra giải pháp.
Câu nói cuối cùng của Introduction mà mình thấy rất tâm đắc:
"My goal is for you and every other reader of this book to learn to systematically approach every programming task and to have the confidence that you will ultimately solve a given problem."
Hẹn mấy bạn ở bài tiếp theo — Chương 1: Strategies for Problem Solving — nơi chúng ta sẽ bắt đầu thực sự học các chiến lược để giải quyết vấn đề trong lập trình! 🚀
Tags: #sách #thinklikeaprogrammer #problemsolving #softwareengineering #lậptrình