Effective Debugging：软件和系统调试的66个有效方法 - (EPUB全文下载)

文件大小：0.38 mb。
文件格式：epub 格式。
书籍内容：

Effective Debugging：软件和系统调试的66个有效方法
第1章 宏观策略
第1条：通过事务追踪系统处理所有的问题
第2条：在网上确切地查询你所遇到的问题，以寻求解决问题的灵感
第3条：确保前置条件与后置条件都能够得到满足
第4条：从具体问题入手向上追查bug，或从高层程序入手向下追查bug
第5条：在能够正常运作的系统与发生故障的系统之间寻找差别
第6条：使用软件自身的调试机制
第7条：试着用多种工具构建软件，并将其放在不同的环境下执行
第8条：把工作焦点放在最为重要的问题上
第2章 通用的方法与做法
第9条：相信自己能够把问题调试好
第10条：高效地重现程序中的问题
第11条：修改完代码之后，要能够尽快看到结果
第12条：将复杂的测试场景自动化
第13条：使自己尽可能多地观察到与调试有关的数据
第14条：考虑对软件进行更新
第15条：查看第三方组件的源代码，以了解其用法
第16条：使用专门的监测及测试设备
第17条：使故障更加突出
第18条：从自己的桌面计算机上调试那些不太好用的系统
第19条：使调试任务自动化
第20条：开始调试之前与调试完毕之后都要把程序清理干净
第21条：把属于同一个类型的所有问题全都修复好
第3章 通用的工具与技术
第22条：用Unix命令行工具对调试数据进行分析
第23条：掌握命令行工具的各种选项及习惯用法
第24条：用编辑器对调试程序时所需的数据进行浏览
第25条：优化工作环境
第26条：用版本控制系统寻找bug发生的原因及经过
第27条：用工具监测由多个独立程序所构成的系统
第4章 调试器的使用技巧
第28条：编译代码时把符号信息包含进来，以便于调试
第29条：对代码进行单步调试
第30条：设置代码断点和数据断点
第31条：了解反向调试功能
第32条：查看例程之间的相互调用情况
第33条：查看变量及表达式的值，以寻找程序中的错误
第34条：了解怎样把调试器连接到正在运行的进程上
第35条：了解怎样运用核心转储信息来进行调试
第36条：把调试工具设置好
第37条：学会查看汇编代码及原始内存
第5章 编程技术
第38条：对可疑的代码进行评审，并手工演练这些代码
第39条：审读代码并与同事讨论
第40条：给软件添加调试机制
第41条：添加日志语句
第42条：对软件进行单元测试
第43条：用断言进行调试
第44条：改动受测程序，以验证自己的推想
第45条：尽量缩小正确范例与错误代码之间的差距
第46条：简化可疑代码
第47条：将可疑代码改用另外一种编程语言来写
第48条：改善可疑代码的可读性与结构
第49条：要清除bug的根源，而不仅仅消除其症状
第6章 编译时的调试技术
第50条：对生成的代码进行检视
第51条：使用静态程序分析工具
第52条：对项目进行配置，令程序能够以固定的方式构建和执行
第53条：对调试所用程序库及构建代码时所应执行的检查进行配置
第7章 运行时的调试技术
第54条：通过构建测试用例来寻找错误
第55条：令软件在遇到问题时尽早退出
第56条：检视应用程序的日志文件
第57条：对系统和进程所执行的操作进行性能评测
第58条：追踪程序的执行情况
第59条：使用动态程序分析工具
第8章 调试多线程的代码
第60条：通过事后调试来分析死锁问题
第61条：捕获并重现
第62条：用专门的工具来探查死锁与竞争条件问题
第63条：把不确定的因素隔离出来，或将其移除
第64条：检查资源争用情况，以解决与可伸缩性有关的问题
第65条：用性能计数器寻找伪共享问题
第66条：考虑用更为高级的抽象机制来重写代码
网上资源
第1章　宏观策略
要想解决问题，就必须先选定最佳的策略，这样才可以事半功倍。如果当前的策略无法奏效，那就应该立刻改用成功率第二高的办法。
第1条：通过事务追踪系统处理所有的问题
请想象这样一种场景：George在电话里朝你大吼，说你开发的那个应用程序“运行不了”，于是你赶紧把问题写在便签上，然后把它贴在显示器旁边，显示器周围还有很多类似的纸条。现在你开始回想，自己到底有没有把新版程序所需的最新库文件发给George。实际上，我们不应该这样来处理问题，而是应该改用下面的办法。
首先，要保证有一套事务追踪系统（issue-tracking system）可供使用。很多开源软件库，如GitHub和GitLab等，都提供基本的事务追踪系统，该系统与它们所提供的其他功能是集成在一起的。有些组织使用一种名为JIRA的专有系统，这种系统要复杂得多，它可以在企业内部运行，也可以作为服务来运行。还有一些组织使用开源替代品，如Bugzilla、Launchpad、OTRS、Redmine或者Trac。选择哪个系统并不重要，重要的是必须保证所有的事务都记录在这个系统里面。
如果某个问题没有记录在事务追踪系统中，那我们就拒绝处理该问题。坚持使用这样的系统，能够带来下面几个好处：
·可以看见调试工作所取得的进展。
·可以对软件的发行进行追踪与规划。
·帮助我们确定各种工作项（work item）之间的优先次序。
·帮助我们把常见的事务及其解决方案整理成文档。
·防止我们遗漏某些问题。
·可以自动生成发行说明（release note）。
·可以用作知识库，使我们对软件中的缺陷进行估量及反思，并从中总结经验。
对于公司里面那些不必亲自汇报问题的高层员工来说，你可以代他们汇报问题。如果某个问题是你自己发现的，那你也可以自己把这个问题提交到系统里面。有一些公司规定：在修改代码之前，必须先指明这次修改所涉及的事务。
我们还要保证的是：每一项事务都能够精确地描述问题的重现方式。最好能在其中给出一个简短（short）、自足（self-contained）且正确（correct，也就是可以正确编译并运行）的例子（example），即SSCCE。我们可以把这个例子直接剪下来，粘贴到应用程序中，以便重现它所要说明的问题（参见第10条）。为了使大家能够写出有效的错误报告（bug report），我 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。