Tư duy debug – Nhanh chóng, tiện lợi, an toàn

I. Mở bài
– Ông bà có câu: “Thế gian chuộng của, chuộng công. Nào ai có chuộng người không bao giờ”
Đã bao giờ bạn tự hỏi, “thế gian” đánh giá năng lực của ta dựa trên yếu tố nào không ?
– Yếu tố muôn thuở của mọi vấn đề chính là thời gian. Câu chuyện nhanh và chậm. Có 2 người cùng làm 1 loại công việc, giả sử xét trên tiêu chí là cả 2 đều hoàn thành được thì ai làm nhanh hơn(mất ít thời gian) thì hiệu suất cao hơn. Hầu hết trong mọi vấn đề, ta càng giảm thời gian xuống thì ta càng dễ nhận đánh giá cao từ cấp trên hay đồng nghiệp của mình.
– Có 1 sự thật rằng, càng trong những lúc hiểm nguy thì ta càng phải thể hiện bản thân tốt hơn. Bug là 1 cái thứ “đáng yêu” mà ta thường xuyên gặp phải trong quá trình phát triển sản phẩm. Ở đây, chúng ta sẽ bàn đến bug xảy ra trên các môi trường production/staging vì nó ảnh hưởng đến khách hàng. Làm thế nào khi nó đến, ta luôn có cách để điều tra và khắc phục nó nhanh nhất cho khách hàng ? Bài viết này sẽ chia sẻ cho bạn các bước cơ bản cùng với 1 case study thực tế.

II. Thân bài

Các bước cơ bản trong tư duy debug mà mình đề xuất
1. Xác nhận tình trạng bug với reporter
– Việc này thực sự rất quan trọng để ta xác minh được thực sự vấn đề là gì. Trong các dự án của công ty, hầu như PO là người gửi các thông báo lỗi/thắc mắc của khách hàng đến dev team. Mỗi người ở mỗi lĩnh vực sẽ có góc nhìn khác nhau, dẫn đến cách xác định vấn đề cũng khác nhau. Nhất là những vấn đề liên quan sâu sắc đến kĩ thuật. Chúng ta sẽ cần phải được cung cấp đẩy đủ các thông tin:
+ bối cảnh chức năng
+ dữ liệu
+ api/màn hình nào
+ hiện trạng lỗi
===> Cố gắng tái hiện lỗi và xác định được chính xác lỗi gặp phải. Next nào.

2. Đọc log
– Đây là 1 kỹ năng thường xuyên được dùng đến mà không thấy ai chỉ hoặc chương trình đào tạo nào dạy cả. Log sẽ cho ta biết thông tin sơ bộ về lỗi và 1 stack trace. Dựa vào đó ta có thể gọi bác google search dễ dàng.

Nhìn vào dòng 1 và 2 ta biết được thông tin lỗi và file xảy ra lỗi là: RCAPIErrorReads.scala tại dòng 44. Từ đó dễ dàng khoanh vùng và sửa lỗi.
Mọi lập trình viên đều cần biết và luyện tập kĩ năng này. Nếu bước này chưa giúp gì được bạn thì ta next tiếp nào.

– Mỗi chức năng ta phát triển đều sẽ có các bước cơ bản: A -> B -> C… Nhiệm vụ lần này là hình dung lại các bước trên, phản ảnh thông qua các khai báo function trong code. Cố gắng định hình xem phần lỗi đang nằm ở bước nào để giảm bớt phạm vi cần kiểm tra.
– Các lỗi khi xảy ra trên production/staging, tức là đã pass test của QA trên dev, chứng tỏ là dữ liệu test gây ra lỗi có điểm đặc biệt. Cái ta cần là xem xét dữ liệu lỗi và phân lập thành các nhóm. Cần 1 chút tinh tế + óc logic để khớp với phần flow đã nói ở trên.
Từ 2 ý trên ta có góc nhìn đầy đủ vùng lỗi, tác nhân đã gây ra lỗi.

Từ bước trên, ta đã có 2 điểm: dữ liệu gây ra lỗi và bước lỗi. Ta cần trổ tài phán đoán: đưa ra các kịch bản và tiến hành loại dần nó đi. Việc này cần có logic + kinh nghiệm chinh chiến. Lúc đầu sẽ hơi chậm, theo thời gian sẽ càng tiến bộ và tốc độ đưa ra phán đoán sẽ càng nhanh hơn. Bạn cần luyện tập nó hàng ngày. Ở mức đỉnh cao, đây sẽ là 1 phản xạ tự nhiên, vô thức. Đọc phát là ta đủ biết lỗi ở đâu rồi và sửa như thế nào. Nghe thật pro như siêu nhân vậy. Đừng giống như chơi sổ xố, đưa ra dự đoán và chờ đợi hên xui. Luôn ý thức rằng mọi dự đoán đều cần có cơ sở từ các bước trên. Sau cùng, ta cần kiểm chứng giả thuyết bằng cách tái hiện lỗi với 1 trường hợp tương tự. Bingo! Mọi thứ đến đây sẽ rất nhanh và xuôn xẻ.

5. Debug mode && Fake environment
– Đây là bước cuối cùng, là bước mà mình không khuyến khích áp dụng, nhất là với những bạn là lính mới bởi nó tốn thời gian và nguy hiểm.
Ý tưởng cơ bản ở đây là cố gắng mô phỏng dữ liệu từ môi trường thật về local và chạy project ở chế độ debug mode. Thông qua việc đặt các điểm break-point, ta sẽ lần từ từ qua các bước để xem dữ liệu gây lỗi ở đâu.
– Với các project sử dụng sbt && IntelIJ IDEA, bạn có thể làm theo các bước sau:
+ Chạy command: sbt -jvm-debug 5005 run
+ Tại IDEA, toolbar -> run -> attach to process -> chọn dòng nào có số 5005
+ Đặt các điểm break-point bằng cách tích chuột vào bên trái dòng code

Nên đặt break-point có định hướng, tránh việc tràn lan sẽ giúp giảm thời gian debug.
Qua bước này mà bạn vẫn chưa tìm được nguyên nhân gây ra lỗi thì giải pháp tốt nhất là bê máy sang hỏi người có nhiều kinh nghiệm hơn. Ta sẽ có được góc nhìn khác của vấn đề.

III. Kết luận
– Hi vọng với các bước mình trình bày ở trên sẽ giúp các bạn có phương hướng khi khắc phục lỗi. Vẫn nên hạn chế xảy ra lỗi, nếu chẳng may xảy ra thì ta sẽ chẳng ngán gì.
– Khi các bạn luyện tập theo các bước ở trên đủ nhiều, mọi thứ sẽ xảy ra rất nhanh trong đầu bạn. Sếp và đồng nghiệp sẽ rất ngỡ ngàng “fast and furious”. Ta sẽ thành địa điểm uy tín trong mắt người khác khi gặp khó khăn hay thắc mắc.
– Cuối cùng mình vẫn khuyên: hạn chế sử dụng bước 5, với 4 bước trên hoàn toàn đã đủ để ta xài rồi.
– Code hay debug, đến cuối cùng ai cũng làm được thôi. Điểm làm nên sự khác biệt chính là thời gian. Tối ưu thời gian càng tốt thì giá trị ta thu về càng nhiều. Hãy làm việc thông minh và có phương pháp, ta sẽ luôn là ngôi sao nổi bật.
Phần tiếp theo của bài viết là case study thực tế của dự án CTX. Cùng xem ta áp dụng các bước trên giải quyết vấn đề như thế nào.

Nguồn: labs.flinters.vn