Những người bạn đồng hành trên con đường không nuột nà của code

Code của em chạy local ổn sao deploy lên dev/stage/production nó lỗi rồi, mà em không biết lỗi ở đâu!

Hẳn đây luôn là trường hợp oái ăm ít nhiều gì các anh chị em dev trong nghề cũng đã trải qua, thật dễ để debug hay trace lỗi khi mọi thứ ở local, khi mà bạn có thể kiểm soát được mọi thứ theo những luồng mong muốn.

Nhưng nếu có những trường hợp không ngờ tới khi đến tay các tester, QC hay người dùng cố tình “múa” để tìm ra bug trong phần mềm của bạn thì sao?

Ở bài viết này, mình sẽ chia sẻ một số “bạn đồng hành” đã làm quen trong hành trình xử lí lỗi (error handling) khi theo chân code đi trên con đường không nuột nà như mong muốn.

Validator – Người kiểm duyệt

Sức chứa một column của bạn là 100 kí tự nhưng nhận được input là 101, sau một hồi xử lí phức tạp lại nhận được lỗi vượt quá maximum length từ database?

Người dùng A thực hiện huỷ đơn hàng số 123, sau đó “nghịch” bằng cách gọi đúng API huỷ đơn hàng số 456 của người dùng B và thành công?

Dữ liệu đầu vào luôn là thứ cần được kiểm duyệt khắt khe, hiện nay nhiều library hay framework từ frontend đến backend đều đã hỗ trợ validate các input đầu vào cùng với regex pattern và message lỗi tương ứng, vì vậy trước khi dữ liệu được gửi đi để xử lí, hãy luôn kèm theo một bước kiểm tra tính hợp lệ, bạn sẽ không ngờ được user có thể đưa bất kì thứ gì vào input đâu.

Còn liên quan đến xác thực phân quyền (authorization), hãy luôn đảm bảo các function được gắn đúng người đúng việc đúng quyền, và câu query của bạn có kiểm tra điều kiện hợp lệ là đúng với resource của người dùng trước khi thực thi (để tránh trường hợp huỷ đơn hộ như trên).

Như trường hợp trên, user A và user B đều có thể thực hiện huỷ đơn của mình, vậy hãy chắc rằng đơn được huỷ thuộc đúng người bằng cách check exist hoặc có condition where user_id = <user_nào đó> khi lấy thông tin nhé.

Hãy luôn nhớ validate input từ frontend đến cả backend

Logger – Người ghi chép

Bạn không thể debug khi code đã được deploy, nhưng bạn có thể ghi lại những bước mà code đã thực thi, các đoạn log tưởng chừng như thừa thãi như Bắt đầu xử lí ABC, Nhận được response DEF hay Lỗi tại function XYZ… sẽ là cứu tinh của bạn khi bật monitor để xác định lỗi bắt nguồn từ đâu và luồng đã chạy đến đâu thay vì ngồi đọc một cái error stack-trace đầy rẫy những lỗi trong core-library.

Nếu có thể, hãy luôn ghi log tại những điểm quan trọng trong xử lí: khi bắt đầu một function, bắt đầu init service, trước khi gửi request đến một service khác, sau khi nhận được response, trước khi kết thúc hàm, hoặc ngay sau khi nhận được lỗi… để đảm bảo bạn luôn có nguồn minh chứng cho việc code được thực thi cũng như khoanh vùng tìm lỗi một cách nhanh chóng.

Các logger trong các ngôn ngữ hay framework nay cũng đã support đến tận răng – từ thời điểm ghi lại chính xác đến từng mili-giây, lỗi xảy ra tại function nào cho đến có thể ghi ra các object trong quá trình xử lí chứ không đơn thuần chỉ log ra lỗi và message do user tự định nghĩa.

Ví dụ về logging trong Grafana

Alert – Người cảnh báo

