🧠 Think Like a Programmer #9 — Chương 8: Tư duy như một lập trình viên — Master Plan của riêng bạn

Ảnh: Brett Jordan — Pexels

Mở đầu

Vậy là mình đã cùng mấy bạn đi qua 7 chương của cuốn "Think Like a Programmer" — từ những chiến lược giải quyết vấn đề tổng quát, rèn tư duy với pure puzzles, khám phá sức mạnh của array, vật lộn với con trỏ và bộ nhớ động, thiết kế class, giải mã đệ quy, cho tới tái sử dụng code một cách thông minh.

Và giờ, tới chương cuối cùng: Chương 8 — Thinking Like a Programmer.

Đúng vậy, chương này có tên trùng với tựa đề cuốn sách. Và nó không phải ngẫu nhiên. Spraul dành toàn bộ chương cuối để tổng kết lại hành trình — không phải bằng một bài giảng khô khan, mà bằng thứ có giá trị nhất mà một người thầy có thể tặng học trò: một master plan để tự mình giải quyết bất kỳ vấn đề nào.

Tư duy như một lập trình viên — Chương cuối

Nếu tóm tắt Chương 8 trong một câu, thì đó là: "You should construct a master plan that maximizes your strengths and minimizes your weaknesses."

Nghe có vẻ đơn giản — nhưng thực ra rất sâu. Suốt 7 chương trước, Spraul đã dạy chúng ta kỹ thuật: cách chia nhỏ vấn đề, cách dùng array/con trỏ/class/recursion, cách tái sử dụng code. Nhưng đến chương này, ổng nói rằng kỹ thuật thôi chưa đủ — quan trọng hơn là bạn phải hiểu chính mình.

1. Tự nhận thức — điều mà ít sách dạy lập trình dám làm

Spraul mở đầu chương bằng một phép ẩn dụ rất hay: bạn là một huấn luyện viên bóng bầu dục, chuẩn bị cho trận đấu. Hai quarterback đều tài năng, nhưng điểm mạnh/yếu khác nhau. Cùng một game plan, áp cho người A thì thắng, cho người B thì thua.

Với lập trình cũng vậy. Không có "cách đúng duy nhất" để giải quyết vấn đề. Có cách đúng với bạn, dựa trên điểm mạnh và điểm yếu của bạn.

Spraul phân chia điểm yếu làm hai loại:

Coding Weaknesses — lỗi khi viết code

Đây là những lỗi lặp đi lặp lại khi bạn gõ code. Ví dụ kinh điển: nhầm = với == trong C++. Spraul kể câu chuyện về một lập trình viên chán ngấy vì mắc lỗi này — và ổng đã tự "cai" bằng cách luôn viết literal ở bên trái: if (1 == number) thay vì if (number == 1). Nếu lỡ viết if (1 = number), compiler sẽ báo lỗi ngay — không còn là semantic error nữa.

Bài học lớn hơn: đừng chỉ sửa lỗi — hãy hỏi "tại sao mình mắc lỗi này". Spraul đưa ra ví dụ về hàm tính trung bình các số dương — nếu không có số dương nào, sẽ bị chia cho 0. Sửa lỗi đó dễ. Nhưng nếu bạn tự hỏi "nguyên tắc chung nào bị vi phạm?", bạn sẽ nhận ra: luôn kiểm tra special cases (dữ liệu rỗng, giá trị ngoài khoảng, v.v.).

Đó mới là học.

Design Weaknesses — lỗi khi thiết kế

Spraul liệt kê một số điểm yếu phổ biến ở cấp độ thiết kế — và mình cá là ai cũng thấy mình trong đó:

• Convoluted designs — thiết kế rối rắm, quá nhiều bước, quá nhiều thành phần
• Can't get started — trì hoãn, không biết bắt đầu từ đâu
• Fails to test — không thích test code, chỉ test các trường hợp cơ bản
• Overconfident — tự tin quá mức, chọn giải pháp phức tạp không cần thiết, ước lượng thời gian sai
• Weak area — một mảng kiến thức cụ thể (con trỏ, đệ quy, class) mà bạn yếu hơn hẳn

Cái hay là Spraul không chỉ chỉ ra điểm yếu — ổng còn đưa ra giải pháp cụ thể cho từng loại. "Can't get started"? Hãy dùng kỹ thuật reduce và divide từ Chương 1. "Fails to test"? Hãy biến testing thành một bước bắt buộc trong master plan của bạn, hoặc thử test-driven development.

🔑 Bài học: Điểm yếu không phải là bản án — nó chỉ là chướng ngại vật bạn cần biết để lách qua.

Ảnh: Lukas Blazek — Pexels

2. Biết điểm mạnh của mình — và tận dụng nó

Phần này mình thấy rất hay và... hiếm. Sách kỹ thuật thường chỉ nói về "cách sửa lỗi" — ít cuốn nào dám nói về "cách phát huy thế mạnh". Spraul thì có.

