Làm thế nào để trở thành một Pro Debugger

Trở thành một nhà phát triển có nghĩa là hơn một nửa thời gian bạn phải là người gỡ lỗi, đôi khi cho mã của riêng bạn và đôi khi để giúp đồng nghiệp của bạn xem xét mã hoặc trong trường hợp lập trình cặp. Mặc dù là một kỹ năng cần thiết cho các nhà phát triển, gỡ lỗi không phải là thứ được dạy cho bất kỳ ai ở bất kỳ thời điểm nào trong sự nghiệp của họ, điều này dẫn đến niềm tin rằng nó rất khó.

Gỡ lỗi trông có vẻ khó khăn, không phải do cơ chế của nó, mà vì rất khó để hiểu bắt đầu từ đâu khi mới bắt đầu. Không nghi ngờ gì nữa, đó là một nghệ thuật có thể đạt được bằng cách tạo và xem xét ngày càng nhiều mã theo thời gian, nhưng trực giác có thể được phát triển sớm với một vài khuyến nghị mà chúng ta sẽ thảo luận hôm nay trong bài viết này.

Bắt đầu nào.

Tái tạo vấn đề

Tình huống tồi tệ nhất trong khi gỡ lỗi bất kỳ vấn đề nào là khi lỗi không thể được tái tạo một cách đáng tin cậy. Sự cố có thể xảy ra do một số yếu tố như điều kiện chủng tộc, hệ thống bên ngoài hoặc các vấn đề môi trường dẫn đến các mẫu hành vi khác nhau trên các hệ thống đã triển khai hoặc hộp giai đoạn của nhà phát triển.

Điều này cho thấy cả người thử nghiệm và nhà phát triển rằng bạn càng có thể làm rõ được cách tái tạo lỗi càng cụ thể thì càng tốt. Ngoài ra, khi bạn đã tìm ra vấn đề và cách chứng minh nó, hãy đảm bảo rằng bạn đưa tất cả các chi tiết về việc tái tạo nó cũng như hiểu và giải quyết nó, trên một hệ thống theo dõi lỗi. Điều này sẽ không chỉ giúp bạn xác minh bản sửa lỗi sau khi được triển khai mà còn giúp các nhà phát triển khác hiểu nguyên nhân và giải pháp của lỗi.

Dưới đây là một số mẹo đơn giản để làm theo khi mô tả các bước để tái tạo sự cố:

• Hãy cố gắng cụ thể hóa, vì bạn càng đề cập đến nhiều xác suất, thì càng có nhiều con đường điều tra được mở ra.
• Trong trường hợp đầu vào là bắt buộc, hãy luôn bao gồm một số giá trị mẫu hoặc ví dụ. Ngoài ra, hãy đề cập đến các ràng buộc hoặc quy tắc được chỉ định cho đầu vào của người dùng vì đó có thể là nguyên nhân có thể gây ra sự cố, điều này đáng được kiểm tra.
• Luôn chỉ định chi tiết về môi trường - hệ điều hành, loại trình duyệt và phiên bản trình duyệt. Đây có thể là trường hợp đặc biệt đối với các ứng dụng web nơi các trình duyệt khác nhau có thể mô tả các hành vi khác nhau.
• Bao gồm các báo cáo sự cố có liên quan, nhật ký, ảnh chụp màn hình có chú thích, v.v. để giải thích chính xác sự khác biệt giữa cách bạn mong đợi ứng dụng hoạt động và cách ứng dụng thực sự hoạt động, không để trình gỡ lỗi hiểu nhầm.

Chuyển vấn đề thành một bài kiểm tra tự động

Bước này không phải lúc nào cũng có thể thực hiện được; và đôi khi nó có thể nhưng không thực tế hoặc không thực sự cần thiết, tuy nhiên, có thể có những trường hợp đáng để thực hiện. Kiểm thử tự động, trong ngữ cảnh này, có thể là bất kỳ thứ gì mà trường hợp sử dụng phát triển của bạn đã sử dụng để kiểm tra, chẳng hạn như kiểm thử đơn vị hoặc kiểm tra tích hợp. Bất cứ khi nào có thể, kiểm tra đơn vị là một lựa chọn tuyệt vời vì chúng được thiết kế để thực hiện thường xuyên, vì vậy bạn sẽ biết nếu sự cố sớm quay trở lại.

