Think Like a Programmer #1: Strategies for Problem Solving — Bài Học Đầu Tiên Về Tư Duy Giải Quyết Vấn Đề

Chào mấy bạn, hôm nay mình bắt đầu một series mới mà mình khá háo hức: "Think Like a Programmer" của tác giả V. Anton Spraul.

Cuốn sách này không dạy bạn một ngôn ngữ lập trình cụ thể nào. Nó không phải là một cuốn "sách giáo khoa" khô khan với đầy cú pháp và thuật toán. Thay vào đó, nó dạy bạn thứ quan trọng nhất mà mọi lập trình viên đều cần nhưng ít ai được dạy: cách suy nghĩ để giải quyết vấn đề.

Tác giả V. Anton Spraul đã giảng dạy lập trình hơn 15 năm. Ông nhận ra rằng sinh viên của mình không thiếu kiến thức về cú pháp — họ thiếu phương pháp để tiếp cận một vấn đề khi đứng trước nó. Và cuốn sách này ra đời từ chính khoảng trống đó.

Ảnh: Lukas Blazek — Pexels

Chương 1: Strategies for Problem Solving

Chương mở đầu đặt nền móng cho toàn bộ cuốn sách. Spraul bắt đầu bằng một câu chuyện rất đời thường: chiếc Honda Civic 1997 của bạn bốc khói xanh, nổ không đều, hao xăng. Bạn kể với bạn bè, và họ bảo "bán đi mua xe mới đi!" — đó có phải là giải quyết vấn đề không?

Câu trả lời là không. Đó là trốn tránh vấn đề, là chọn một lối tắt để không phải đối mặt với khó khăn thực sự. Giải quyết vấn đề thật sự là phải chẩn đoán, phải tìm ra nguyên nhân gốc rễ, phải sửa chữa tận gốc.

Và với lập trình cũng vậy. Quá nhiều lần chúng ta — mình cũng từng như vậy — thấy một cái bug, một bài toán khó, và phản ứng đầu tiên là viết đại code, thử sai, hoặc tìm cách "chữa cháy" tạm thời. Spraul nói: hãy luôn có một kế hoạch.

Chương này giới thiệu 8 chiến lược tổng quát để giải quyết vấn đề:

1. Luôn có một kế hoạch (Always Have a Plan)

Đây là quy tắc quan trọng nhất. Không có kế hoạch giống như lái xe trong sương mù mà không có bản đồ. Dù kế hoạch của bạn sau đó có thay đổi đi chăng nữa, chỉ riêng việc xây dựng kế hoạch đã buộc bạn phải hiểu rõ vấn đề, ràng buộc và các lựa chọn của mình.

2. Phát biểu lại vấn đề (Restate the Problem)

Giống như nhìn ngọn đồi từ mọi góc độ trước khi leo. Hãy thử mô tả vấn đề bằng nhiều cách khác nhau, dùng từ ngữ tổng quát hơn hoặc cụ thể hơn. Đôi khi chỉ cần thay đổi cách nhìn là lời giải hiện ra.

3. Chia nhỏ vấn đề (Divide the Problem)

Thay vì giải quyết mọi thứ cùng lúc, hãy bắt đầu với một phần rất nhỏ. Spraul nói rằng nếu chia vấn đề làm đôi, bạn sẽ nghĩ mỗi nửa nhẹ đi một nửa — nhưng thực tế còn nhẹ hơn thế nhiều.

4. Bắt đầu từ những gì bạn biết (Start with What You Know)

Làm những phần bạn chắc chắn có thể làm được trước, rồi từ đó mở rộng ra. Đây là cách giúp bạn tạo đà và có động lực tiếp tục.

5. Giảm vấn đề (Reduce the Problem)

Làm con số nhỏ hơn, giảm số bước. Ví dụ thay vì xử lý 100 phần tử, hãy xử lý 1 phần tử trước. Tìm cách đơn giản hóa bài toán nhưng vẫn giữ được bản chất của nó.

6. Tìm phép tương tự (Look for Analogies)

Bạn đã từng giải một bài toán tương tự trước đây chưa? Những lập trình viên giỏi có khả năng nhìn ra điểm tương đồng giữa các vấn đề dù chi tiết cụ thể khác nhau hoàn toàn.

7. Thử nghiệm (Experiment)

Ý thức thử nghiệm các giải pháp quy mô nhỏ để hiểu thêm về vấn đề. Đừng ngại thử và sai, nhưng hãy có chủ đích, đừng thử một cách ngẫu hứng.

8. Đừng nản chí (Don't Get Frustrated)

Có lẽ đây là kỹ năng bị xem nhẹ nhất. Khả năng kiểm soát cảm xúc khi đứng trước bài toán khó có thể quyết định bạn có giải được nó hay không. Frustration là kẻ thù lớn nhất của tư duy sáng tạo.

Ảnh: ThisIsEngineering — Pexels

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

Mình đọc cuốn sách này lần đầu khi còn là junior dev, và mình nhớ cảm giác click sau khi đọc xong Chương 1. Nó đơn giản đến mức mình muốn nói "biết rồi, khổ quá", nhưng đọc xong mới nhận ra: biết và làm là hai chuyện hoàn toàn khác nhau.

Có một lần, mình bị một con bug rất khó chịu. Một API trả về dữ liệu sai khi có một điều kiện nào đó, mà mình không tài nào reproduce được. Lúc đó kiểu dev trẻ, mình sửa đại mấy dòng, deploy lại — không được. Sửa tiếp — vẫn không được. Mất gần 3 tiếng ngồi mò mẫm.

Cuối cùng, mình dừng lại, viết ra giấy: cái mình biết chắc, cái mình không biết, cái mình cần kiểm tra. Mất 15 phút. Và mình tìm ra bug sau đó 10 phút. Đó chính xác là cái Spraul nói: hãy luôn có một kế hoạch. Cái kế hoạch "viết ra giấy" đó đã giúp mình restate vấn đề, divide nó và start with what I know.

Điều mình thích nhất ở chương này là nó không cố gắng dạy bạn mẹo hay trick. Nó dạy bạn thái độ với vấn đề. Và thái độ đó, một khi đã thấm, sẽ theo bạn suốt sự nghiệp.

Kết

Chương 1: Strategies for Problem Solving đặt nền móng vững chắc cho toàn bộ cuốn sách. 8 chiến lược không phải là công thức thần kỳ — chúng là những nguyên tắc cơ bản mà lập trình viên nào cũng có thể áp dụng ngay lập tức.

Spraul không hứa hẹn rằng đọc xong cuốn sách bạn sẽ giải được mọi bài toán. Nhưng ông hứa — và mình tin — rằng bạn sẽ có một framework để suy nghĩ, để tiếp cận vấn đề một cách có hệ thống hơn. Và điều đó đã làm nên giá trị của cuốn sách này.

Hẹn gặp lại mấy bạn ở chương sau!

— Phong