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

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

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

• 学习如何解决我以前不知道怎样解决的问题；

• 学习如何更快地编写正确的程序。

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

• 读一篇论文；

• 学习一个新工具；

• 读一本书的几个章节；

• 在写程序时录制屏幕，然后审查写程序的过程，找出如何才能写得更快。

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

读一篇论文

这个练习的目的是为了扩展我在计算机科学方面的知识。我发现阅读论文有两个直接的好处，第一就是一些论文改变了我对特定问题的看法，比如《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数据库的性能优化。

译者：弯月，责编：郭芮

_“征稿啦_”

CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。

如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（[e-mail]）。

————— 推荐阅读 —————