解决方法
我在我的个人库中有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服务器特别有用,并且经常在重现性方面领先一步.
我也喜欢有模拟器可以“围绕应用程序并驱动它并从中消耗并进行验证.”(连接/耦合源/接收器模拟器)我的几乎所有代码都是无头的,或者至少人工交互与功能无关,所以“周围”应用程序经常是可能的.我发现获得良好的支持和管理是非常重要的,这些支持和管理理解测试数据的创建非常重要,并且测试数据集合是构建成一套可以演变成的测试的集合.综合回归/烟雾测试.
我也曾经喜欢设置操作系统调度量子方式使用多线程应用程序这样的短量子可以更容易地带出线程错误.我特别喜欢使用许多线程驱动线程安全对象方法 – 如果不是数百个,则为数十个.一般情况下,如果应用程序是人为驱动的,则无法在线测试线程安全对象 – 只是不可能驱动它.因此,确实需要处于低得多(面向组件)级别的自定义测试驱动程序.正是在这些测试中,如果出现问题,断言可以让你知道.显然不能证明代码是正确的,但确实给了一些信心.
这些偏好也可能反映了我所拥有的更多类库/可重用性视图和角色.当你编写库代码时,通常很少有“生产”问题,因为根据定义,库被大量使用并经过大量测试.记录和那种历史似乎比面向库更具应用程序导向.
