Lợi ích của việc tránh sử dụng trình gỡ lỗi là gì?

Trong suốt sự nghiệp của mình, tôi đã nhận thấy rằng một số nhà phát triển không sử dụng các công cụ gỡ lỗi, nhưng hãy kiểm tra tại chỗ trên mã lỗi để tìm ra vấn đề là gì.

Mặc dù nhiều lần có thể nhanh chóng tìm ra lỗi trong mã mà không cần trình sửa lỗi là một kỹ năng tốt, nhưng có vẻ như sẽ không hiệu quả khi dành nhiều thời gian để tìm kiếm các vấn đề khi trình gỡ lỗi sẽ dễ dàng tìm thấy các lỗi nhỏ như lỗi chính tả.

Có thể quản lý một phức tạp mà không cần một trình sửa lỗi? Có nên khuyên không? Những lợi ích nào có được bằng cách sử dụng " gỡ lỗi tâm linh ?"

Những gì trông giống như đoán từ bên ngoài thường hóa ra là cái mà tôi gọi là "gỡ lỗi trong tâm trí bạn". Theo một cách nào đó, điều này tương tự như khả năng chơi cờ của các đại kiện tướng mà không cần nhìn vào bàn cờ.

Đó là bởi đến nay gỡ lỗi kỹ thuật hiệu quả nhất mà tôi biết, bởi vì nó không đòi hỏi một trình gỡ lỗi gì cả. Bộ não của bạn khám phá nhiều đường dẫn mã cùng một lúc, mang lại khả năng quay vòng tốt hơn mức bạn có thể có với trình gỡ lỗi.

Tôi đã không ý thức về kỹ thuật này trước khi bước vào thế giới lập trình cạnh tranh một thời gian ngắn , trong đó sử dụng trình gỡ lỗi có nghĩa là mất đi những giây quý giá. Sau khoảng một năm thi đấu, tôi bắt đầu sử dụng kỹ thuật này gần như chỉ là tuyến phòng thủ ban đầu của mình, sau đó là ghi nhật ký gỡ lỗi, với việc sử dụng một trình gỡ lỗi thực tế ở vị trí thứ ba xa xôi. Một tác dụng phụ hữu ích của thực tiễn này là tôi bắt đầu thêm các lỗi mới với tốc độ chậm hơn, bởi vì "gỡ lỗi trong tâm trí tôi" không dừng lại khi tôi viết mã mới.

Tất nhiên phương pháp này có những hạn chế của nó, chủ yếu là do những hạn chế của tâm trí một người trong việc hình dung nhiều đường dẫn thông qua mã. Tôi đã học cách tôn trọng những hạn chế này trong tâm trí của mình, chuyển sang một trình sửa lỗi để sửa lỗi trong các thuật toán tiên tiến hơn.

Tôi càng biết nhiều cơ sở mã, tôi càng cần ít trình gỡ lỗi (nhưng tôi vẫn kiểm tra lỗi được báo cáo, đó là một đầu mối quan trọng trong mọi lý do).

Nó là một công cụ tốt để hiểu một số hành vi động có độ phức tạp nhỏ đến trung bình, nhưng tôi thường phát hiện ra rằng nó tập trung vào tôi vào các chi tiết thay vì bức tranh lớn hơn. Và sau một thời gian, đó là vấn đề: trong các tương tác phạm vi rộng hơn mà hành vi động của họ có xu hướng dễ hiểu hơn với các công cụ khác (ví dụ: ghi nhật ký đầu vào và đầu ra ở ranh giới mô-đun).

Họ có thể không phải là lập trình viên tồi, nhưng có lẽ họ là những người gỡ rối kém hiệu quả.

Tôi có xu hướng làm theo lời khuyên từ Gỡ lỗi: 9 quy tắc không thể thiếu để tìm kiếm ngay cả những vấn đề phần mềm và phần cứng khó nắm bắt nhất (David Agans), và điều này rơi thẳng vào hướng dẫn của "Thoát khỏi suy nghĩ và nhìn"

Bất kỳ công việc đòi hỏi phải sử dụng đúng công cụ đúng cách. Nếu bạn có một trình gỡ lỗi thì hãy sử dụng nó để xem những gì đang thực sự xảy ra. Hầu hết các lỗi được gây ra bởi các giả định.

