(评论)
(comments)

原始链接: https://news.ycombinator.com/item?id=43974026

Hacker News 上讨论了 bug 的分类和调试策略。一位评论者建议在深入调试之前,先仔细考虑究竟哪里出了问题,将其称为“第零步”。另一位评论者建议使用二分查找法,将 bug 限制在已知的好状态和坏状态之间。评论中提到了常用弱点枚举 (CWE) 作为理解 bug 类型的一种资源。 几条回复都集中在测试方面。一个用户描述了自动化系统重运行以查找 bug 的方法,并因此受到了赞扬,认为他实际上发明了集成测试。这引发了关于单元测试与集成测试的讨论,一些人将最初评论者的行为解读为单元测试。修复 bug 后添加回归测试的价值也得到了强调,因为它可以防止 bug 再次出现。该讨论突出了这样一种普遍的经验:在解决实际问题时,人们会独立地发现已建立的软件开发实践。

相关文章
  • (评论) 2025-05-11
  • (评论) 2025-05-08
  • (评论) 2025-05-13
  • (评论) 2025-05-11
  • (评论) 2025-05-13

  • 原文
    Hacker News new | past | comments | ask | show | jobs | submit login
    A Taxonomy of Bugs (ruby0x1.github.io)
    49 points by lissine 1 day ago | hide | past | favorite | 20 comments










    Here's a step 0 for your debugging strategy: spend a few minutes thinking about what could account for the bug. Prior to its occurrence, you are thinking about what could go wrong, but now you are thinking about what did go wrong, which is a much less open-ended question.


    I've had large success by treating the bug as a binary search problem as soon as I identify an initial state that's correct and a terminal state that's incorrect. It seems like a lot of work, but that's underestimating just how fast binary searches are.

    Depends of course on the nature of the bug whether it's a good strategy.



    There's also the Common Weakness Enumeration (CWE), a long-running taxonomy of software weaknesses (meaning types of bugs).

    https://cwe.mitre.org/



    A subcategory of the design flaw I find quite a lot is the case where the code works exactly as intended, it's just not having the desired effect because of some erroneous premise.


    The Third-Party Bug

    Is the party responsible for the bug bigger than you? If yes, it's your problem. If no, it's their problem.



    John Carmack uses a debugger


    I was such a bad developer that I realized I had to automate the re-running of parts of the system to find the bugs.

    Of course, the code I wrote to exercise the code I wrote had bugs, but usually I wouldn't make offsetting errors.

    It didn't fix all the problems I made, but it helped. And it helped to have the humility when trying to fix code to realize I wouldn't get it the first time, so should automate replication



    > I had to automate the re-running of parts of the system to find the bugs

    Congratz, you've independently invented integration tests.



    I don't always test but adding a lil test after finding and fixing a bug so you don't end up there again a second time is a great practice


    Congratz, you've invented regression tests.


    Congrats, you've found someone who failed to invoke a buzzword that you know.

    EDIT: But Acktshally `the code I wrote to exercise the code I wrote` is a description of "Unit Testing", not integration testing.



    Unit/integration tests are anything but a buzzword. And my intentions were not to belittle, but to praise.

    Some actions simply make so much sense to do, that any sensible person (unaware of the concept) will start doing them given enough practice, and in process they "reinvent" a common method.



    As far as you knew that guy was aware what Unit Testing was since well before you were born. lol. I'm sure he appreciates all your nice compliments.


    Good thing he has knights in shining armor like you to defend him from my nasty insults.


    Good thing you can admit what you were doing.


    Good thing you can understand sarcasm.


    but your sarcasm was truthful.


    but it wasn't.


    Well in that case...Congratz, you've invented sarcasm.


    > And my intentions were not to belittle, but to praise.

    With the stock eyeroll dismissal phrase.







    Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact



    Search:
    联系我们 contact @ memedata.com