优秀的程序员是如何处理技术 Bug 的？

最新推荐文章于 2025-09-16 17:42:06 发布

转载最新推荐文章于 2025-09-16 17:42:06 发布 · 2.4k 阅读

640?wx_fmt=gif

640?wx_fmt=jpeg

最近我的圈子里人们都在讨论“如何成为更优秀的程序员”。看了他们的讨论，我决定分享一下我关于“如何成为更优秀的程序员”的经验。我希望向别人介绍我认为有用的经验，以便他们应用到自己的生活中。

我“变得更优秀”的办法是建立在训练的基础上的。我每周都要做一系列的“练习”。我设计的训练有两个明确的目标：

学习如何解决我以前不知道怎样解决的问题；
学习如何更快地编写正确的程序。

我的训练方法总共由四个不同的练习组成，每个都能帮我实现上面的两个目标。这四个练习分别是：

读一篇论文；
学习一个新工具；
读一本书的几个章节；
在写程序时录制屏幕，然后审查写程序的过程，找出如何才能写得更快。

我会具体解释下每个练习。我还会分享一些我如何进行这些练习，以及我从这些练习中得到的好处。

读一篇论文

这个练习的目的是为了扩展我在计算机科学方面的知识。我发现阅读论文有两个直接的好处，第一就是一些论文改变了我对特定问题的看法，比如《The Tail at Scal》（https://ai.google/research/pubs/pub40801）这篇论文介绍了长尾的违反直觉的延迟。

我从这篇论文里学到一个很有意思的事情，就是在多台机器上执行请求会影响延迟。作者研究的数据来自某个Google服务，该服务在处理请求时，会将请求的各个部分分发到多个不同的服务上。文章利用一些数据估算了将请求分布到100个不同的服务上时会发生什么。作者发现，如果测量从所有100台服务器上接收响应的时间，那么超过一半的时间是在等待最后五个响应！这是因为最慢的5%的请求要比所有其他请求慢得多。这篇论文还给出了几种降低长尾延迟的方法。我发现这些方法在我的工作中非常有用。

读论文的另一个好处就是它能为我提供知识，使我从整体上理解不同的系统。以Google的分布式数据库Spanner为例，Spanner使用了许多不同的技术，如Paxos、两阶段提交、MVCC和谓词锁等。通过阅读这些论文，我理解了这些技术的概念。这样我就可以从整体上理解Spanner，并理解与其他系统相比Spanner做出的权衡。

我发现，我阅读的大部分论文都来自于我读过的论文的引用，或者来自Morning Paper的推荐。《Designing Data Intensive Applications》（https://dataintensive.net/）这本书也引用了许多值得一读的论文。

学一个新工具

解决问题的最简单的方式之一就是使用一个已有的、专门用于解决该问题的工具。在这个练习中，我会选一个工具并学习之。通常我会在本地设置好工具，阅读几篇指南，再阅读一点手册。我过去学过的工具很广泛，从jq、sed等bash工具，到Kafka或Zookeeper等分布式系统。

学习bash工具能帮我更快地解决许多常见的任务。简单的文本处理使用sed通常比使用编程语言更容易。类似地，学习不同的分布式系统能帮我理解解决不同问题所需的不同工具。

这样当我面对某个问题时，我能知道该用什么工具来解决。

阅读一本书的几个章节

我用书籍来补充我无法从论文或工具中得到的知识。我阅读的书籍覆盖的话题非常广泛。我最近读的书包括：

《重构》（Refactoring），我发现通过这本书能很好地理解好代码应该是什么样子，以及怎样将坏代码变成好代码。
《尽管去做》（Getting Things Done），这本书对优先级排序和任务跟踪很有帮助。它帮我建立了一套规则，保证我能把重要的事情先做完。
《新手经理人圣经》（The First Time Manager），我最近在工作上成了团队的协调人，主要责任是在有需要时与其他团队沟通，也负责组织我们团队的会议。这本书是理解基本的管理概念的很不错的入门读物。

录制屏幕

这个是我最喜欢的练习，它对我解决问题的改变最大。这个练习就像运动员审核自己的录像，以便找出改进的方式一样。我打算在编程上使用同样的办法。关于录制屏幕的练习，我有以下经验：

它能帮我在编写代码时进行测试。这样做可以减少定位bug的时间，从而减少调试代码的时间。如果所有的代码都没有bug，那么bug必然出在新写的代码中。
在调试一个问题时，增加一个调试专用的功能通常很值得。举例来说，我之前解决过的一个玩具性质的问题是写一个LRU缓存，有个bug是无法把正确的元素替换出去。我加了一个函数用来输出缓存的状态，这样就能迅速确定出错的原因了。我能够看到缓存的实际行为和正确行为之间的差异，这样就能迅速地确定bug的位置。
在写任何代码之前，花五分钟确定一个方案是物有所值的。这样做有两个好处，它能让我确定我选择的方案是正确的，更重要的是，它能强迫我选择唯一的一个方案。通过观察自己的视频记录，我发现我在两种不同方案的来回切换上浪费了很多时间。实际上任何一种方案都可以工作得很好。

现在回想起来，这些经验教训都很明显，但如果没有屏幕的记录，并观察我在哪里浪费了时间，我完全不能意识到这些问题。

这个练习的步骤是：

记录我自己解决某个问题的过程。可以是我在工作上遇到的问题，或者是在某个编程挑战网站上（如Leetcode）遇到的问题。
以10倍速度重放视频记录，找出每段时间我在做什么。
计算我在每一类事情上花费的时间。我在调试bug上花了多少时间？在构建某个功能时花费了多少时间？
查看我花费时间最多的分类，然后继续挖掘究竟是什么花费了时间。
想办法找出节省时间的办法。通常都能找到办法，提前组织代码的结构，这样就能写更少的代码，或者更容易找到bug。

我强烈推荐记录你的屏幕——这是找出提高工作效率的小改进中，最容易的一个办法了。

我去年一整年都在进行这种训练，从我自身来说真的发生了很大的变化。我学到了许多本来不可能学到的关于系统和工具的知识，我还能比以前更快地解决问题。我希望你喜欢这些练习，并将其中一些应用到自己的工作中。

以后我将分享我在训练过程中的发现。首先，我要在每次做某个练习时写一篇博文，记录下我在练习中得到的经验和教训。我觉得记录下我的经验教训应该对我很有好处，也能成为其他人的很好的学习资源。

原文：http://malisper.me/my-approach-to-getting-dramatically-better-as-a-programmer/

作者：malisper，Heap的软件工程师，位于旧金山，他致力于多个TB级别的PostgreSQL数据库的性能优化。

译者：弯月，责编：郭芮