Tôi đã làm việc với các nhà phát triển từ chối sử dụng trình gỡ lỗi vì họ biết rõ hơn. Câu trả lời kinh điển mà tôi nhận được một lần là "sự cố không phải do tôi gây ra, tôi đã dành cả ngày để kiểm tra mã [nơi nó bị sập] và không có gì sai". (Điều gì về giá trị null được đọc từ db?) Ông chủ dường như nghĩ rằng đó là một câu trả lời tuyệt vời nhưng khách hàng thì không.

Tôi rời đội đó nhanh nhất có thể. Mục đích của họ là làm hỏng công việc và biến một vấn đề đơn giản trong 10 phút thành một vấn đề bận rộn cả ngày.

Hướng dẫn tốt nhất của bạn về thực hành gỡ lỗi là cuốn sách Code Complete của Steve McConnel . Chương 23 bao gồm gỡ lỗi chi tiết, và tôi sẽ chắt lọc một vài điểm từ nó.

1. Hiểu vấn đề là quan trọng và việc sử dụng trình gỡ lỗi không phải là sự thay thế cho nó.
2. Đoán là một cách tiếp cận xấu để gỡ lỗi. Nếu đồng nghiệp của bạn thực sự sử dụng phỏng đoán, thay vì suy nghĩ về vấn đề, thì họ đang làm một công việc tồi tệ. Đoán có nghĩa là dán các câu lệnh in ngẫu nhiên trong mã và hy vọng tìm thấy một cái gì đó hữu ích.
3. Nếu đồng nghiệp của bạn thực sự không biết cách sử dụng trình gỡ lỗi (thay vì chọn không sử dụng trình gỡ lỗi) thì có, họ không đủ năng lực, giống như ai đó không biết cú pháp của ngôn ngữ mà họ sẽ sử dụng.

Khó nói. Gỡ lỗi bằng cách đoán có thể hoạt động nếu bạn đã có ý tưởng về lỗi là gì (giá trị không chính xác được truyền cho hàm thư viện, có thể là SQL không hợp lệ, v.v.). Tôi thừa nhận đôi khi tôi làm điều đó khi lỗi có vẻ nhỏ hoặc rõ ràng, chẳng hạn như "bộ đệm ký tự quá nhỏ" - dấu vết ngăn xếp cho tôi thấy dòng nó bị lỗi và tôi không cần trình gỡ lỗi để giải quyết lỗi đó.

Làm điều này mọi lúc có thể phản tác dụng và nếu một vài lần "đoán" đầu tiên thất bại, đoán có lẽ là chiến lược giải quyết vấn đề sai và một trình gỡ lỗi thực sự nên được gọi. Thông thường, tôi nói hoàn toàn không có gì sai khi sử dụng trình gỡ lỗi .

Điều đó đã được nói, tôi đã làm việc với các công cụ và môi trường nơi trình gỡ lỗi rất khó để làm việc đúng, hoặc rất nhỏ và vô dụng đến nỗi việc đoán không may thường là một cách tiếp cận tốt hơn. Tôi đã làm việc với một số công cụ độc quyền thậm chí không có trình gỡ lỗi thích hợp. Tôi cho rằng có thể là nếu một người làm việc trong những môi trường như vậy quá lâu thì cuối cùng họ sẽ mất niềm tin vào những người sửa lỗi và tin tưởng vào cách tiếp cận đoán.

Tôi ngạc nhiên rằng các cuộc thảo luận về chủ đề này đã không đề cập đến "thử nghiệm đơn vị".

Bởi vì tôi phát triển dựa trên thử nghiệm, tôi không dành nhiều thời gian cho trình gỡ lỗi. Cách đây 10 năm, tôi đã từng mạnh dạn bước qua trình gỡ lỗi:

1. Sau khi viết một đoạn mã để đảm bảo rằng nó hoạt động và
2. Khi tôi nhận được một báo cáo lỗi để cố gắng chẩn đoán vấn đề

Điều tôi đã tìm thấy sau 10 năm phát triển dựa trên thử nghiệm là tôi sẽ làm việc rất hiệu quả hơn khi là một lập trình viên nếu:

1. Tôi viết các bài kiểm tra đơn vị trước khi tôi viết mã để đảm bảo rằng tôi đã viết đúng
2. Tôi viết các bài kiểm tra đơn vị ngay lập tức khi nhận được báo cáo lỗi để cố gắng sao chép và đi sâu vào vấn đề.