Các điểm mạnh ổng liệt kê:

• Eye for detail — thấy được special cases, test kỹ, code chậm mà chắc
• Fast learner — học nhanh, thích thử công nghệ mới
• Fast coder — gõ code nhanh, ít syntax error
• Never gives up — bền bỉ, không nản trước bug
• Super problem-solver — đọc đề đã hình dung ra hướng giải quyết
• Tinkerer — thích mày mò, thêm tính năng, refactor

Mỗi điểm mạnh nên được dùng để xây dựng master plan. "Fast coder"? Hãy thử rapid prototyping — viết nháp thật nhanh, rồi cải tiến dần. "Fast learner"? Hãy dành thời gian đầu mỗi dự án để học công nghệ mới. "Never gives up"? Hãy giải quyết phần khó nhất trước, vì bạn biết mình sẽ không bỏ cuộc.

🔑 Bài học: Master plan không chỉ tránh điểm yếu — nó còn tối ưu hoá điểm mạnh. Hãy dành càng nhiều thời gian càng tốt để làm điều bạn giỏi.

3. Master Plan của Spraul — một ví dụ thực tế

Spraul không chỉ nói suông. Ổng đưa ra master plan của chính mình:

"To fight my primary design weakness (over-designing), I will strictly limit my time spent in the design phase. After my initial analysis, I'll write a small test-bed program to try out new skills. To fight excessive eagerness, I'll create two versions: a crusty, anything-goes prototype and a polished version for delivery."

Đây là điểm mạnh của cuốn sách: Spraul không giả vờ hoàn hảo. Ổng thừa nhận mình thích thiết kế quá mức, thích code ngay mà không kiểm tra. Và ổng xây dựng master plan để bảo vệ mình khỏi chính mình.

Ý tưởng "hai phiên bản" (crusty prototype + polished delivery) đặc biệt thú vị. Thay vì cố gắng kiềm chế bản thân (dễ thất bại), hãy cho phép bản thân viết code "bẩn" ở một phiên bản riêng, và chỉ đưa code đã được review vào phiên bản chính thức.

🔑 Bài học: Master plan cá nhân không sao chép từ người khác được. Bạn phải tự xây dựng nó dựa trên hiểu biết về chính mình.

4. Cheating Hangman — case study lớn nhất cuốn sách

Phần còn lại của chương dành cho một bài toán lớn: viết chương trình chơi hangman ăn gian. Chương trình không chọn một từ cố định từ đầu — nó giữ một danh sách tất cả các từ có thể, và sau mỗi lần đoán, nó chọn phản hồi (đúng/sai) sao cho giữ lại nhiều từ nhất trong danh sách ứng viên.

Spraul dùng bài toán này để minh hoạ cách áp dụng master plan vào thực tế:

1. Có kế hoạch — giới hạn thời gian thiết kế, làm prototype trước
2. Bắt đầu với những gì đã biết — dùng list, string, array — những thứ quen thuộc
3. Reduce — làm phiên bản đơn giản trước (cố định độ dài từ, cố định số lần sai)
4. Divide — chia thành các operation nhỏ: đọc file, đếm từ không chứa chữ, tìm pattern phổ biến nhất, v.v.
5. Experiment — thử nghiệm với danh sách mẫu trên giấy để hiểu cách cheat

Cách Spraul giải quyết vấn đề này — từng bước một, viết code, test, rồi phân tích thiếu sót — là một minh hoạ tuyệt vời cho tất cả những gì cuốn sách đã dạy.

5. Học kỹ năng mới — không bao giờ ngừng

Cuối chương, Spraul dành thời gian để nói về việc học tập liên tục. Ổng đưa ra lời khuyên cho từng loại kỹ năng mới:

Học ngôn ngữ mới: Dành thời gian học trước khi viết production code. Dùng "what you know" — viết lại chương trình cũ bằng ngôn ngữ mới. Rồi tìm hiểu điểm khác biệt. Rồi nghiên cứu code của chuyên gia.

Học kỹ năng mới trong ngôn ngữ đã biết: Tìm những vấn đề không thể giải quyết thoả đáng với kỹ năng hiện tại. Ví dụ: chương trình chạy tốt với dữ liệu nhỏ — nếu dữ liệu lớn gấp 1000 lần thì sao? Nếu cần lưu trữ từ xa? Nếu nhiều người dùng đồng thời?

Học thư viện mới: Tạo một dự án test riêng, không quan trọng. Học theo cấp độ khó tăng dần. Nghiên cứu code của người dùng thành thạo thư viện đó.

Đi học: Lớp học chỉ là chất xúc tác — việc học thực sự xảy ra khi bạn ngồi trước máy tính. Hãy tận dụng lớp học để học nhiều hơn chương trình yêu cầu.

🔑 Bài học: Là lập trình viên, bạn không bao giờ "tới nơi". Con đường học tập là vô tận — nhưng bạn luôn có thể có kế hoạch cho nó.

