Làm thế nào để bạn gỡ lỗi mà không có IDE? [đóng cửa]

Mỗi lần tôi tìm một IDE (hiện tại tôi đang mày mò với Go), tôi tìm thấy một chủ đề đầy những người giới thiệu Vi, Emacs, Notepad ++, v.v.

Tôi chưa bao giờ thực hiện bất kỳ sự phát triển nào ngoài IDE; Tôi đoán tôi đã hư hỏng. Làm thế nào để bạn gỡ lỗi mà không có IDE? Bạn có giới hạn chỉ đăng nhập?

Bằng cách sử dụng một trình gỡ lỗi. Đối với hầu hết các phần, đây cũng là điều mà IDE thực hiện đằng sau hậu trường - nó chỉ gói gọn trải nghiệm trong GUI.

Trên Unix, một trong những trình gỡ lỗi được sử dụng phổ biến nhất là GNU gdb, phần lớn đã thay thế các trình gỡ lỗi Unix trước đó như dbx.

Để có được ý tưởng về việc gỡ lỗi trông như thế nào / cảm thấy như thế nào từ dòng lệnh, bạn có thể xem hướng dẫn gdb .

Giống như trong các lĩnh vực khác, sử dụng trình gỡ lỗi từ dòng lệnh yêu cầu học một cú pháp và một bộ lệnh, nhưng mang lại rất nhiều tính linh hoạt và khả năng viết kịch bản. Mặt khác, nếu bạn đã thoải mái làm việc trong một trình soạn thảo như vim hoặc emacs, bạn có thể thấy rằng trình soạn thảo yêu thích của bạn có một trình cắm cho trình gỡ lỗi yêu thích của bạn.

Tôi đã sử dụng một trình sửa lỗi trong vài năm khi tôi đang viết trình điều khiển đồ họa. Tôi đã có một máy tính thứ hai chạy trình gỡ lỗi so với máy tính thứ nhất (vì màn hình trong máy tính chính sẽ không hoạt động khi trình điều khiển đồ họa bị hỏng). Điều quan trọng là có thể dừng mã và bước đến điểm tôi treo phần cứng để tôi biết điều gì đang xảy ra.

Đối với các vấn đề hoàn toàn về phần mềm, tôi thấy rằng suy nghĩ về vấn đề và kiểm tra hệ thống để tìm hiểu thêm về vấn đề này hữu ích hơn nhiều so với việc từng bước từng dòng mã. Với các câu lệnh in, tôi có một danh sách tất cả mọi thứ xảy ra ở dòng lệnh hoặc tệp nhật ký mà tôi có thể xem và xây dựng lại những gì đã xảy ra, đi lùi và chuyển tiếp dễ dàng hơn bao giờ hết với trình gỡ lỗi.

Các lỗi khó nhất thường được giải quyết bằng cách hiểu vấn đề ra khỏi máy tính. Đôi khi với một mảnh giấy hoặc bảng trắng, và đôi khi câu trả lời tự tiết lộ trong khi tôi đang làm một việc khác. Các lỗi khó nhất được giải quyết bằng cách xem kỹ mã như chơi Waldo của Where. Tất cả phần còn lại có vẻ dễ nhất với báo cáo in hoặc báo cáo đăng nhập.

Những người khác nhau có phong cách khác nhau, và phong cách khác nhau tốt hơn cho các nhiệm vụ khác nhau. Báo cáo in không nhất thiết phải là một bước xuống từ trình gỡ lỗi. Tùy thuộc vào những gì bạn đang làm, họ thậm chí có thể tốt hơn. Đặc biệt là trong một ngôn ngữ không có trình gỡ lỗi bản địa (có phải không?).

Một số người sử dụng gdb tại dòng lệnh hoặc plugin . Ngoài ra còn có giao diện người dùng GUI độc lập với gdb, như DDD . Tùy thuộc vào ngôn ngữ của bạn, có các GUI gỡ lỗi độc lập dành riêng cho ngôn ngữ, như Winpdb cho python hoặc jswat cho java. Bởi vì các dự án này chỉ tập trung vào gỡ lỗi, chúng thường vượt trội so với các trình gỡ lỗi tích hợp.