Bạn có thể thấy mình viết rất nhiều bài kiểm tra đơn vị sẽ vượt qua trong khi cố gắng xác định nguồn gốc của vấn đề. Bạn cũng có thể tình cờ thấy mình đang viết các bài kiểm tra đơn vị không có ý nghĩa gì ngoài tình huống hiện tại, nhưng ngay cả như vậy, không có hại gì khi có một bài kiểm tra có thể giúp bạn chỉ ra nguồn gốc của vấn đề. Chỉ vì nó không phải là vấn đề hiện tại không có nghĩa là nó sẽ không tìm thấy nó sau này - và nó cũng phục vụ như một tài liệu khác về cách mã sẽ hoạt động. Kiểm tra đơn vị làm việc thường là một cách tiếp cận tuyệt vời để xác định lớp nào bên trong hệ thống đang tạo ra sự cố.

Cấu trúc lại các bài kiểm tra đơn vị của bạn với sức sống giống như bạn làm với mã sản xuất của mình. Nếu bạn có một bài kiểm tra đơn vị lớn đang thực sự kiểm tra một đoạn mã quan trọng, hãy cố gắng chia nó thành các bài kiểm tra nhỏ hơn. Nếu may mắn, bạn sẽ phát hiện ra rằng một bài kiểm tra đơn vị thất bại lớn dựa trên vấn đề ban đầu có thể được chia thành nhiều bài kiểm tra vượt qua và một bài kiểm tra trượt nhỏ, duy nhất.

Ngay cả khi bạn phát hiện ra vấn đề sớm và có thể giải quyết nó trong một dòng, hãy xây dựng một bài kiểm tra đơn vị để xác nhận nó bất cứ khi nào có thể. Việc mắc lỗi khi sửa mã cũng đơn giản như phát triển nó ngay từ đầu và các nguyên tắc kiểm tra đầu tiên vẫn được áp dụng.

Đừng mong đợi rằng mọi thứ sẽ hoạt động như bình thường

Bạn phải hoang tưởng một chút nếu bạn đang gỡ lỗi bất kỳ vấn đề nào để giữ cho mình tiếp tục vì rõ ràng có thứ gì đó ở đâu đó không hoạt động như ý muốn, nếu không sẽ không có vấn đề gì. Bạn cần phải cởi mở về nơi vấn đề có thể xảy ra và điều hướng với kiến thức của bạn về hệ thống liên quan.

Mục tiêu chính ở đây là ngăn bạn tuyên bố, "Vấn đề không thể ở đó." Hãy chứng minh nếu bạn không tin. Nếu nó xuất hiện, bất kể nó không thể xuất hiện như thế nào, hãy tìm hiểu kỹ hơn về nó.

Hãy rõ ràng về mục đích của mã

Nếu mục đích của bất kỳ đoạn mã nào không rõ ràng đối với bạn, bất kể nó có thể là nguyên nhân của sự cố hay không, hãy dành một chút thời gian để hiểu nó. Bạn luôn có thể đặt một số thử nghiệm xung quanh nó và cố gắng ghi lại những gì nó hoạt động. Nếu bạn không chắc liệu hành vi đó có đúng hay không, hãy yêu cầu trợ giúp. Khi đã rõ ràng, hãy cố gắng ghi lại mọi thứ bạn biết, cho dù bằng một bài kiểm tra, tài liệu XML hay một số tài liệu bên ngoài.

Khắc phục từng sự cố một

Nếu một đoạn mã đặc biệt xấu, bạn có thể phát hiện ra các vấn đề khác trong khi gỡ lỗi mã gốc. Trong trường hợp như vậy, điều quan trọng là phải quyết định vấn đề nào phải được giải quyết trước và sau đó chỉ tập trung vào vấn đề đó.

