极简调试方法

卡尔·萨根曾说过：“我们生活在一个精妙地依赖科学技术的社会中，但几乎没有人了解科学技术。” Katrina Hayes 显然是一个例外——她运用自己的知识和技能来有效地调试代码。

Katrina 在即将到来的 ScaLE 14X 大会上进行题为 调试器工具包中的日志记录 的演讲之前，从她繁忙的日程中抽出时间与 Opensource.com 进行了交谈。她向我们讲述了她对工具的极简使用以及她的一些调试过程。

您是如何开始编码，尤其是调试的？

我很小的时候就接触到了代码，因为我的父亲和祖父都在 SAS 和 BCBS 从事计算机工作。我主要是在大学自学 Perl 时接触到调试。如果你通过命令行运行自己的脚本来学习编码，你必须非常擅长快速发现遗漏的分号。

请您谈谈您自己对调试工具的入门经历。

实际上，我一直对使用极简工具感到自豪。我甚至默认情况下都不使用 IDE——在我的大部分个人开发中，我只使用 TextWrangler，而在工作中，我目前主要使用 UltraEdit。只要给我代码、行为的良好描述，以及向其投掷东西并查看其输出的能力即可。这可能也是我越来越喜欢使用日志记录的原因之一——如果我可以让我的系统（以及可能我的用户）为我做这件事，我就不必进行那么多记录或测试。

每位系统管理员和程序员都有一个他们喜欢讲述的最喜欢的错误，无论是由于它特别困难、幽默还是其他原因。请您讲讲您的。

虽然可能不严格算作“错误”，但我最引以为豪的克服不兼容性时刻之一是将一种特殊的富 HTML5 文档与其余的定制内部教育软件集成，这种文档是由教育演示软件套装生成的，这些软件主要是在此之前的十年左右构建的 PHP 应用程序。那时 HTML5 才刚刚开始流行。它涉及到 13 个单独的手动代码更改，这些更改必须对演示软件输出的每个演示文稿进行。我通过几个月的反复试验，借助我使用的日志记录和其他通知机制，发现了所有这 13 个更改。

您的演讲摘要提到了对遗留系统理解不足，以及使用错误规避而不是修复。这个问题有多严重，解决它有多关键？

这只是我从与其他程序员交谈中得到的印象，但如果你询问任何一家开门营业超过一两年的公司的 IT 部门，这似乎是标准情况。实际上，除非一家公司在其整个生命周期中都非常重视拥有高度可维护的代码库，否则这种情况最终是不可避免的。考虑到可维护的代码只有在长期才能显示其价值，因此总是会存在为了更快速的部署而牺牲可维护性的诱惑。

快速部署有很多很好的理由，但我认为企业在这方面还有很大的改进空间。我认为，展望未来，可能区分能够生存下来的企业和注定消亡的企业的一个重要因素是，哪些企业能够最好地驯服和培育其代码库。不能再仅仅是把它扔出去看看什么能站住脚了。

您是否有明确的个人调试流程？您能否为我们简要描述一下？

没有任何高度开发的流程，但通常我只是花一些时间思考受 bug 影响的系统以及 bug 在该特定系统中的位置。如果它是我已经熟悉的系统的一部分，我可能会浏览一些代码或涂鸦一些东西。如果是我不熟悉的东西，我会尽可能多地阅读代码（或日志或数据库转储）。除非问题很快得到解决，否则我通常会花一些时间思考它，然后再回来更认真地寻找 bug 可能潜伏的地方。此时，根据 bug 和我的访问权限，我可能会读取日志或数据转储，并对代码进行调整以查看这会如何影响事情。那时主要就是迭代。戳戳东西，翻开石头，看看会爬出什么蜘蛛。

您如何选择调试工具？

如果它有效，就部署它。如果它被炒作得很厉害，那就忽略它，直到它成为你正在参加的继续教育课程的作业中要求的工具。

您希望通过在 SCaLE 14X 上的演讲实现什么目标？

分享我与可能从中受益的人们的一些经验，将我迄今为止在特定主题上职业生涯中学到的东西提炼成一些有用的东西，并希望开始一些有趣的讨论！