Cho phép máy tính chạy mã và xác thực kết quả nhanh hơn hàng nghìn lần so với tôi có thể nghĩ hoặc bước qua mã để xác thực tinh thần kết quả và không mắc lỗi.

Thỉnh thoảng tôi vẫn phải tiếp tục trình gỡ lỗi và tôi vẫn tham gia vào việc phân tích tinh thần mã ... nhưng chỉ hiếm khi, và chủ yếu là cho mã rất phức tạp.

Cá nhân, tôi cố gắng giảm thiểu việc sử dụng trình gỡ lỗi bằng cách:

• sử dụng trình kiểm tra tĩnh và các tùy chọn trình biên dịch tương tự gợi ý các nguồn lỗi có thể xảy ra chỉ bằng cách phân tích mã
• viết mã với càng ít tác dụng phụ càng tốt, theo kiểu chức năng nhất có thể, loại bỏ trạng thái có thể thay đổi khi có thể
• viết bài kiểm tra đơn vị với độ chi tiết hợp lý tối thiểu
• không nuốt ngoại lệ

Tất nhiên, mọi người đều mắc lỗi, vì vậy ngay cả khi soạn chương trình theo cách này, nếu thử nghiệm thất bại, tôi sử dụng trình gỡ lỗi để kiểm tra giá trị của biểu thức trung gian. Nhưng bằng cách tuân thủ các nguyên tắc trên, khiếm khuyết sẽ dễ dàng xác định hơn và gỡ lỗi không có nghĩa là một quá trình đau đớn, không xác định.

Sử dụng trình gỡ lỗi bất cứ khi nào có thể. Trình gỡ lỗi sẽ chỉ đơn giản là khắc phục sự cố (ồ, chúng tôi đã không kiểm tra giá trị này) hoặc cung cấp rất nhiều bối cảnh hữu ích khi phân tích mã có liên quan (wow, ngăn xếp hoàn toàn bị rối, tôi sẽ có thể là một vấn đề tràn bộ đệm).

Gỡ lỗi là một công cụ rất hữu ích để kiểm tra trạng thái của các đối tượng và các biến trong mã của bạn trong thời gian chạy.

Như đã đề cập trước đây trong các câu trả lời ở trên, gỡ lỗi là cực kỳ hữu ích, nhưng có một số trường hợp bị hạn chế.

Theo kinh nghiệm của tôi, tôi thấy việc sử dụng trình gỡ lỗi rất hữu ích vì nó giúp tiết lộ các giả định sai mà tôi đang đưa ra về trạng thái mã của mình. Một số người không thông minh khi đọc mã để tìm lỗi, vì vậy việc gỡ lỗi có thể giúp tiết lộ các giả định sai mà bạn hoặc nhà phát triển khác đưa ra về trạng thái của mã.

Có thể bạn mong đợi rằng một tham số sẽ không bao giờ là null khi được truyền cho một phương thức, vì vậy bạn không bao giờ kiểm tra trường hợp đó và tiếp tục trong phương thức như thể tham số đó sẽ không bao giờ là null. Thực tế là tham số đó cuối cùng sẽ trở thành null ngay cả khi bạn đặt làm điều kiện tiên quyết cho phương thức mà tham số không bao giờ nên null. Nó sẽ luôn xảy ra.

Trái ngược với tính hữu dụng của trình gỡ lỗi trong các ví dụ đã nói ở trên, tôi thấy khó sử dụng và có phần không hữu ích khi sử dụng đa luồng (nghĩa là xử lý đồng thời, xử lý không đồng bộ). Nó có thể giúp ích, nhưng rất dễ để mất định hướng của bạn trong sương mù đa luồng khi các điểm dừng của trình gỡ lỗi đang bị tấn công trong một luồng tại điểm A và một luồng hoàn toàn riêng biệt tại điểm B. Nhà phát triển buộc phải đẩy điểm dừng mới " quá trình suy nghĩ "trên đỉnh" ngăn xếp "của bộ não và tự hướng đến mã ở điểm dừng mới. Sau khi mức độ liên quan của điểm dừng B giảm, nhà phát triển sau đó chuyển trở lại điểm dừng đầu tiên và phải nhớ lại những gì anh ta / cô ta đang tìm kiếm trước khi kích hoạt điểm dừng B. Tôi biết rằng đây có thể là một lời giải thích khó hiểu,

