Phức tạp hóa vấn đề: Làm sao để debug? (Phần 2)

#Nếu lỗi phía Frontend

Đứng ở góc độ frontend, những lỗi có khả năng xảy ra trong trường hợp này là:

Giả sử backend hoạt động tốt, thì phía frontend:

  • Quên xử lý sự kiện click của nút Add to Card (quên code) 
  • Không handle đúng dữ liệu trả về của backend để render ra màn hình cho đúng

Hoặc nếu có lỗi từ backend, thì lỗi của phía frontend là:

  • Không handle trường hợp xảy ra lỗi khi gọi API
  • Không handle luôn cả request timeout,…

Hoặc cũng có trường hợp cả backend và frontend đều chạy đúng, nhưng có một lỗi không liên quan làm ảnh hưởng đến chức năng hiện tại, ví dụ như một lỗi ất ơ nào đó khi load trang, làm break cả frontend app, vì thế nên sự kiện click của nút Add to Card không chạy nữa,…

#Nếu lỗi phía Backend

Từ phía backend, những lỗi có khả năng xảy ra là:

  • Quên không validate dữ liệu request lên từ phía frontend
  • Code logic để thêm một item vô cart bị sai, hoặc add lộn vô cart của một user khác 
  • Không kết nối được với database, hoặc kết nối được nhưng viết raw SQL query nên khi insert vô DB thì bị lỗi cú pháp, hoặc bị SQL injection luôn mà không biết 
  • Hoặc là mọi thứ hoạt động trơn tru, nhưng quên gửi data trả về cho frontend 

#Nếu lỗi phía Database

Nếu là từ phía database thì có thể là:

  • Quên bật database 
  • Bị tràn dung lượng đĩa cứng (ai xài WordPress với MySQL trên mấy con free host ngày xưa chắc gặp cái này hoài)

Đưa ra phương án khắc phục

Sau khi đã biết được nguyên nhân thì chúng ta có thể dễ dàng đưa ra cách khắc phục, nhưng quan trọng hơn hết là phải đưa ra được phương án hành động để không lặp lại vấn đề như thế này trong tương lai.

Cụ thể vấn đề lớn nhất có thể thấy từ đầu bài đó là vì sao phải ngồi vẽ rồng vẽ rắn rồi đoán mò từng bước như thế? Đó là vì chưa ai đề cập đến việc cần có một hệ thống tracking, monitoring từ cả frontend lẫn backend.

Trên thực tế, có rất nhiều công cụ giúp monitor, tracking lỗi hiệu quả, như Sentry, FullStory, hay các công cụ phân tích log như Splunk,…

Đáng ra phải đề cập luôn từ đầu bài nhưng tại viết tới đây rồi mới nhớ ra nên thôi, lười.

Kết

Tóm lại, sau khi đã có bức tranh toàn cảnh, thì việc chẩn đoán rất dễ, chỉ cần một ít nghi ngờ về bản thân và đồng đội, chúng ta có thể đưa ra hàng trăm giả thuyết để có thể blame nhau, rồi cùng nhau tìm cách reproduce, rồi fix, rồi commit, rồi test, rồi deploy, rồi xách cặp đi về nhà.

Nhưng việc đó chỉ đúng nếu bạn không phải là một frontend developer.

Trong bất cứ trường hợp nào, dù vấn đề xảy ra ở phía backend, database hay thậm chí là từ phía người dùng, nếu như có một dòng thông báo cụ thể trên màn hình thì cả team đã không mất thời gian vẽ rồng vẽ rắn và chỉ trỏ blame nhau như thế này, cho nên mọi tội lỗi đều có thể đổ lên đầu các bạn frontend developer  (nếu biết trước cái nghề nó bạc vậy thì mình đã không theo).

Tham khảo khóa học lập trình web 6 tháng, đảm bảo 100% công việc đầu ra!

Nguồn: https://topdev.vn/blog/phuc-tap-hoa-van-de-lam-sao-de-debug/


Hãy tham gia nhóm Học lập trình để thảo luận thêm về các vấn đề cùng quan tâm.

Bài viết liên quan

Leave a Reply

Your email address will not be published.

TÀI LIỆU DEV WORLD
Cẩm nang phát triển bền vững với nghề lập trình!