Một bí mật bẩn thỉu khác về IDE là tất cả chúng đều có giá trị muối cho phép bạn chỉ định một trình soạn thảo tùy chỉnh, vì vậy bạn có thể sử dụng các phần của IDE cho một số tác vụ nhất định, nhưng sử dụng trình chỉnh sửa hợp lý để chỉnh sửa. Không có gì lạ khi chỉ kích hoạt IDE để sử dụng trình gỡ lỗi của nó, đặc biệt nếu đó là những gì đồng nghiệp của bạn sử dụng.

Một số ngôn ngữ cung cấp REPL - nghĩa là bạn có thể viết và thực thi từng dòng mã khi bạn viết nó, đây có thể là bước đầu tiên để xác minh một đoạn mã. Nhiều trong số này cũng cung cấp các cơ sở sửa lỗi. GHC cho Haskell đi kèm với GHCi có thể được sử dụng để gỡ lỗi tương tác một chương trình trong dòng lệnh, tương tự như cách IDE sẽ làm.

Tôi không hiểu tại sao có ác cảm với việc gỡ lỗi khi sử dụng các câu lệnh printf. Đã có lúc mất quá nhiều thời gian để biên dịch lại và liên kết một chương trình, nhưng hôm nay chỉ mất vài giây. Tôi thấy rất dễ dàng để gỡ lỗi bằng cách sử dụng loại đầu ra cout, printf, qDebug (), v.v. Các câu lệnh Printf cung cấp cho bạn một lịch sử chạy của tất cả mọi thứ mà chương trình đã làm, mà bạn có thể phân tích sau khi thực tế, trong khi chạy trong trình gỡ lỗi khiến bạn phải nhớ thủ công dòng chương trình khi nó chạy. Với printf's, bạn có thể chuyển đổi giá trị của các biến thành các đơn vị cụ thể, hiển thị chúng dưới dạng hex, thập phân, bất cứ thứ gì. Các câu lệnh printf có thể liệt kê tên của các thường trình và biến cũng như số dòng. Bạn chỉ có thể liệt kê các thành phần mảng nhất định tùy thuộc vào các biến khác. Bạn có thể làm theo chỉ dẫn. Bạn có thể kiểm soát đầu ra rất dễ dàng, đặt trong bộ đếm, chỉ in một số lần nhất định thông qua một vòng lặp, thêm và xóa các câu lệnh in khi bạn gỡ lỗi, có các mức đầu ra gỡ lỗi khác nhau, ghi vào tệp, v.v. Việc xem lịch sử chương trình của bạn được ghi vào tệp dễ dàng hơn nhiều so với cố gắng nhớ tất cả các địa điểm bạn bước qua một cách thủ công và có thể phải ghi lại nội dung của các biến khi chúng thay đổi theo thời gian, để khám phá những gì chương trình đã làm. Và cuối cùng, với các câu lệnh printf, bạn có thể để chúng vĩnh viễn, được bật và tắt, để gỡ lỗi trong tương lai. Dễ dàng hơn để xem lịch sử chương trình của bạn được ghi vào một tệp hơn là cố gắng nhớ tất cả các địa điểm bạn đã bước qua một cách thủ công và có thể phải ghi lại nội dung của các biến khi chúng thay đổi theo thời gian, để khám phá chương trình là gì đã làm. Và cuối cùng, với các câu lệnh printf, bạn có thể để chúng vĩnh viễn, được bật và tắt, để gỡ lỗi trong tương lai. Dễ dàng hơn để xem lịch sử chương trình của bạn được ghi vào một tệp hơn là cố gắng nhớ tất cả các địa điểm bạn đã bước qua một cách thủ công và có thể phải ghi lại nội dung của các biến khi chúng thay đổi theo thời gian, để khám phá chương trình là gì đã làm. Và cuối cùng, với các câu lệnh printf, bạn có thể để chúng vĩnh viễn, được bật và tắt, để gỡ lỗi trong tương lai.

jimwise đã trả lời câu hỏi khá tốt, nhưng tôi nghĩ tôi nên thêm điều đó, nếu bạn chọn làm việc mà không có IDE đầy đủ, trình gỡ lỗi dòng lệnh do Microsoft cung cấp cho Windows được gọi là CDB . CDB đi kèm với một số công cụ khác, bao gồm WinDBG tương đương với GUI, khi bạn tải xuống SDK Windows.