Trong một thế giới hoàn hảo, bạn sẽ giải quyết một vấn đề, xác minh mã của bạn trong kiểm soát phiên bản, sau đó sửa lỗi tiếp theo, v.v. Điều này giúp bạn dễ dàng xác định những thay đổi nào trong mã dẫn đến những thay đổi trong hành vi sau này, điều này rất quan trọng khi một bản sửa lỗi cho một vấn đề hóa ra lại phá vỡ một vấn đề khác.

Làm cho mã của bạn giúp bạn gỡ lỗi

Nhật ký có thể cực kỳ hữu ích trong việc gỡ lỗi. Họ có thể cung cấp cho bạn thông tin từ cơ sở mà trình gỡ lỗi có thể không hữu ích. Tuy nhiên, ghi nhật ký, giống như gỡ lỗi, cũng là một nghệ thuật cẩn thận. Nếu bạn không làm điều đó một cách chính xác, nó có thể không thể giúp bạn một cách tốt nhất có thể. Vì vậy, bất cứ khi nào một ngoại lệ được đưa vào mã, hãy làm cho nó không chỉ ghi lại thông điệp của ngoại lệ mà còn theo dõi ngăn xếp.

Các ngoại lệ về cơ bản không bao giờ được nuốt âm thầm mà không được ghi lại. Đôi khi chúng có thể là cách dễ nhất để xác minh thông tin đầu vào của người dùng hoặc cài đặt cấu hình. Trong những tình huống này, ghi nhật ký có thể thực sự là người bạn của bạn.

Tương tự, làm cho mã của bạn chống lại đầu vào xấu. Đầu vào xấu được phát hiện càng sớm thì càng dễ tìm ra vấn đề. Có thể khó tìm ra gốc rễ của vấn đề nếu bạn chỉ nhận được một kỳ vọng sau khi một giá trị đã được xử lý bằng một số phương pháp. Hợp đồng có thể hữu ích trong việc xác định các ràng buộc ở đây, nếu không, bạn nên thận trọng và bổ sung các xác nhận nếu bạn nghi ngờ có vấn đề trong tương lai.

Tìm hiểu về trình gỡ lỗi của bạn

Giống như một Jedi không thể trở nên tuyệt vời nếu không có Light Sabre của anh ấy, bạn không thể trở thành một nhà phát triển tuyệt vời nếu không biết về khả năng của trình gỡ lỗi của mình. Trình gỡ lỗi hiện đại có rất nhiều tính năng hầu như không được sử dụng vì các nhà phát triển không biết về chúng. Ví dụ: các điểm ngắt có điều kiện hoặc biểu diễn cấu trúc dữ liệu do người dùng xác định có thể tạo ra sự khác biệt giữa phiên gỡ lỗi kéo dài cả ngày hoặc phiên chỉ kéo dài trong 10 phút.

Bạn không cần phải biết tất cả mọi thứ, nhưng một ý tưởng tốt về những gì trình gỡ lỗi của bạn có khả năng và kiến thức tốt về các phím tắt liên quan đến các chức năng cơ bản như bước qua, bước vào, đặt điểm ngắt và tiếp tục thực thi là rất quan trọng .

Cho mọi người tham gia

Gỡ lỗi rất khó vì nó có thể làm mất tinh thần và làm việc với một mê cung mã được ghi chép kém có thể nhanh chóng dẫn đến kiệt sức về thể chất. Hãy xem xét điều này: nếu bạn đang gặp khó khăn, hãy nghỉ ngơi, đi dạo, ăn cà phê, một thanh sô cô la - bất cứ điều gì có ích cho bạn.

Đừng bối rối nếu bạn cần thêm người khác - nếu hành vi của mã có vẻ khó tin hoặc nếu bạn không biết phải tìm ở đâu, hãy hỏi. Để ý xem người kia đang làm gì, vừa để học hỏi từ họ vừa để cảnh báo họ nếu họ có vẻ đang đi vào một con hẻm khuất mà bạn đã quan sát trước đó. Hãy cho họ biết những gì bạn đã quan sát và những gì bạn nghĩ, một cuộc thảo luận có thể mang lại một gợi ý.

Kiểm tra đến CUỐI CÙNG