Bạn không thể nào luôn check log mọi lúc mọi nơi, đặc biệt là khi môi trường staging hay production gặp lỗi, đến lúc nhận được phản hồi lỗi từ người dùng, đối tác hay bộ phận chăm sóc khách hàng thì có thể lỗi cũng đã xảy ra tương tự ở nhiều nơi khác, nếu nhận được thông tin càng trễ thì dĩ nhiên sự tình sẽ càng nghiêm trọng.

Vì vậy, trong các môi trường như staging hay production, khi phát sinh bug hay các lỗi không mong muốn khiến cho luồng xử lí “đột tử” một cách bất ngờ, các core team có thể build hệ thống tự động gửi cảnh báo đến email, kênh chat, hay thậm chí là tin nhắn điện thoại đến những người có liên quan, giúp cho team dev dễ dàng trace lỗi và ứng phó.

Việc có các cảnh báo tự động còn góp công lớn không chỉ cho đội ngũ phát triển, mà còn có thể hỗ trợ cả team chăm sóc khách hàng hay team truyền thông của dự án kịp thời ứng phó và thông tin đến người dùng.

Error alert trong Slack, có tin tới là check log ngay

Messenger – Người thông tin

Code của bạn không hoàn hảo, và thậm chí những lỗi bất ngờ luôn có thể xảy ra, vì vậy khi gửi thông tin giữa các service hay response trong các API, hãy luôn tâm huyết trong những message gửi đi.

Bản chất người thông tin là do bạn tạo ra, và nó sẽ gắn liền với ba người bạn trên – chi tiết mà bạn ghi ra trong các dòng log, alert hay validation sẽ là nguồn thông tin trọng yếu khi code của bạn đi lầm đường lạc lối.

Một message lỗi thân thiện trong response API như Trường email không hợp lệ, Không thể tìm thấy người dùng, Có lỗi xảy ra, bạn vui lòng liên hệ bộ phận chăm sóc khách hàng… sẽ giúp cho việc giao tiếp giữa người dùng với ứng dụng, giữa các team hay giữa các anh chị em dev với nhau được trơn tru và nuột nà hơn.

Riêng đối với message trong logger hay alert có liên quan đến đội ngũ engineer thì bạn nên đổi cách hành văn theo hơi hướng technical một chút như Email field is not matched with regex, No record found in table users, Request time out hay Received response status 400 from ABC service with message xyz

Cũng đừng quá thân thiện như Password này thuộc về user anhdepchai99 nhé

Reviewer – Người đánh giá

Không có phần mềm nào hoàn hảo, các đoạn code luôn có thể gặp lỗi, requirement cũng như khả năng scale của ứng dụng cũng thay đổi theo thời gian,… Đồng thời bản chất coding cũng như là hành văn, nó sẽ mang đậm màu sắc của bạn, vì thế chúng ta luôn có những người đánh giá như sau:

  • Các senior hay team member review code để đảm bảo tuân thủ theo quy chuẩn, kiểm tra đã xử lí đầy đủ các trường hợp và performance đảm bảo không, có cách nào cải thiện code hơn…
  • Các tester, QC hay PO review luồng thực thi, dữ liệu đã đảm bảo đúng chưa, đầu vào các trường hợp éo le đã được xử lí hay chưa, nếu lỗi phát sinh thì xử lí ra sao…
  • Các user sẽ feedback ứng dụng chạy chậm ở đâu, có chức năng gì khó sử dụng, có thể cải tiến thêm ở những điểm nào…
  • Các chuẩn lint khi build CI/CD đảm bảo code của bạn chất lượng hơn như đưa ra các cảnh báo init unused variable, duplicated code, code complexity quá lớn, vi phạm naming convention…
Hãy đảm bảo luôn có người review code của bạn

Kết

Thật khó để nói chắc rằng code của bạn luôn chạy nuột nà trong mọi trường hợp, vì những tình huống bất ngờ luôn có thể xảy ra, việc viết code nếu chỉ nghĩ đến happy case thực sự là một thiếu sót rất lớn nếu thiếu đi những người bạn đồng hành trên.

Bạn có quen thêm những ai khác trong quá trình error handling không? Có thể chia sẻ với mình tại đây nhé =P

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s