Tôi thường không sử dụng trình gỡ lỗi, có thể vài tuần một lần nhưng đó không phải là điều đầu tiên tôi đến.

Công cụ quan trọng nhất trong công việc của tôi rất phổ biến đến nỗi tôi gần như quên đề cập đến nó - dấu vết ngăn xếp. Hơn 90% các vấn đề tôi gặp phải có thể được giải quyết bằng cách kiểm tra dấu vết ngăn xếp. Công cụ này không phải lúc nào cũng hữu ích tùy thuộc vào ngôn ngữ của bạn, nhưng khi chúng được triển khai tốt bằng ngôn ngữ, chúng có thể giúp bạn tiết kiệm một lượng thời gian đáng kinh ngạc.

Tôi đoán cách phổ biến thứ hai tôi phát hiện ra các vấn đề đơn giản là có lẽ đó là mã tôi vừa thay đổi. Tôi chạy thử nghiệm đơn vị khá thường xuyên vì vậy tôi thường biết những gì tôi vừa phá vỡ.

Để phát triển và gỡ lỗi phức tạp hơn, tôi có thể thêm một số báo cáo nhật ký mức gỡ lỗi hoặc theo dõi. Tôi coi các vấn đề phát triển là một hướng dẫn tốt để giúp tôi đặt thông tin ghi nhật ký theo dõi / gỡ lỗi sản xuất, điều này dẫn tôi đến:

Bạn không phải lúc nào cũng có trình gỡ lỗi tiện dụng. Trong sản xuất, có thể không thể chạy trình gỡ lỗi (Heck, có thể không thể truy cập vào các máy sản xuất ngoại trừ nhật ký tùy thuộc vào mức độ an toàn của công ty bạn). Cũng có những ngôn ngữ mà việc kết nối trình gỡ lỗi chỉ mất quá nhiều thời gian hoặc có thể không có trình gỡ lỗi tốt.

Nếu bạn đã mã hóa tất cả cùng với việc sử dụng logic và ghi nhật ký mức gỡ lỗi / theo dõi thì đó có thể chỉ là trường hợp kiểm tra các báo cáo nhật ký xuất sắc của bạn (Có thể tăng mức nhật ký) để tìm ra vấn đề mà không cần truy cập vào phần cứng.

Mặc dù tôi nghĩ trình gỡ lỗi là một công cụ mạnh mẽ, nhưng đừng để chúng là công cụ duy nhất trong hộp công cụ của bạn!

Không có lý do tại sao bạn không thể sử dụng trình gỡ lỗi trong IDE cùng với trình soạn thảo văn bản độc lập. Tôi đã từng sử dụng! Zap để chỉnh sửa, JBuilder để gỡ lỗi trên một máy khác và một máy chủ tệp trong tầng hầm. Theo truyền thống, các trình gỡ lỗi là các chương trình độc lập mà không kéo theo IDE và điều đó cũng hoạt động.

Điều đáng chú ý là thử nghiệm toàn diện thay thế gỡ lỗi. Đáng để xem xét một lỗi được báo cáo là một lỗi trong thử nghiệm của bạn chứ không phải trong mã của bạn.

Cũng có printf. Nó có thể hữu ích để tạo ra một lượng lớn "đăng nhập" và tìm kiếm thông qua nó, thay vì dừng lại cho mỗi dòng. Tôi thấy đặc biệt hữu ích nếu bạn có thể sửa đổi các lớp thư viện mà bạn không thể sửa đổi trong sản xuất, ví dụ như sử dụng -Xbootclasspath/p:để hack các lớp thư viện Java.

Đồng ý rằng vấn đề tốt nhất có thể được giải quyết khỏi máy tính bằng bút và giấy hoặc chỉ nghĩ về vấn đề. Điều này hữu ích hơn so với sử dụng trình gỡ lỗi trực tiếp. Nó thường sửa chữa quá trình suy nghĩ của bạn.

Bạn có thể sử dụng pudb là một giao diện điều khiển dựa trên giao diện người dùng đơn giản. Bạn có thể chọn trình gỡ lỗi ưa thích của mình như pdb hoặc ipdb nếu bạn muốn nhập REPL và kiểm tra chi tiết hơn.

Ngoài ra, vui lòng kiểm tra PythonDebuggingTools Wiki để có bộ sưu tập các công cụ toàn diện hơn.