Ngoài ra, việc không thể đoán trước được mã đồng thời có thể khiến nhà phát triển mất tập trung hơn trong việc gỡ lỗi mã đồng thời.

Tóm lại, theo ý kiến ​​trung thực của tôi:

• Gỡ lỗi khi sử dụng đồng thời = xu hướng tăng mất tập trung vào "mô hình suy nghĩ gỡ lỗi"

và

• bất cứ lúc nào khác = tăng năng suất gỡ lỗi b / c sự chú ý của bạn không bị gián đoạn bởi các điểm dừng bất ngờ (bất ngờ do điều kiện cuộc đua).

Tôi nghĩ rằng họ là một chút quá khó khăn. Cá nhân khi tôi gặp lỗi, tôi kiểm tra lại mã, cố gắng theo dõi nó trong tâm trí của tôi từ logic chương trình, bởi vì điều đó đôi khi giúp tôi phát hiện ra các vấn đề khác hoặc tác dụng phụ dễ dàng hơn là chỉ sử dụng trình gỡ lỗi và sửa lỗi trong đó nó tự biểu hiện .

Ngay cả khi tôi nghĩ rằng tôi đã đóng đinh nó, tôi thường gỡ lỗi nó để đảm bảo rằng tôi đúng. Khi vấn đề phức tạp hơn một chút, tôi tin rằng việc gỡ lỗi là hoàn toàn cần thiết.

Ngoài ra ... chỉ là ý kiến ​​của tôi, nhưng, không có lý do gì để không tận dụng lợi thế của các công cụ mà một IDE hiện đại có thể mang đến cho bàn. Nếu nó giúp bạn hoàn thành công việc của mình nhanh hơn và theo cách đáng tin cậy hơn, bạn nên sử dụng nó.

Ghét để khái quát, nhưng nhiều lập trình viên tôi đã gặp nghĩ rằng chỉ có một cách để giải quyết vấn đề (cách của họ). Thật dễ dàng để giả định rằng mọi thử nghiệm có thể đã được nghĩ đến. Một quan điểm khác nhau có thể rất có giá trị.

Lập trình bằng thử nghiệm và lỗi có thể đưa ra một số cách tiếp cận mới tuyệt vời và nắm bắt những điều mà người khác đã bỏ lỡ.

Nhược điểm, thường mất nhiều thời gian.

Erm, nó phụ thuộc vào người. Cá nhân, bản thân tôi không sử dụng trình gỡ lỗi. Khi tôi lập trình bộ điều khiển vi mô, về cơ bản tôi sử dụng đèn LED hoặc ghi dữ liệu vào EEPROM để "gỡ lỗi" mã trên nó. Tôi không sử dụng JTAG.

Khi tôi lập trình phần mềm cho PC hoặc máy chủ, tôi có xu hướng sử dụng ghi nhật ký và nhiều đầu ra giao diện điều khiển. Đối với các ngôn ngữ kiểu C, tôi sử dụng các chỉ thị tiền xử lý và trong Java tôi đã sử dụng các mức nhật ký.

Vì tôi không sử dụng trình gỡ lỗi, bạn có nói tôi đang làm gì sai không? Đó là công việc biên tập viên, để chỉ cho tôi nơi tôi có lỗi cú pháp và khi có lỗi logic, tôi chỉ phải chạy thử nghiệm.

Có một sự khác biệt giữa không cần sử dụng trình gỡ lỗi và không biết cách (hoặc từ chối) sử dụng trình gỡ lỗi. Trình gỡ lỗi chỉ là một trong nhiều công cụ để sử dụng trong việc theo dõi và sửa lỗi. Tôi đã làm việc với các nhà phát triển, những người có thể giải đố nó trong đầu và những người khác nghĩ rằng họ có thể.

Cách kết hợp tốt nhất là viết mã của bạn để dễ dàng kiểm tra thông qua các bài kiểm tra đơn vị và ghi lại các lỗi. Sau đó, bạn hy vọng bạn không cần phải xem nhật ký hoặc sử dụng trình gỡ lỗi. Nó giống như mua bảo hiểm. Bạn hy vọng không bao giờ cần sử dụng nó, nhưng một khi bạn gặp phải một lỗi không thể khắc phục bằng cách kiểm tra lại mã thì đã quá muộn để thêm xử lý lỗi / ghi nhật ký, kiểm tra đơn vị hoặc tìm hiểu cách sử dụng trình gỡ lỗi.

