6 sai lầm thường gặp khi giải quyết bài toán lập trình (và cách khắc phục)

Đó là một cảm giác ức chế vô cùng quen thuộc: nhìn chằm chằm vào màn hình hàng giờ liền, cố gắng săn lùng một lỗi (bug) dường như cứ biến mất ngay khi bạn vừa chạm tới. Hoặc khi bạn vừa xây dựng xong một tính năng cực kỳ thú vị, để rồi nhận ra rằng nó lại làm hỏng một phần khác, cứ như thể đang trêu ngươi bạn vậy.

Chúng ta thường tự coi mình là những người giải quyết vấn đề một cách logic. Nhưng ngay khi một thuật toán thất bại hoặc một ứng dụng bị sập, sự logic đó dường như bay biến mất. Vấn đề thường không nằm ở việc bạn thiếu kỹ năng công nghệ. Nó tinh vi hơn thế nhiều. Bộ não của chúng ta liên tục rơi vào những thói quen xấu giống nhau mà chúng ta hiếm khi nhận ra.

Sau khi xây dựng các bài học cho hàng triệu học viên trên Coddy, chúng tôi liên tục thấy một khuôn mẫu lặp đi lặp lại. Những điểm giống nhau khiến mọi người bối rối. Những thói quen giống nhau dần xuất hiện. Và hầu như tất cả đều bắt nguồn từ một điều duy nhất:

bộ não của bạn đang ưu tiên tốc độ hơn là sự thấu hiểu.

Vì vậy, hãy cùng phân tích sáu sai lầm phổ biến mà chúng ta thường mắc phải khi giải quyết các vấn đề lập trình, và cách xây dựng tư duy lập trình sắc bén hơn. Bạn đã sẵn sàng chưa? Hãy cùng bắt đầu nào!

1. Vội vàng viết code trước khi hiểu rõ vấn đề

Tất cả chúng ta đều muốn làm việc thật nhanh và hiệu quả. Vì vậy, ngay khi một lỗi xuất hiện, các ngón tay của chúng ta bắt đầu gõ liên tục trên bàn phím. Một bài kiểm tra (test) bị thất bại? Chúng ta tinh chỉnh một tham số, thay đổi một câu lệnh if, hoặc sao chép một giải pháp từ Stack Overflow rồi dán vào với hy vọng rằng nó sẽ hoạt động.

Vấn đề ở đây là, khi bạn viết code mà không biết tại sao lỗi lại xảy ra, bạn đang vô tình thêm nhiều thành phần phức tạp hơn vào một mớ hỗn độn mà bản thân chưa hiểu rõ. Bạn không hề giải quyết được lỗi, bạn chỉ đang che giấu nó dưới những lỗi mới mà thôi.

Tốc độ thực sự đến từ việc biết dừng lại đúng lúc. Trước khi gõ bất kỳ dòng code nào, hãy xác định rõ ba điều: đầu vào là gì, đầu ra mong muốn là gì, và điều gì xảy ra ở giữa.

2. Tự trách bản thân thay vì cải thiện hệ thống

Một lỗi chính tả. Một chỉ mục (index) bị sai. Một biến (variable) đặt sai tên âm thầm làm hỏng mọi thứ. Khi điều này xảy ra, chúng ta rất dễ thở dài và tự trách: "Thôi xong, lỗi của mình, mình bất cẩn quá."

Nhưng tại sao một sơ suất nhỏ như vậy ngay từ đầu lại có thể gây ra thiệt hại lớn đến thế?

Thay vì đổ lỗi, các đội ngũ kỹ sư giỏi nhất thường tự hỏi điều gì đã khiến sai lầm đó lọt qua mà không bị phát hiện. Bạn cũng có thể làm điều tương tự với các dự án của riêng mình, bất kể quy mô lớn hay nhỏ. Nếu một giá trị sai có thể làm sập toàn bộ tập lệnh (script) của bạn, thì giải pháp không phải là "lần sau cố gắng hơn". Giải pháp là xây dựng một hệ thống vững chắc hơn, với các bước kiểm tra nhỏ để phát hiện lỗi trước khi nó lan rộng. Vì vậy, hãy ngừng đổ lỗi cho bản thân và bắt đầu viết code an toàn hơn.

3. Cho rằng chỉ có duy nhất một lỗi

Những thảm họa lập trình lớn hiếm khi đến từ một sai lầm duy nhất. Thông thường, một vài lỗi nhỏ, ẩn giấu sẽ xuất hiện cùng một lúc để tạo ra một vấn đề đau đầu thực sự.

Trong kiểm thử (testing), thậm chí có một thuật ngữ cho hiện tượng này: các lỗi thường có xu hướng tập trung lại với nhau. Nơi nào bạn tìm thấy một lỗi, những lỗi khác thường cũng đang ẩn nấp ngay gần đó.

Vì vậy, nếu bạn chỉ săn lùng một nguyên nhân duy nhất, bạn sẽ bỏ lỡ bức tranh toàn cảnh. Khi bạn sửa xong một lỗi và thông báo lỗi biến mất, đừng vội ăn mừng rồi bỏ đi ngay. Hãy xem xét xung quanh xem sao. Triệu chứng đó biến mất là vì bạn đã khắc phục được nguyên nhân gốc rễ, hay vì bạn đã vô tình che giấu nó? Hãy kiểm tra thêm một vài điểm liên quan trước khi coi như đã hoàn thành.

