7 bước giải quyết vấn đề kỹ thuật dành cho developer: Không chỉ là kỹ năng, mà là tư duy sống còn

22 July, 2025

Lập trình không chỉ là việc “code cho chạy”. Thực tế, phần lớn thời gian của developer là để đọc, phân tích, fix bug, tối ưu, hoặc suy nghĩ cách giải quyết một vấn đề chưa từng gặp.

Và trong quá trình ấy, kỹ năng giải quyết vấn đề kỹ thuật chính là thứ tách biệt một coder bình thường với một developer trưởng thành.

Dưới đây là framework 7 bước mình thường áp dụng để xử lý những vấn đề kỹ thuật – từ nhỏ như lỗi API, đến lớn như cải tổ một module backend.

1. Xác định vấn đề rõ ràng

Một trong những sai lầm phổ biến nhất là đi fix một thứ mà mình chưa thực sự hiểu nó đang sai gì.

“Nếu tôi có một giờ để giải quyết một vấn đề, tôi sẽ dành 55 phút để nghĩ về vấn đề và 5 phút để nghĩ về giải pháp.” – Einstein

Việc cần làm:

Viết ra vấn đề bằng từ ngữ của bạn → giúp bạn hình dung rõ ràng.
Xác định phạm vi: lỗi xảy ra ở đâu? Khi nào? Với ai? Có lặp lại không?
Ghi nhận kỳ vọng của người dùng/business → đừng fix theo suy đoán của riêng bạn.

2. Tìm nguyên nhân gốc rễ – không chỉ chữa triệu chứng

Đừng vội “bấm nút restart server” khi chưa biết vì sao nó crash.

Hãy chọn một phương pháp phân tích phù hợp:

5 Whys: liên tục hỏi “Tại sao?” cho đến khi ra tận gốc.
Biểu đồ xương cá: phân loại nguyên nhân theo nhóm (logic, input, môi trường, database…).
Nguyên nhân – hệ quả: ghi lại các hệ quả để không bỏ sót ảnh hưởng lan tỏa.
Pareto 80/20: nếu hệ thống có 10 bug, đâu là 2 bug gây ra 80% rắc rối?

Ví dụ:

API lỗi 500?

Tại sao? → Hàm xử lý gặp null.
Tại sao null? → Không validate đầu vào.
Tại sao không validate? → Dev tin rằng input luôn đúng.
Tại sao tin như vậy? → Vì chưa có quy trình kiểm thử đầu vào...

3. Xây dựng giải pháp – đừng chỉ chọn hướng đầu tiên

Sau khi hiểu rõ nguyên nhân, đừng code vội.

Hãy brainstorm các hướng tiếp cận:

Fix nhanh để restore hệ thống? Hay thiết kế lại cho bền vững?
Có cần thông báo người dùng hoặc log lại lỗi để trace?
Có giải pháp nào đã được dùng ở nơi khác?

💡 Gợi ý: hãy viết thuật toán (pseudocode) hoặc vẽ flow xử lý bằng giấy trước. Việc này giúp bạn giảm lỗi logic và giao tiếp tốt hơn với teammate/QA/PM.

4. Viết code rõ ràng, có tổ chức

Viết code là bước triển khai kỹ thuật, nhưng đừng chỉ hướng đến “chạy được”.

Hãy:

Viết clean code: đặt tên rõ ràng, chia nhỏ hàm, tránh lặp logic.
Dự trù lỗi: null, undefined, lỗi API, timeout...
Ghi chú (nếu cần) bằng comment ngắn, đúng chỗ.

Code là để máy hiểu, nhưng đọc lại code 3 tháng sau mà bạn vẫn hiểu nổi – mới là lập trình có trách nhiệm.

5. Test và debug kỹ lưỡng

Test không chỉ là chạy thử vài input.

Bạn cần:

Test happy case & edge case.
Kiểm thử hiệu năng (nếu liên quan đến query, cache, xử lý số lượng lớn).
Ghi log thông minh để dễ debug về sau.

Và nhớ: Test không bao giờ là “việc của QA”, mà là việc của dev đầu tiên.

6. Đánh giá hiệu quả giải pháp

Sau khi fix xong, hãy pause lại và hỏi:

Giải pháp này có khắc phục đúng vấn đề chưa?
Có side-effect nào tiềm ẩn không?
Có thể tái sử dụng không?
Có cần lên kế hoạch refactor trong sprint tới không?

Tự retrospective sau mỗi lần fix bug là cách để bạn trở thành một dev tư duy sản phẩm, không chỉ “xử lý đầu việc”.

7. Ghi lại tài liệu – để đồng đội (và chính bạn) hiểu chuyện gì đã xảy ra

Nhiều dev né viết doc vì “lười”. Nhưng rồi đến khi chính bạn quên logic 6 tháng trước thì… cảm ơn mình đi.

Cách đơn giản để viết doc là dùng mô hình STAR:

Situation: Bối cảnh kỹ thuật
Task: Bạn cần xử lý gì
Action: Giải pháp đã thực hiện, công nghệ áp dụng
Result: Kết quả ra sao (số liệu, tốc độ, phản hồi người dùng...)

Tài liệu không cần dài, chỉ cần rõ ràng và dễ tìm lại.

Một số kỹ năng bổ trợ không thể thiếu

Giao tiếp rõ ràng: giải thích giải pháp cho PM, QA, đồng đội là điều cần thiết – không ai sống một mình trong team tech.
Làm việc nhóm tốt: cùng debug với đồng đội, nhận góp ý và phối hợp chặt chẽ với người khác là kỹ năng sống còn.
Tư duy logic & phản biện: đừng dễ dãi với suy đoán. Hãy hỏi “liệu còn cách nào tốt hơn không?” – cả với code của mình lẫn của người khác.

Kết luận

Giải quyết vấn đề kỹ thuật là kỹ năng quan trọng nhất mà một developer cần thành thạo.

Hãy rèn luyện nó mỗi ngày – từ bug nhỏ nhất, đến hệ thống phức tạp nhất.

Một dev giỏi không phải là người viết 1000 dòng code/ngày, mà là người biết cách tiếp cận vấn đề đúng – và đưa ra giải pháp gọn, hiệu quả, dễ duy trì.