[译] 阅读别人的代码

原文链接:Reading Other People’s Code

我确实喜欢阅读别人的代码,这可以让你了解别人是怎样解决常见问题,有时还会提供编写代码时你不该做什么的格言。这还会教你许多必要的**阅读别人代码的技能**。不幸的是,阅读别人的代码并不会感到方便有趣

现在,问你自己两个问题:

  1. 每周你编写代码花了多少小时?
  2. 每周你阅读不认识的人写的或者可以接触到的代码花了多少小时?

勇敢的话甚至会问:

  1. 所阅读的代码中有多少是确信自己理解了的并能做贡献的?

许多人避免阅读代码仅仅是因为他们讨厌走出自己的舒适区。如果文档所说的跟代码所做的是一样的话,那阅读文档是高效利用时间的方式。往往很多时候,文档是过时的,不靠谱的,甚至也许还会撒谎。你唯一能确信的是源码

整个行业已经树立了分享和编写代码的观念,却没有阅读。

阅读

如何阅读(What about reading)?我认为阅读和编写代码正如听和说一样都是整体的。每个人都喜欢说/写自己的表达方式;艺术在工艺的背后,但如果没有对应的听/读,都不会欣赏这两者。

如果我递给你一本书并让你指出是从哪里开始阅读的,你会翻过致谢,目录,和其他编辑名单,然后翻到正文第一页或第一章。棒极了!

现在如果我递给你打印出的一堆代码,你能告诉我从哪里开始会容易阅读吗?你能轻松地给代码分章节吗?你的读者必须这样吗?如果没有一个主要的方法会怎样?: )

在我告诉你之前,我想告诉你一个故事。

在开始编写代码时,我喜欢从头开始写东西。我会很清楚代码干的每件事,感受到自己的强大。我能理解代码的一切是因为这是我写的,我并不需要阅读它是因为这是我写的。非我所创( NIH (not invented here))是常见的,因为开发者觉得重写比阅读代码容易。开发者开发赢者赢(developers develop and winners win,即什么样的人做什么样的事)。

当开发者可以简单地为现有满足需求的程序打补丁时,为何他们还要为添加一些功能而重写程序?

这涉及到以下事情:

  1. 获取源码
  2. 阅读和理解源码
  3. 贡献/打补丁
  4. 测试(但愿如此)
  5. 分享

第二步是大多数人会试图避免的,因为它会让我们绕回到最初的问题。

一个软件中哪里才是第一章或者是正文第一页呢?我认为是开始写代码的地方。一般来说这跟写书类似。书的结构(开头,中间和结尾)一般不会改变的,但软件开发一般把最后的目的放在前面。

那么来回答这些问题:

你是从哪里开始阅读软件的?作者开始写的地方。就算它实际上没干什么也不要紧,一个未完成的故事你仍然能够阅读它,不是吗?

Rainman

在这里告诉大家,今天(2012/9/23)我将开始开发 Rainman。这个工具将会使用 git 仓库以明智的方式重现 git 提交(commits)和差异(diffs),并展示了清晰透明的软件开发过程。

这样你会认为提交(commits)实在是太有用了吧。大多数情况是这样,这也是我为什么打算也提供一个记录工具,让开发者记录软件开发的过程并能重现精细明了的开发过程。

这仍然是在初始阶段,欢迎在 GitHub issues 提交反馈和建议。