4. Nhầm lẫn giữa việc mô tả và phân tích thực tế

"Kết nối cơ sở dữ liệu đã quá thời gian chờ (timeout)."

Câu nói đó nghe có vẻ giống như một câu trả lời. Nhưng thực tế không phải vậy. Đó chỉ là một lời mô tả. Nó cho bạn biết điều gì đã xảy ra, chứ không phải tại sao nó lại xảy ra. Và khi bạn nhầm lẫn giữa hai điều này, bạn sẽ đưa ra những giải pháp tạm thời, như tăng thời gian chờ từ 30 giây lên 60 giây rồi coi như xong việc. (Một sai lầm kinh điển!)

Có một thói quen đơn giản giúp khắc phục điều này, gọi là phương pháp 5 câu hỏi Tại sao (5 Whys). Bạn chỉ cần liên tục hỏi "tại sao" cho đến khi tìm ra nguyên nhân thực sự. Tại sao kết nối lại quá thời gian chờ? Vì truy vấn (query) quá chậm. Tại sao truy vấn lại chậm? Và cứ tiếp tục như thế. Mỗi câu hỏi "tại sao" sẽ đưa bạn tiến gần hơn một bước đến vấn đề thực sự cần khắc phục, thay vì chỉ dừng lại ở hiện tượng đầu tiên mà bạn vô tình nhận thấy.

Mô tả một vấn đề mới chỉ là vạch xuất phát. Việc đào sâu tìm hiểu tại sao nó lại hoạt động như vậy mới là nơi mang lại sự ổn định thực sự cho hệ thống.

5. Lập trình trong sự cô lập hoàn toàn

Lập trình đôi khi giống như một môn thể thao độc diễn, vì vậy khi gặp bế tắc, bản năng của chúng ta là cúi đầu và cố gắng tự mình vượt qua. Nhiều giờ trôi qua, nhưng khó khăn vẫn nằm im ở đó.

Việc cố gắng giải quyết một vấn đề hóc búa mà không có bất kỳ sự trợ giúp nào từ bên ngoài thường dẫn đến những kết quả tệ hại hơn cả sự chậm trễ. Nó dẫn đến những giải pháp quá phức tạp, rối rắm và sẽ là một cơn ác mộng nếu muốn sửa lại sau này. Một góc nhìn mới mẻ, một cuộc trò chuyện ngắn về cách tiếp cận của bạn, hoặc thậm chí chỉ một gợi ý nhỏ cũng có thể cứu bạn khỏi việc loay hoay vòng quanh suốt cả buổi chiều.

6. Giải quyết cùng một vấn đề lặp đi lặp lại

Nếu tuần nào bạn cũng phải sửa cùng một loại lỗi, thì lỗi đó không còn là vấn đề thực sự nữa. Thói quen của bạn mới là vấn đề.

Khi bạn không ghi lại các trường hợp đặc biệt (edge case) từng khiến mình gặp rắc rối, hoặc không chuyển đổi các logic lặp đi lặp lại lộn xộn thành một khuôn mẫu sạch sẽ, có thể tái sử dụng, bạn đang lãng phí năng lượng để giải quyết những vấn đề cũ thay vì xây dựng những thứ mới. Điều đó thật mệt mỏi, và tin vui là bạn hoàn toàn có thể tránh được nó.

Cách giải quyết là thực hành có chủ đích. Việc biến những gì bạn biết trên lý thuyết thành phản xạ tự nhiên của các ngón tay là điều giúp giải pháp của bạn có giá trị lâu dài. Một khi bạn đã thực sự làm chủ một khuôn mẫu, bạn sẽ không còn phải tốn thời gian sửa đi sửa lại nó nữa.

Xây dựng thói quen giải quyết vấn đề tốt hơn cùng Coddy

Đọc về các sai lầm khi lập trình là một bước khởi đầu tuyệt vời. Thực sự đấy! Nhưng bạn không thể thực sự học được những điều này nếu chỉ dừng lại ở việc đọc.

Bạn chỉ thực sự học được khi bắt tay vào làm.

Bạn không thể xây dựng phản xạ tự nhiên nếu chỉ nhìn chằm chằm vào những dòng chữ tĩnh lặng. Bạn phải tự mình viết code, tự làm hỏng và tự mình sửa chữa. Vòng lặp đó, khi được lặp đi lặp lại, chính là nơi sự tiến bộ thực sự diễn ra. Và đó cũng là lý do Coddy được tạo ra.

Chúng tôi muốn tạo ra một không gian nơi việc học lập trình giống như một cuộc phiêu lưu thú vị từng bước một. Cho dù bạn đang gõ dòng code đầu tiên hay đang thử sức với các thuật toán phức tạp hơn, luôn có một vị trí thoải mái dành cho bạn tại đây. Và bạn hoàn toàn có quyền lựa chọn lộ trình cho riêng mình!

Bạn không cần một hệ thống máy tính hoàn hảo hay một ngày cuối tuần rảnh rỗi để bắt đầu. Chỉ cần mang theo sự tò mò của bạn, học từng bài học nhỏ một, và quan sát cách bộ não giải quyết vấn đề của bạn bắt đầu thay đổi.

Hãy tham gia cùng chúng tôi trên Coddy, thử bài học tương tác đầu tiên của bạn, và cùng nhau xây dựng những điều tuyệt vời nhé!