有printfs,断言,编辑和继续,记录框架？你最喜欢的毒药是什么？
ASSERTs ASSERTs ASSERT.
我在我的个人库中有300000个loc(不计入注释)的高度因素和重用代码,其中大约15%(猜测)是模板,50000 loc是测试代码.
如果一个成语被复制,那么它就成了一个函数/方法.我个人认为剪切和粘贴的容易程度,因为DEVIL的发明故意放在那里膨胀代码并传播缺陷.
大约4%的库是ASSERTS和调试代码(极少数printfs和几乎所有输出都排队输出到cout流自定义低优先级任务,因为屏幕IO是如此昂贵,因此时序变化).也许50%的断言是为了保证类不变量和方法执行的后置条件.
当我重新访问一些我可能已经匆忙或可能只是在接口/对象耦合设计中犯了错误的代码时,我无情地重构,假设方法的主题对象真的属于对象对象,并且该方法属于其中一个最初的对象对象(参数对象).如果我进行大量的重构,那么自由主义的言论似乎可以保护我免受一些愚蠢的错误.这种情况并没有发生,但有时候会发生.
我有一个DEBUGGING宏,就像ASSERT一样,所以我可以将代码包围起来
调试(......代码......);
它不是在非调试版本中编译的.
我不使用供应商提供的断言.我的断言不要中止和核心转储他们只是抛出一个消息框并调用调试器.如果它是新代码并且该方法是const方法,则能够返回到该方法然后使用相同的参数集重新执行它(该方法)非常有用.有时甚至一些数据被更改的事实与问题无关,并且可以通过知识获得重新调用.
我绝对是HATE命令行调试器.这就像回到过去25年一样 - 不妨使用电传打字机和2400波特线.我需要并想要一个完整的IDE,可以右键单击数据结构并打开它,关闭它,追逐指针执行方法等等.
我逐步完成新代码的每一行,并检查每个(我的一个)变量的预期行为.在这里使用突出变化的IDE是非常宝贵的.为了用GDB做到这一点,我必须是一位有着Carnac the Magnificent记忆的音乐会钢琴家;-).
对于新开发,我还尝试在遇到异常情况时捕获流数据/消息数据.这对于udp服务器特别有用,并且经常在重现性方面领先一步.
我也喜欢有模拟器可以"围绕应用程序并驱动它并从中消耗并进行验证."(连接/耦合源/接收器模拟器)我的几乎所有代码都是无头的,或者至少人工交互与功能无关,所以"周围"应用程序经常是可能的.我发现获得良好的支持和管理是非常重要的,这些支持和管理理解测试数据的创建非常重要,并且测试数据集合是构建成一套可以演变成的测试的集合.综合回归/烟雾测试.
我也曾经喜欢设置操作系统调度量子方式使用多线程应用程序这样的短量子可以更容易地带出线程错误.我特别喜欢使用许多线程来驱动线程安全对象方法 - 如果不是数百个则为数十个.一般情况下,如果应用程序是人为驱动的,则无法在线测试线程安全对象- 只是不可能驱动它.因此,确实需要处于低得多(面向组件)级别的自定义测试驱动程序.正是在这些测试中,如果出现问题,断言可以让你知道.显然不能证明代码是正确的,但确实给了一些信心.
这些偏好也可能反映了我所拥有的更多类库/可重用性视图和角色.当你编写库代码时,通常很少有"生产"问题,因为根据定义,库被大量使用并经过大量测试.记录和那种历史似乎比面向库更具应用程序导向.
多级日志记录系统.我发现使用至少5个级别:
详细:你只想在调试协议错误等低级别的东西时看到的东西; 可以从发布二进制文件中编译,因此您可以将这些内容放在您不希望最终用户查找的级别中
内部:低于正常水平的低级跟踪,这通常很有用,但不是经常想要一直看到它
normal:默认输出级别,用于对观看系统正常运行的任何人有用的内容
问题:程序知道如何应对的运行时错误; 您可以选择在此级别上运行发行版本,而不是正常版本
致命错误:"尖叫和死亡"类型的消息,如内存不足
多级日志记录使您可以在程序中构建大量日志信息,而无需一直查看.只有在必须调试某些内容时才会调高日志级别,然后将其恢复到正常级别.在进行"printf"类型调试时 - 临时消息 - 我将它们置于正常级别,因此我不必调高日志级别来查看它们,并让它们被嘈杂的内部或详细级别消息遮盖.
一般来说,printf的.它们允许简单的程序切片,除了编辑器和编译器之外不需要任何工具.
反应措施:
使用一个好的调试器,尤其是集成的多样化器.使用与您的代码可视化工作的调试器.
调试策略.熟悉您的工具.了解常见的陷阱.演绎过程.在不同的想法上使用假设和分支.在需要时回到以前的想法.跟踪调试进度.科学方法.
分析工具(例如Dependancy Walker,.NET Reflector),内存转储,堆栈跟踪和日志.
预防措施:
小增量构建.在主动开发期间,逐个添加到项目中并测试每个传入的部分.不要喷出一堆代码然后混合运行并轻率地纠正每个错误.逐个添加到您的程序,并花时间来解决所有问题.尝试使项目中的每个增量"原子".
正如其他人已经指出的那样,多级日志记录.从跟踪到致命错误以及介于两者之间的所有内容都有严重性级别.您的生产应用程序应该记录它所做的每件事以及它成功或失败的原因,但是当不需要极端细节时,您还应该能够更改日志记录级别.日志应该是人类可读的第一优先级.
故障安全日志记录.不要依赖于您的记录机制来应对异常情况.总是有备份计划 - 事件日志,平面文本文件,最后一封电子邮件 - 当事情发生时自下而上.
良好的源控制政策.定期至少经常办理登机手续,加上任何和所有变更组的登记入住,特别是广泛或可能发生的变化.
我喜欢GDB -我通常在命令行模式下使用它,但是,如果你不能忍受的是,有GUI前端它像洞察,DDD等日志总是帮助,也等做核心转储文件上您可以使用这些相同的工具执行"postmortem debugging".
京公网安备 11010802040832号 | 京ICP备19059560号-6 