Các công cụ / nền tảng khác nhau ưu tiên các kỹ thuật gỡ lỗi khác nhau (trình gỡ lỗi, ghi nhật ký, kiểm tra đơn vị, v.v.) Miễn là nhà phát triển quen thuộc với một vài kỹ thuật cho nền tảng / công cụ của họ, ngoài việc chỉ kiểm tra lại mã, thì họ có thể một nhà phát triển lành nghề, nhưng nếu họ chỉ có một mẹo khi sửa lỗi thì cuối cùng họ sẽ gặp phải một lỗi mà họ không thể tìm thấy hoặc sửa chữa.

Nhiều câu trả lời, nhưng không đề cập đến Heurrorms ?!?!

Heisenbugs xảy ra do các nỗ lực chung để gỡ lỗi chương trình, chẳng hạn như chèn các câu lệnh đầu ra hoặc chạy nó trong trình gỡ lỗi, thường sửa đổi mã, thay đổi địa chỉ bộ nhớ của các biến và thời gian thực hiện của nó.

Tôi sử dụng trình gỡ lỗi, chỉ trong trường hợp xấu nhất (đối với các lỗi khó tìm). Ngoài ra, theo các thực tiễn tốt nhất mà nhiều nhà phát triển / người thử nghiệm nổi tiếng đã nói đến, thật tốt khi đơn vị kiểm tra mã kỹ lưỡng. Bằng cách đó, bạn có thể bao quát hầu hết các vấn đề và do đó sẽ không cần sử dụng trình gỡ lỗi.

Tôi đã đọc một đối số chống gỡ lỗi gỡ lỗi ở đây gần đây (hoặc đó là StackOverflow?). Bạn nên có trường hợp kiểm tra đối với mã của bạn. Nếu các thử nghiệm của bạn vượt qua, việc gỡ lỗi của bạn có thể sẽ không xảy ra lỗi (giả định: bạn sẽ gỡ lỗi với dữ liệu tương tự như dữ liệu thử nghiệm của bạn).

Mặt khác, đăng nhập là bắt buộc. Nếu bạn vượt qua các bài kiểm tra của mình và triển khai vào sản xuất, bạn có thể thấy rằng mình có một lỗi. Bằng chứng của lỗi là từ một cái gì đó đã xảy ra trong quá khứ. tức là có người nói, "Làm thế nào mà nó vào được?" Nếu bạn không có nhật ký tốt, bạn sẽ không bao giờ tìm thấy nguyên nhân. Ngay cả một trình gỡ lỗi có thể không được sử dụng tại thời điểm đó bởi vì bạn không biết dữ liệu trông như thế nào thực sự gây ra lỗi. Bạn cần có khả năng gỡ lỗi ứng dụng từ nhật ký.

Thật không may, tôi đang diễn giải khá nhiều và có thể đang làm cho đối số ban đầu trở thành một sự bất đồng. Cụ thể, vị trí "Có các trợ lý gỡ lỗi quan trọng để dành thời gian phát triển hỗ trợ" có thể trực giao với tầm quan trọng của trình gỡ lỗi. Nhưng phần về sự khó khăn trong việc thiết lập trạng thái hệ thống trong một cấu hình khiến cho việc gỡ lỗi trở nên hữu ích cho việc tìm lỗi khiến tôi phải suy nghĩ.

Với các bài kiểm tra đơn vị tốt và các trường hợp ngoại lệ cung cấp cho bạn nền tảng, bạn hiếm khi phải sử dụng trình gỡ lỗi.

Lần cuối cùng tôi sử dụng một bản sửa lỗi là khi tôi nhận được một tệp cốt lõi trong một số ứng dụng cũ.

Tôi có phải là một "minion minion" hay những kẻ này "quá khó tính"?

Cũng không. Họ chỉ là loại người thích làm cho cuộc sống của họ khó khăn hơn.

Gỡ lỗi chỉ là một công cụ mà một nhà phát triển giỏi nên sử dụng thành thạo.

Chắc chắn đôi khi bạn có thể biết trái tim lỗi ở đâu nếu bạn biết cơ sở mã. Nhưng bạn cũng có thể mất cả ngày hoặc tuần để tìm một lỗi khó chịu chỉ bằng cách xem mã.