6. Kết luận — "Are you thinking like a programmer yet?"

Spraul kết thúc cuốn sách bằng một câu hỏi: "Are you thinking like a programmer yet?"

Câu trả lời của ổng rất thực tế: nếu bạn đã giải các bài tập ở cuối mỗi chương — thì có. Nếu chưa — hãy quay lại giải chúng. Không có đường tắt.

Và một câu nói mà mình sẽ nhớ mãi: "If someone calls you a coder rather than a programmer, say that a well-trained bird could be taught to peck out code — you don't just write code, you use code to solve problems."

Ảnh: Alexandra — Pexels

Cảm nhận của mình

Vậy là hết một cuốn sách. 8 chương, hơn 200 trang, từ những bài toán đơn giản nhất (in hình với vòng lặp) đến cả một chương trình hangman ăn gian đồ sộ.

Mình muốn chia sẻ vài điều sau khi đọc xong cuốn này:

1. Đây không phải sách dạy C++. Nếu bạn đọc cuốn này để học C++, bạn sẽ thất vọng. Đây là sách dạy tư duy giải quyết vấn đề. Spraul dùng C++ làm phương tiện, nhưng tinh thần của cuốn sách áp dụng được cho mọi ngôn ngữ.

2. Phần master plan (Chương 8) là phần đáng đọc nhất. 7 chương đầu xây nền móng — kiến thức, kỹ thuật, pattern. Chương 8 là lúc bạn đứng trên nền móng đó và nhìn lại toàn cảnh. Mình đã highlight gần như cả chương.

3. Bài học lớn nhất mình rút ra: hiểu chính mình quan trọng hơn hiểu code. Bạn có thể biết tất cả syntax, tất cả design patterns, tất cả thuật toán — nhưng nếu không biết mình yếu ở đâu, mạnh ở đâu, bạn sẽ mãi loay hoay. Một master plan cá nhân — dù chỉ là một trang note — có giá trị hơn cả đống sách.

4. Ý tưởng "crusty prototype + polished version" — mình sẽ áp dụng ngay. Cho phép bản thân viết code "bẩn" để giải phóng sáng tạo, nhưng có một quy trình review trước khi đưa vào production. Điều này giải quyết được cả vấn đề "không dám bắt đầu" lẫn "code bừa bãi".

5. Đọc sách là chưa đủ. Câu cuối cùng của Spraul rất thẳng: "If you haven't solved many of the exercises, then go back and solve them." Mình đã giải được vài bài — nhưng chưa hết. Và mình biết mình sẽ quay lại.

Kết — Tạm biệt "Think Like a Programmer"

Cảm ơn mấy bạn đã đồng hành cùng mình qua 8 bài viết của series này. Viết về một cuốn sách và đọc nó là hai trải nghiệm hoàn toàn khác nhau — viết buộc mình phải suy ngẫm sâu hơn, tổ chức ý tưởng rõ hơn, và quan trọng nhất, nhớ lâu hơn.

Cuốn "Think Like a Programmer" của V. Anton Spraul là một trong những cuốn sách về tư duy lập trình hay nhất mình từng đọc. Nó không dạy bạn C++, Java hay Python — nó dạy bạn cách nghĩ. Và đó là kỹ năng không bao giờ lỗi thời.

"The real challenge of programming isn't learning a language's syntax — it's learning to creatively solve problems so you can build something great." — V. Anton Spraul

Nếu bạn là lập trình viên ở bất kỳ trình độ nào, mình đều recommend cuốn này. Đọc chậm, giải bài tập, và — như Spraul nói — think like a programmer. 🚀

📋 Phụ lục thuật ngữ
- Master plan — kế hoạch tổng thể cá nhân hoá, tối ưu điểm mạnh và giảm thiểu điểm yếu
- Coding weakness — điểm yếu ở cấp độ viết code (ví dụ: nhầm = với ==, fencepost error)
- Design weakness — điểm yếu ở cấp độ thiết kế (ví dụ: thiết kế rối, không biết bắt đầu)
- Fencepost error — lỗi "đếm cọc hàng rào": nhầm lẫn giữa số lượng phần tử và số khoảng trống
- Special case — trường hợp đặc biệt (dữ liệu rỗng, division by zero, ngoài khoảng)
- Rapid prototyping — phương pháp viết nhanh một phiên bản thô, rồi cải tiến dần
- Test-driven development (TDD) — viết test trước, viết code sau
- Crusty prototype — phiên bản nháp "có gì dùng nấy", cho phép code bẩn để thử nghiệm nhanh
- Restore point — ý tưởng tạo bản sao code trước khi chỉnh sửa lớn (dùng version control)
- Cross-training — học ngôn ngữ mới để cải thiện kỹ năng với ngôn ngữ cũ

Tags: #sách #thinklikeaprogrammer #problemsolving #softwareengineering #masterplan #career #learning