【译文】成为更好的程序员的方法

叁叁肆2018-12-17 10:58

翻译 :仲维昌

欢迎访问网易云社区,了解更多网易技术产品运营经验。 


最近在我的社交圈子里出现了关于“更为更好的程序员”的方法的讨论。基于这场讨论,我决定与大家分享一下自己的更为更好的程序员的方法。我希望大家知道,我发现的方法经实践证明是有用的,所以大家也可以将它们用到自己的生活中。


我的改进的方法是围绕训练计划建立的,我每周都有一套特定的“练习”,我在设计训练计划时考虑了两个明确的目标:

l  学习怎么解决我以前不会解决的问题

l  学习怎么将程序写的又快又好

 

我的训练路线一直包含四个不同的练习,其中每一个都能帮助我达到上面所描述的两个

目标。这四个练习如下:

l  读一篇论文

l  学习一种新的工具

l  读一本书的几个章节

l  在写程序的时候录制屏幕,然后回顾所录的视频,思考如何能够将程序写的更快

 

在这里,我再深入一些解释下每个练习。我想分享下每个练习是如何起作用的细节和我通过每一个练习获得的益处。

 

读一篇论文


本练习旨在扩展我对计算机科学的了解,我发现阅读论文有两个最直接的好处。第一个好处是有些论文改变了我对一些问题的思考模式,一个很好的例子是《The Tail at Scale》,这篇论文研究了长尾延迟的反直觉性。

我从这篇论文中学到的一个有趣的教训是在多台机器上执行一个请求是如何影响延迟的。作者观察了Google服务的经验数据,他们使用这些数据来估算如果你在100个不同的服务中分发请求会发生什么。作者发现,如果你测量从100个服务器获取响应所需要的时间,那么将有一半的时间用于等待最后五个服务器,这是因为最慢的5%的请求比其它请求慢的太多。本论文还提供了几种减少尾部延迟的方法,我发现这些方法在我的工作中很有用。

通过阅读论文,我发现的另一个好处是它们让我整体性的了解不同的系统。例如,拿Google的分布式数据库Spanner举例,Spanner使用了许多不同的技术,像Paxos、两阶段提交、MVCC、predicate锁等,通过阅读论文我已经建立了对这些不同技术的理解。反过来,这也使我能够将Spanner作为一个整体进行推理,将推断Spanner与其它系统相比的权衡。

我发现我读的大多数论文要么是引用我读过的文章要么是引用早报上所述的文章。《Designing Data Intensive Applications》这本书也引用了许多值得阅读的文章。

 

学习一种新的工具


一种解决问题最容易的方法是使用已经解决类似问题的现有工具。在本练习中,我选择了一个工具并对它进行了解。通常我会在本地安装这个工具,浏览一些教程和阅读一些使用手册。在过去,我学习过的工具包括从bash工具包(如jq或seq)到分布式系统(如Kafka或Zookeeper).

学习bash工具可以帮助我解决许多常见任务,且比使用其它工具更快,如使用sed通常比使用编程更容易的进行简单的文本处理。同样,了解不同的分布式系统,能很容易的知道应该用什么工具更好的解决遇到的各种不同的问题。通过这种练习方式,当我面对问题时我就知道自己应该用什么工具了。

阅读一本书的几个章节


我通过书本来补充我不能够从论文阅读或学习工具的过程中获取的知识,我读过的书涉及了广泛的主题。最近读的书有:

l  《Refactoring》我发现读这本书,是了解好代码应该是什么样子以及如何将坏代码转换为好代码的方法。

l  《Getting Things Done》这书有助于确定事项的优先顺序和追踪记录。它帮助我建立了一个系统,以确保我完成对我来说比较重要的事项。

l  《The First Time Manager》我最近成为了我们工作团队的协调员,作为团队协调员,我的主要工作是在需要的时候与其它团队进行沟通。我也主导我们团队的会议,我发现这本书非常有助于理解基本的管理原则。

      

录制屏幕


这个练习是我最喜欢的,它最大程度的改变了我遇到问题的方式。通常运动员为了了解如何能做的更好会回顾自己的镜头,我也决定将这种方法应用到编程之中。通过录制屏幕我总结出如下经验教训:

l  它有助于我在编写代码时测试代码,这样就可以减少花在定位bug位置的时间,从而减少调试代码所需要的时间。如果你先前已经写好的所有代码都是没有问题的,那么新的bug只可能会出现在最新写好的代码中。

l  当调试一个问题时,为了调试而添加的功能通常是非常值得的。例如,我参与的一个玩具的问题是写了一个URL缓存,我并没有正确的删除结点元素导致出现了一个bug。此时通过添加一个打印缓存状态的函数,我能够很快的确定哪里出了问题。然后我可以看到缓存中的预期行为与实际行为的不同之处,这让我很快的定位到bug。

l  在编写任何代码之前劳逸结合五分钟时间确定一个要写的方法是值得的。我发现这样做有两个好处:它有帮助确保我所写的方法是正确的,更重要的是,它迫使我决定采用单一的方法。通过观察自己的录屏,我发花现自己在两个不同的方法上来回改写浪费了太多的时间,事实上,这两个方法中的任何一个都能很好的达到目的。

 

回想起来,所有这些经验教训都是显而易见的。直到录屏后意识到自己在这些情况下花费的时间之前,我并不觉得这些情况都是有问题的。

我为这个练习采取的步骤是:

1, 将一些问题录制下来,可以是在工作中遇到的问题,也可以是编程挑战网站(例如Leetcode)上的问题

2, 以10倍的速度浏览视频,并记录每个申请时刻自己正在做什么。

3, 统计自己总共花费了多少时间在高级类别上,花了多少时间在调试bug上?又花了多少时间在构建一些功能上?

4, 查看花费时间最多的类别,然后深入了解下实际所占用的时间或哪些地方占用了时间。

5, 想出一个能够节省时间的方法。通常有一些已经构建好可以复用的方法,这样就可以让我写更少的代码或更容易的发现bug。

 

我强烈建议你建制屏幕。这是一种最容易帮助你做出最小改变而能在很大程度提高工作效率的方法。

 

在过去的一年里我一直在执行这种训练计划。毫无疑问,我注意到了它带来影响。这里面有丰富的关于系统和工具的知识,足够让我不用再以其它方式进行开发,我也有了比以前更快的解决问题的能力。我希望你能考虑下这些训练并将它们在自己身上实践。

在未来,我打算开始分享我通过训练计划发现的一些东西,准备每做其中的一个练习时都写一篇博客。我将会分享自己在练习中学到的东西,感觉解说自己学到的东西不但能让自己受益,还能够为他人制作一些很好的学习资源。

 

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


免费领取验证码、内容安全、短信发送、直播点播体验包及云服务器等套餐

更多网易技术、产品、运营经验分享请点击