Lập trình viên thực sự sử dụng trình gỡ lỗi? [đóng cửa]

Nếu lập trình viên có kinh nghiệm thực sự từng sử dụng trình gỡ lỗi, và nếu vậy trong hoàn cảnh nào. Mặc dù trong câu trả lời cho câu hỏi đó tôi đã nói "tháng" trước đây có lẽ tôi có nghĩa là "năm" - tôi thực sự không sử dụng trình gỡ lỗi. Vì vậy, câu hỏi trả lời cụ thể của tôi là trong trường hợp nào, bạn sẽ là một lập trình viên có kinh nghiệm sử dụng trình gỡ lỗi?

Tôi sẽ nói rằng không sử dụng một trình sửa lỗi là một dấu hiệu của thiếu kinh nghiệm. Bước qua từng dòng mã là cách tốt nhất để theo dõi luồng thực thi.

Tôi sử dụng trình gỡ lỗi thường xuyên, bởi vì tôi làm việc trên một hệ thống lớn và do đó tôi rất tệ. http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

Cho dù mã của bạn ngắn và thường xuyên đọc như thế nào, luôn có khả năng nó sẽ có lỗi. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-gầnly.html

Sai lầm là con người và người ta không bao giờ có thể chứng minh rằng một chương trình là chính xác, vậy tại sao không sử dụng các công cụ như trình gỡ lỗi / kiểm tra tự động để hỗ trợ chúng ta trong công việc khó khăn này?

Nếu mã đủ ngắn, thì các thử nghiệm đơn giản sẽ làm. Ngoài ra, nếu nó ngắn và bạn biết bản chất của lỗi, việc đọc mã có thể là đủ. Tuy nhiên, một khi cơ sở mã lớn, bao gồm nhiều ngôn ngữ được trộn lẫn với nhau, cộng với 3 tầng, thì bạn chỉ cần có phạm vi kiểm tra tốt ở nhiều cấp độ cộng với trình gỡ lỗi rất tốt - nếu không bạn sẽ lãng phí rất nhiều thời gian.

Vì vậy, khi nào tôi không cần một trình sửa lỗi?

Tôi không phải là lập trình viên thông minh nhất, cũng không phải là người có kinh nghiệm nhất, nhưng đôi khi, tôi không cần sử dụng trình gỡ lỗi. Đó là khi:

• Mã này là của tôi hoặc được viết tốt VÀ
• Nó được viết bằng ngôn ngữ dễ đọc VÀ
• Dự án tổng thể là nhỏ.

Khi nào tôi dựa vào trình gỡ lỗi rất nhiều?

• Trả lời ngắn gọn: thường xuyên .
• Khi một ứng dụng gặp sự cố. Đặc biệt khi nó được triển khai. Việc cài đặt VS2010 trên máy tính đó có thể tạo ra sự khác biệt giữa "Lỗi không xác định" và FileNotFoundException.
• Khi thư viện bên thứ 3 gặp sự cố hoặc hoạt động sai.
• Khi mã được viết kém. Đặc biệt, nếu cùng một tập tin được chạm vào bởi 10 người khác nhau trong 10 năm qua, 7 trong số đó không còn với công ty.
• Khi dự án lớn
• Khi mã khá nguyên khối.
• Khi có một số tầng (GUI, SQL, BL) tham gia.

Lưu ý rằng "trình gỡ lỗi" có thể tham chiếu đến nhiều hơn một công cụ. Tôi sử dụng trình gỡ lỗi Visual Studio, trình gỡ lỗi SQL (chủ yếu cho các procs được lưu trữ) và SQL profiler (để tìm ra SP nào đang được gọi). Tôi có cần các công cụ của tầm cỡ này không? Tôi đang viết một kịch bản Python sysadmin-ish nhanh chóng? Không. Nếu tôi tạo công cụ dựa trên GUI nhỏ của riêng mình? Phụ thuộc. Nếu đó là .Net WinForms - có thể không. Nếu đó là WPF - có.

Điều gì định nghĩa một lập trình viên "thực sự" nào? Một trong đó là nhanh chóng? có kiến ​​thức? Có giỏi thuật toán không? Viết tài liệu tốt? Chỉ khi nào chính xác một người tốt nghiệp vào danh hiệu mới này? Khi nào một người vượt qua dòng ma thuật?

Tôi có thể nói rằng một lập trình viên không bị bẩn tay trong nỗ lực hơn 100 năm hiện tại đã không có cơ hội bị hạ thấp bởi sự phức tạp và giới hạn của chính mình (cũng như thất vọng với chất lượng mã).