Khi bạn nghĩ rằng mình đã giải quyết được vấn đề, hãy làm tất cả những gì bạn có thể để kiểm tra nó (trong phạm vi lý do). Rõ ràng, các bài kiểm tra đơn vị nên là cổng gọi đầu tiên của bạn - các bài kiểm tra đơn vị mà bạn đã giới thiệu để cô lập vấn đề bây giờ sẽ vượt qua, nhưng tất cả các bài kiểm tra khác cũng vậy.

Vấn đề cấp cao thường do nhiều vấn đề cấp thấp gây ra - thật dễ dàng để phát hiện ra vấn đề cấp thấp đầu tiên, sửa nó và sau đó giả sử vấn đề cấp cao sẽ biến mất. Đôi khi điều ngược lại xảy ra: hành vi cấp cao xấu đi do một vấn đề cấp thấp quan trọng hơn. Trong trường hợp đó, bạn sẽ cần tiếp tục sửa chữa và sau đó kiểm tra cho đến khi bạn thấy rằng mọi thứ hoạt động chính xác.

Kiểm tra các lỗi tiềm ẩn

Các vấn đề thường xuyên xảy ra trong các nhóm. Ví dụ: nếu bạn phát hiện ra rằng ai đó quên thực hiện đầy đủ thoát / mã hóa đối với dữ liệu nhập của người dùng trong một trường hợp, vấn đề tương tự có thể phát sinh trong một trường hợp khác. Sẽ ít tốn kém hơn đáng kể khi thực hiện kiểm tra nhanh các vấn đề có thể xảy ra cùng một lúc so với việc để mỗi vấn đề được nêu ra như một vấn đề riêng biệt, có thể liên quan đến các kỹ sư khác thực hiện cùng một cuộc điều tra mà bạn vừa hoàn thành.

Xem xét hậu quả của miếng dán của bạn trong một tĩnh mạch tương tự. Nó có gây ra sự cố ở một nơi khác mà có thể không khắc phục được trong thời gian ngắn không? Nó sẽ có tác động đến việc vá lỗi hoặc nâng cấp? Đây có phải là một sửa chữa đáng kể ở giai đoạn này trong vòng đời sản phẩm của bạn không? Thông thường, việc tìm ra lỗi sai luôn đáng giá, nhưng đôi khi sẽ an toàn hơn nếu để mã bị hỏng - có khả năng là sửa chữa "hỗ trợ ban nhạc" để giải quyết các triệu chứng nhưng không phải nguyên nhân - và để lại phương pháp chữa trị hoàn toàn cho bản phát hành tiếp theo. Điều này không có nghĩa là bạn nên để nguyên bản báo cáo lỗi.

Nếu bạn có đề xuất sửa chữa, hãy thử tạo một tệp vá và thêm tệp đó vào báo cáo lỗi (tất nhiên, làm rõ phiên bản nào của tệp cần vá). Ít nhất, hãy cung cấp giải thích chi tiết về nghiên cứu của bạn trong báo cáo lỗi để tránh lãng phí thời gian sau này. Trạng thái lỗi của "Giải quyết bản phát hành tiếp theo" (hoặc bất cứ điều gì tương đương của bạn) chỉ nên chỉ ra rằng, không phải "Chúng tôi có khả năng sẽ thực sự khắc phục sự cố này, nhưng chúng tôi sẽ trì hoãn bản phát hành một lần."

Sự kết luận

Những khuyến nghị này không thể biến bạn trở thành một trình gỡ lỗi chuyên nghiệp trong một hoặc hai ngày, nhưng nó chắc chắn sẽ giúp bạn bắt đầu đúng hướng nếu tuân theo sự kiên nhẫn và thực hành tốt. Mã chất lượng cao không ngẫu nhiên xảy ra - nó cần sự kiên nhẫn và chính xác.

Đó là tất cả cho bài viết này. Hãy cho tôi biết suy nghĩ của bạn về các mẹo gỡ lỗi ở trên và vui lòng thêm cách tiếp cận, mẹo và thủ thuật của bạn để trở thành một trình gỡ lỗi chuyên nghiệp trong các nhận xét bên dưới.

Hãy đọc tiếp!