Trong các ngôn ngữ được gõ động mà không có một số loại gỡ lỗi (ngay cả khi nó chỉ đưa các giá trị vào bảng điều khiển), việc đoán đôi khi trở nên không thể.

Vì vậy, để trả lời câu hỏi của bạn - có thể họ là những lập trình viên xuất sắc, nhưng kỹ năng xử lý sự cố và trình độ của họ khi săn lỗi rất tệ.

Phụ thuộc vào phạm vi của một vấn đề. Nếu chương trình nhỏ và mọi thứ được phân chia tốt, bạn có thể tìm ra nó bằng cách xem. Nếu chương trình là 4,5 triệu dòng mã được phát triển bởi một nhóm hơn 100 người trong vài năm thì một số lỗi nhất định sẽ không thể phát hiện ra.

Một trong câu hỏi trong chương trình nói (bằng C) là một bộ nhớ ghi đè. Trình gỡ lỗi với điểm dừng bộ nhớ đã xác định dòng mã vi phạm ngay khi lỗi xuất hiện. Nhưng trong trường hợp này, không có cách nào mà ai đó có thể đọc và giữ lại tất cả 4,5 triệu dòng mã để xác định vị trí mà ai đó đã viết qua mảng của họ (cộng với việc họ phải biết cách bố trí thời gian chạy của bộ nhớ cho trạng thái của chương trình khổng lồ khoảng 10 phút trong một thời gian dài đầu vào để đưa nó đến điểm đó).

Điểm đang tồn tại: Trong các chương trình nhỏ hoặc những thứ được mô đun hóa cao, bạn có thể thoát khỏi trình gỡ lỗi w / oa. Nếu chương trình thực sự lớn và phức tạp thì trình gỡ lỗi có thể giúp bạn tiết kiệm rất nhiều thời gian. Như những người khác đã nói, nó là một công cụ và nó có những tình huống vượt trội hơn bất kỳ phương pháp nào khác và những phương pháp khác không phải là sự lựa chọn tốt nhất.

Nếu lỗi xảy ra trong máy tính của khách hàng hoặc trong máy tính mà môi trường của nó khác nhiều so với máy tính của bạn, thì việc thiết lập trình gỡ lỗi / trình gỡ lỗi từ xa rất khó khăn. Vì vậy, đối với ngày lạnh khi bạn gặp lỗi từ trường, phản hồi của 'nhưng ... tôi không có trình gỡ lỗi' không giúp ích được gì. Do đó, bạn cần phát triển một bộ kỹ năng xử lý sự cố và tìm lỗi chỉ thông qua việc hiểu mã và tệp nhật ký.

Thật là một loạt những điều vô nghĩa: "Các lập trình viên thực sự không cần Trình gỡ lỗi." Cũng có thể nói rằng một lập trình viên thực sự không cần bất kỳ IDE nào, chỉ cần đưa cho tôi một tờ ghi chú và một cây bút chì buồn tẻ. Trình gỡ lỗi là một công cụ như bất kỳ công cụ nào khác giúp tăng năng suất.

Ngoài ra, hãy xem xét rằng không phải tất cả mọi người được giao nhiệm vụ với mã gỡ lỗi đều quen thuộc với mã đó. Nhiều nhà thầu thời gian bước vào một môi trường nơi họ chỉ có một lý tưởng chung những gì đang xảy ra. Họ thậm chí có thể được cung cấp một mô tả chi tiết về một môi trường - hoặc bản đồ lược đồ 20 năm và hướng dẫn về các quy ước đặt tên phức tạp (thử hiểu sự khác biệt giữa bảng X1234 và bảng X4312 với các trường F1, F2 và F3 [vâng, rác như thế này tồn tại] khi bạn là người mới), nhưng nhiều lần mô tả đó là sai; nếu không, tại sao có lỗi "bí ẩn".

Là một người mới làm quen với môi trường, bạn có thể dành hàng giờ hoặc hàng ngày để lập bản đồ và "biết" một cơ sở dữ liệu lớn cho một khu vực có vấn đề mà bạn có thể khắc phục và sau đó không bao giờ phải xem lại. Đây là một sự lãng phí rất lớn thời gian và tiền bạc. Nếu bạn có quyền truy cập vào trình gỡ lỗi, bạn sẽ thấy những gì đang xảy ra, sửa nó và biến mất trong vài phút. Tất cả những điều này "bạn không cần trình gỡ lỗi" hooey chỉ là nhà sản xuất tinh hoa.