Cá nhân tôi cố gắng sử dụng trình gỡ lỗi tốt nhất có sẵn cho tôi và tôi có xu hướng sử dụng nó thường xuyên. Nếu một tác vụ đủ đơn giản và không yêu cầu trình gỡ lỗi - thì tôi không sử dụng nó. Không mất quá nhiều thời gian để tính xem tôi có cần hay không.

...

Bây giờ, về lý thuyết tôi có thể đọc cơ sở mã quá lâu, rằng tôi sẽ chỉ nhận được nó. Tuy nhiên, phương pháp thực hành hoạt động tốt nhất, cộng với tôi thường muốn viết lại mã ngu ngốc mà tôi đang thấy. Thật không may, tôi sẽ mất hơn 10 năm để dọn sạch cơ sở mã mà tôi đang ở. Vì vậy, sử dụng trình gỡ lỗi là bước đầu tiên rõ ràng. Chỉ khi tôi phát hiện ra một trong số 5 triệu dòng mã đang hoạt động, tôi mới quét tệp lên và xuống để cố gắng tìm hiểu xem lớp đó đang làm gì.

"Tôi không thích trình gỡ lỗi. Không bao giờ có, có lẽ sẽ không bao giờ." - Linus Torvald

Mặt khác, anh ấy không có tài khoản Stack Overflow, vì vậy tôi không chắc bạn có quan tâm đến ý kiến ​​của anh ấy không :)

Vì vậy, câu hỏi trả lời cụ thể của tôi là trong trường hợp nào bạn, với tư cách là một lập trình viên có kinh nghiệm, sẽ sử dụng trình gỡ lỗi?

• Khi bạn không thể "gỡ lỗi" bằng cách đọc mã của mình.
• Khi bạn không thể dự đoán giá trị nào thì các biến nhất định có thời gian nhất định.
• Khi mô hình tinh thần của mã của bạn không phù hợp với đầu ra được cung cấp bởi mã của bạn

Biên tập:

Tôi đã có may mắn / bất hạnh khi không biết cách sử dụng trình gỡ lỗi trong hành trình lập trình của mình. Vì vậy, trong quá khứ tôi đã buộc phải gỡ lỗi mà không có trình gỡ lỗi. Tuy nhiên, sau khi học cách sử dụng trình gỡ lỗi -> Tôi đã trở nên hiệu quả hơn gấp 100 lần trong việc tìm lỗi.

Để đưa ra một quan điểm hơi khác với các câu trả lời hiện tại; Là một kỹ sư phần mềm nhúng làm việc trên các hệ thống thường có thành phần thời gian thực, tôi hiếm khi sử dụng trình gỡ lỗi.

Đôi khi, trình gỡ lỗi có thể là một công cụ tuyệt vời và bất cứ khi nào tôi có thể xây dựng và chạy mã trên máy tính để bàn thì tôi sẽ luôn sử dụng trình gỡ lỗi.

Trên chip, với các ràng buộc thời gian thực, sau đó có một gánh nặng lớn liên quan đến việc cố gắng sử dụng trình gỡ lỗi. Ngay khi bạn tạm dừng thực thi, bạn có khả năng buồn bã, có thể gây tử vong, thời gian của phần còn lại của hệ thống. Nói chung trên chip, printf trong mã không quan trọng và IO vẫy trong mã quan trọng thời gian là công cụ tốt nhất và thực sự đơn giản nhất. Nó không tốt như trình gỡ lỗi, nhưng rẻ hơn nhiều khi làm việc với một hệ thống thực sự.

Tôi nghĩ rằng các lập trình viên có kinh nghiệm hầu như chỉ sử dụng trình gỡ lỗi, khi họ cần thiết. Cách nào tốt hơn để theo dõi một lỗi hơn là thực sự tuân theo việc thực thi mã ...

Bạn có theo giả định rằng Skeets của thế giới không phạm sai lầm hay chỉ biết mọi thứ? Tất cả trừ những chương trình tầm thường nhất đều hành xử theo những cách bất ngờ trong một số trường hợp. Nó được đưa ra rằng các vấn đề sẽ phải được điều tra. Vì vậy, các lựa chọn là sử dụng các câu lệnh in, ở một đầu của phổ hoặc xem xét xem điều gì đã xảy ra, mặt khác, hoặc nhìn vào giữa khi mã thực thi và tìm hiểu điều gì đang xảy ra.

