哪种编程技术可以帮助您在错误投入生产之前避免或解决错误

RED*_*AIR 12 c++ architecture debugging design-patterns

我不是指外部工具.我想到了架构模式,语言结构,习惯.我最感兴趣的是C++

P.K*_*P.K 32

自动化单元测试.

  • 我发现这更好,以确保您不会破坏已有的功能,更多的是帮助您避免错误. (2认同)
  • 谁获得准确,完整的规格? (2认同)

Xia*_*ofu 20

有一种经常被人不知情的技术,我喜欢称之为QA团队,它可以在错误到达生产之前清除错误.

这是我的经验(并经常在教科书中引用),程序员不会做出最好的测试人员,尽管他们可能会想到,因为他们倾向于测试他们已经知道的编码行为.最重要的是,他们往往不太擅长将主题放在最终用户的手中(如果是那种应用程序),因此很可能忽略UI格式化/对齐/可用性问题.

是的,单元测试非常重要,我相信其他人可以提供比我更好的技巧,但不要忽视你的系统/集成测试.:)

..嘿,这是一种语言无关的技术!

  • 是! 并且很难让程序员意识到他们没有很好地测试自己的代码. (2认同)

Goz*_*Goz 16

我发现以下相当方便.

1)ASSERT.
2)可以输出到调试spew,控制台或文件的调试记录器.
3)内存跟踪工具.
4)单元测试.
5)智能指针.

我确定有很多其他的但我无法想到它们在我的头顶:)


Vin*_*vic 15

RAII避免资源泄漏错误.


blt*_*txd 14

  1. 力求简洁和简洁.
  2. 永远不要将代码行为未定义的情况留下.
  3. 寻找利用类型系统的机会,并在编译时尽可能地检查编译器.只要您保持常识,模板和代码生成就是您的朋友.
  4. 最小化单例和全局变量的数量.
  5. 使用RAII!
  6. 使用断言!
  7. 自动测试一些名义和所有角落情况.
  8. 避免像瘟疫一样的最后一刻改变.


小智 13

我用思考.


sha*_*oth 8

将变量范围缩小到尽可能窄.外部范围内的变量较少 - 种植和隐藏错误的机会较少.


sbi*_*sbi 7

我发现,在编译时完成和检查的越多,运行时可能出错的可能性就越少.所以我尝试利用允许在编译时进行更严格检查的技术.这是我进入模板元编程的原因之一.如果你做错了什么,它就不会编译,因此永远不会离开你的办公桌(从而永远不会到达客户).

  • +1.令人遗憾的是,C++使元编程变得如此痛苦,并且仍然存在一些错误类型,这些错误应该是编译时可以预防但尚未(例如避免对象切片),但希望事情会发生变化. (3认同)
  • 99%的东西都有解决方案.通过强制执行"非叶类是抽象的"和/或保护所有基类复制构造函数/复制赋值运算符,可以避免对象切片. (2认同)

RED*_*AIR 5

在我开始测试之前,我发现很多问题

断言

  • +1,但我相信在不运行(测试)代码的情况下触发运行时断言非常棘手...... (4认同)

af.*_*af. 5

从一开始就用实际的,真实的数据进行测试.并且测试不仅在编写代码时是必要的,而且应该在设计阶段的早期开始.找出最糟糕的用例,并确保您的设计能够处理它.如果你的设计在这些使用案例中感觉良好和优雅,它实际上可能是好的.

自动化测试非常适合确保您编写的代码正确无误.但是,在编写代码之前,您必须确保构建正确的代码.

  • +1我非常同意.针对模拟器或理想化数据的测试可以作为一个开始,但在单元测试中甚至不应该都是如此.而且我认为需求往往没有得到满足或被误解,所以或许"更多地与业务方面交谈"应该是另一条建议.这一切都能很好地提供完美无瑕的代码,但如果这是错误的解决方案则不行. (3认同)

Pra*_*are 5

学习函数式编程有所帮助. 在这里
了解一个haskell非常好.