让自己成为更优秀程序员的方法

最近我的朋友群中在讨论一个问题“成为一个更优秀的程序员”意味着什么？基于这个讨论，我决定分享一些我“成为更优秀的程序员”的一些方法。我希望其他人可以发现我的一些有用的练习方法，这样他们可以将这些方法融入到自己的生活中。

我让自己变得更好的方法是建立在一套训练方法之上的。每周我都做一套具体的“练习”。我是基于两个明确的目标来设计训练方法的：

学习如何解决那些我之前不知道如何解决的问题

学习如何更快速地编写正确的代码

我的日常训练包含四个不同的练习。每个都帮助我实现上面的两个目标。这四个不同的练习时：

阅读学术论文

学习一个新的工具

阅读几章节的书

编程时录屏，然后回看视频，看看如何能写得更快

让我来更深入地解释一下每一个练习。我想分享一些每个练习是如何操作的细节，以及我从每个练习中得到的主要好处。

阅读学术论文

设计这个练习是为了扩展我的计算机科学知识。我发现阅读学术论文有两个直接的好处。第一个好处是，一些论文改变了我对某个问题的思考模式。一个很好的例子是这篇论文《尾部规模》（The Tail at Scale）。该论文研究了长尾延迟的反直觉性质。

我从这篇论文中学到的有意思的一课是，在多台机器上运行请求是如何影响延迟的。作者研究了来自一个Google服务的经验数据。该服务通过将请求分布到不同的服务中来处理请求。他们运用数据来预估如果你将请求分布到100个不同的服务中会发生什么情况。作者发现如果你测量从所有从100个服务器获得响应所需要的时间，其中一半时间花费在等待最后五个服务。这是因为最慢的5%的请求比所有其他请求慢得多。论文还给出了几个降低尾部延迟的方法。我发现这些方法在我自己的工作中很有用。

从阅读学术论文中发现的另外一个好处是，他们给了我一个知识体系来理解作为一个整体的不同系统。比如Spanner——Google的分布式数据库。Spanner运用了许多其他技术比如：Paxos（分布式环境下解决一致性问题的算法）、two phase commit（两阶段提交，用于同时向多个分离的数据库写信息的联机事务处理中）、MVCC（多版本并发控制）和predicate locks（谓词锁？）。我已经能够通过阅读学术论文来积累对这些不同技术的理解。反过来，这使我可以将Spanner作为一个整体来理解，同时也可以权衡Spanner并与其他系统进行对比。

我发现我阅读的学术论文要么是我读过的论文的参考资料，要么是对Morning Paper（晨报）所包含的论文的后续报道。《Designing Data Intensive Applications》（设计数据密集型应用）一书中也有很多参考论文值得一读。

学习一个新的工具

解决问题的一个最简单的方法是使用一个已经解决这个问题的现有工具。在这个练习中，我选择一个工具并从中学到点东西。通常，我会在本地按照工具，学习一些教程，并阅读一些手册。我在过去一段时间学到的工具有：bash utils（比如jq或者sed）、分布式系统（比如Kafka或者Zookeeper）。

学习一些bash工具帮助我更快地解决一些常规问题。使用sed通常比使用编程语言更容易处理简单的文本。同样，学习不同的分布式系统有助于理解不同工具在解决不同问题时的优势。这样我就知道在面对给定的问题时应该使用什么工具。

阅读几章节的书

我通常读一些书来增补那些我从学术论文或者工具学习中得不到的知识。我读的书涵盖主题非常广。最近读的书包括：

《重构》（Refactoring）——我发现这是一个很好的方法，可以理解好代码应该长什么样子，以及如何将坏代码转变成好代码。

《搞定：无压力工作的艺术》（GettingThings Done）——我发现这本书有助于优先排序事情并跟踪。它帮助我建立一套体系，以确保我完成了对我来说重要的事情。

《第一次当经理》（TheFirst Time Manager）——我最近成为了我团队在工作中的协调员。作为团队协调员，主要职责是必要时与其他团队进行沟通。我还组织我们团队的会议。我发现这本书对于了解基本的管理原则很有意义。

录屏

这个练习是我的最爱。正是这个练习改变了我处理问题的方式。运动员们经常会回看自己的镜头来了解自己如何能做得更好。我决定将同样的方法应用于编程。通过录屏学到的一些教训包括：

它有助于在编写代码时进行测试。这样做可以减少定位bug所在的时间，从而减少调试代码所需的时间。如果你所有现存的代码没有bug，那么bug一定在你刚刚写的新代码里。

当调试一个问题时，仅仅为了调试的目的添加功能通常是值得的。比如我研究过一个toy问题（toy problem？）是编写一个LRU缓存。我遇到一个bug，它没有释放出正确的元素。通过添加一个函数来打印出缓存的状态，我可以快速的判断是什么问题。然后我可以看到缓存的预期行为和实际行为有什么不同。这让我能快速的定位bug。

在写任何代码之前，先花5分钟决定一个方法是值得的。我发现这样做有两个好处。它帮助我确认了我的方法是正确的。更重要的是，它让我只关注一个单一的方法。通过回看我自己的录屏，我发现我浪费了很多时间在两种不同的方法之间切换代码。实际上，每个方法都可以很好的工作。

回想起来，这些教训都是很明显的。但我不知道这些都是问题，直到我开始录屏并且回看我实际花费时间的地方。

我做这个练习的步骤：

1.录下自己写的一些问题。可能是工作中遇到的问题，也可能是编程网站比如Leetcode上遇到的问题。

2.以10倍速查看录像，并标注我在每一个刻所做的事情。

3.统计花费在最高层类别上的时间；花费在调试bug上的时间；花费在构建功能上的时间。

4.看看我花费时间最多的类别。然后深入研究到底是什么占用了这些时间。

5.想出能让我节省时间的办法。通常的方法是可以预先构造代码，这样就可以编写更少的代码或者更早的发现bug。

我强烈推荐录屏练习。这是最简单的方法，你可以从中找到细微的改变从而使自己更有效率。

在过去一年，我一直采用着这套训练方法。我确实注意到了巨大的差异。大量关于系统和工具的知识，没有这些练习我是不会开发的。我也能比以前更快地解决问题。我希望你也能反思一下这些练习，并能自己实践其中的一些练习。

未来，我将会分享我在这套训练方法中发现的东西。我将从每一次练习时写一篇文章开始。我将分享在练习中学到和发现的东西。将我学到的东西再解释一遍，对理解学习内容是有帮助的，并能为其他人提供了很好的学习资源。

作者：

Andrew Owen

https://malisper.me/my-approach-to-getting-dramatically-better-as-a-programmer/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website

作者博客（排版很舒服）：

https://malisper.me

扩展：

The Tail atScale（尾部规模）

https://ai.google/research/pubs/pub40801

Morning Paper（晨报）

https://blog.acolyer.org/about/

Designing Data Intensive Applications（设计数据密集型应用）

https://dataintensive.net/

jq

https://stedolan.github.io/jq/

sed

https://www.gnu.org/software/sed/

Kafka

https://kafka.apache.org/

Zookeeper

https://zookeeper.apache.org/

Refactoring（重构）

https://refactoring.com/

https://item.jd.com/11728740.html

搞定：无压力工作的艺术（GettingThings Done）

https://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0142000280

https://item.jd.com/11916193.html

第一次当经理（TheFirst Time Manager）

https://www.amazon.com/dp/B006WYSBIG/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

https://item.taobao.com/item.htm?spm=a230r.1.14.14.33163a5fBVtgxs&id=583111631716&ns=1&abbucket=5#detail