Có lẽ một cách tốt hơn để suy nghĩ về nó là các lập trình viên có kinh nghiệm biết khi nào nên sử dụng một trình gỡ lỗi. Trong mã với một vài phụ thuộc nhìn vào dấu vết ngăn xếp có lẽ là đủ để tìm ra điều gì sai. Nhưng có những kịch bản phức tạp khi mã của bạn hoạt động với mã khác và bạn cần một trình gỡ lỗi để xem nội dung bạn không viết.

Tôi không, và tôi đã lập trình được hơn 10 năm. Tôi đã từng, khi tôi lập trình trong c / c ++. Bây giờ tôi lập trình trong java. Sự thật là nếu bạn đang đăng nhập chính xác, bạn sẽ kết thúc với một dấu vết ngăn xếp đủ cho hầu hết các nhà phát triển lành nghề. Ngoài ra nếu bạn đang viết các bài kiểm tra đơn vị (tốt) và kiểm tra chức năng, loại bỏ cả một lớp lỗi.

Ai quan tâm? Những gì tôi muốn biết là việc sử dụng một trình gỡ lỗi sẽ ngăn tôi trở thành một lập trình viên tốt hơn trong dài hạn? Có thể các trình sửa lỗi có chất lượng thấp hơn khi nhiều nhà phát triển có kinh nghiệm bắt đầu nên chúng là một trở ngại. Đó có phải là một cái nạng ngăn cản sự hiểu biết sâu sắc hơn?

Một số lập trình viên, có lẽ tốt hơn so với phần còn lại của chúng tôi, thấy cần một trình gỡ lỗi và xây dựng một trình lập trình (Không biết ai đã tạo ra cái đầu tiên.). Tôi chắc chắn rằng họ đã làm việc hiệu quả hơn nhờ nó. Tôi nghi ngờ động lực là để cho phép những người chết ít hơn viết mã.

Ít khi.

Các phương pháp của bạn phải nhỏ / đủ đơn giản để được biên dịch và chạy theo tâm trí của bạn, các bài kiểm tra đơn vị sẽ bao gồm chức năng. Nếu bạn tìm thấy một lỗi, viết một bài kiểm tra. Chạy nó, sửa nó.

Tôi chỉ có xu hướng sử dụng trình gỡ lỗi khi tôi có hành vi bất ngờ từ mã không thể kiểm chứng, như khung công tác ASP.NET.

Trong Smalltalk, tôi phát triển gần như hoàn toàn trong trình gỡ lỗi:

1. Viết một bài kiểm tra mà tôi biết sẽ thất bại.
2. Chạy thử nghiệm. Khi nó thất bại, trình gỡ lỗi bật lên.
3. Viết, trong trình gỡ lỗi, mã cần thiết để thực hiện kiểm tra vượt qua.
4. Tiếp tục thực hiện.
5. Nếu tôi bật đèn xanh, hãy đến bước 1 với bài kiểm tra thất bại mới. Nếu không, trong trình gỡ lỗi tìm ra những gì tôi đã làm sai và sửa nó.

Tôi sử dụng một trình sửa lỗi khi tôi cần. Đó không phải là hàng ngày, nhưng nó xảy ra đôi khi. Đôi khi tốt hơn là bước qua mã để xem chính xác những gì xảy ra.

Tôi phải thừa nhận tôi sử dụng trình gỡ lỗi ngày càng ít. Tôi đã phát triển ở Delphi hơn 10 năm. Tôi cũng viết các thủ tục được lưu trữ trong PL / SQL. Kể từ vài tháng, tôi cũng là một nhà phát triển PHP.

Tôi chủ yếu sử dụng trình gỡ lỗi trong một trong hai trường hợp này nếu tôi tìm thấy một đoạn mã tối nghĩa được viết từ nhiều năm trước và tôi cần sửa đổi nó. Đôi khi nó giúp tìm ra cách chính xác một chương trình hoạt động nếu khó đọc mã. Trong PHP hầu như không bao giờ cần thiết, nhưng trong Delphi, dựa trên sự kiện, đôi khi nó giúp ích khi bạn có một khung công tác phức tạp.

Nhưng như bạn nói, sử dụng trình gỡ lỗi là một ngoại lệ. Hầu hết các vấn đề được giải quyết bằng cách chỉ đọc mã và sửa bất kỳ lỗi nào bạn (hoặc người khác) đã mắc phải.

Nhưng điều đó đi cho bước qua mã. Tôi thường sử dụng ngăn xếp cuộc gọi khi có ngoại lệ xảy ra và thỉnh thoảng tôi đặt một điểm dừng ở đâu đó để kiểm tra một biến. Nhưng gần như luôn luôn trong một đoạn mã cần tái cấu trúc kỹ lưỡng.

Tôi thỉnh thoảng mã không có trình gỡ lỗi, nhưng chỉ khi bị buộc phải ở gunpoint, tức là. di sản nhúng gunge trên 8051 hoặc Z80.

IMHO, bạn cần một trình gỡ lỗi và đăng nhập vào bất kỳ công việc phức tạp nào. Một lần không phải là một thay thế cho khác. Ví dụ, một hệ thống ghi nhật ký không thể trợ giúp nếu ứng dụng nhét vào trình điều khiển, ví dụ, điều duy nhất mà mã có thể làm là tương tác với phần cứng và thiết lập một semaphore.

Trình gỡ lỗi không thể giúp khắc phục lỗi hệ thống trong đó các ứng dụng hoạt động tốt theo cách bạn đã viết, nhưng hệ thống vẫn không hoạt động do một số lỗi giao thức comms không liên tục.

Vì vậy, tôi cần trình gỡ lỗi để loại bỏ các lỗi ngu ngốc, chói lóa và phần cứng. Tôi cần đăng nhập tốt để bắt lỗi tích hợp hệ thống không liên tục.

Tôi phải có cả hai - tôi cần tất cả sự giúp đỡ tôi có thể nhận được!

Tôi chỉ sử dụng trình gỡ lỗi khi các bước này không thành công:

1. Nhận lỗi tái sản xuất. Hãy suy nghĩ. Đây thường là tất cả những gì cần thiết.
2. Kiểm tra bất kỳ dấu vết ngăn xếp và nhật ký.
3. Thêm đăng nhập xung quanh mã vi phạm.

Các bước này chăm sóc 95% của tất cả các trường hợp. Điều đó có nghĩa là tôi hiếm khi sử dụng trình gỡ lỗi và khi tôi làm điều đó, nó có xu hướng cung cấp cho tôi quá nhiều thông tin và tôi bị sa lầy vào các chi tiết không liên quan. Điều này đặc biệt đúng nếu làm việc trên một hệ thống đa luồng, thời gian thực.

Vì vậy, các báo cáo đăng nhập được đặt một cách thận trọng đi một chặng đường dài.

Có thể chỉ đơn giản là các lập trình viên rất có kinh nghiệm cũng giống như các lập trình viên rất già, và họ đã học lập trình, và hình thành thói quen của họ, trở lại khi trình gỡ lỗi không phải lúc nào cũng có sẵn, và đôi khi không tốt lắm?

Nếu bạn thực sự giỏi trong việc gỡ lỗi printf (và trở lại những năm tám mươi, chúng tôi không có nhiều sự lựa chọn ngoài việc trở nên thực sự giỏi về nó), có lẽ một trình gỡ lỗi không thêm nhiều như vậy.

Đó là một câu hỏi về sự lựa chọn cá nhân.

Thành thật tôi nghĩ rằng trình gỡ lỗi rất hữu ích trong các tình huống xác nhận trong đó nó giúp ích rất nhiều cho việc biết những gì trên ram của bạn tại bất kỳ bước nào trong quá trình thực thi chương trình của bạn.

Tiện ích chính của trình gỡ lỗi là tạm dừng chương trình mà không có chương trình được thiết kế để tự dừng lại: tính năng này khá quan trọng.

Ngoài 2 tính năng đó, tôi không nghĩ trình gỡ lỗi là thực sự cần thiết; bất kỳ chương trình phức tạp nào bạn thực hiện nên có một số chế độ "dài dòng", nghĩa là nói mọi thứ nó đang thực hiện với printf hoặc std :: cout, lựa chọn nào đã thực hiện và rất nhiều tham số khác.

Chỉ cần tưởng tượng bạn tạo một chương trình và người dùng có vấn đề khi sử dụng nó: làm thế nào để biết liệu anh ta có đang sử dụng nó theo cách nó được thiết kế để sử dụng hay không, nếu điều anh ta phàn nàn có thể là một lỗi?

Trình gỡ lỗi giống như hệ thống lái điện cho xe hơi của bạn: sẽ thoải mái hơn khi có một chiếc, nhưng nó sẽ không làm cho ổ đĩa của bạn tốt hơn.

Progamming là về thiết kế và logic, cách các công cụ có thể hỗ trợ bạn trong việc theo dõi công cụ không giúp bạn trở thành một lập trình viên tốt hơn.

Trình gỡ lỗi cộng là hữu ích cho các ngôn ngữ được biên dịch, ít hơn nhiều đối với các ngôn ngữ không được chú ý.