英文原文地址：https://spin.atomicobject.com/2017/06/01/how-to-read-code/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website

作者：WILLIAM SHAWN

 

        “我讨厌阅读别人的代码”在所有经验层次的程序员中都普遍存在着这个问题。然而，这又是一个必备技能，特别是程序员直接使用现成代码时，如果你以正确的角度和正确的工具来处理，那将是一场很享受和有启发的经历。

        我们讨厌读别人代码的原因是代码不是我们自己写的。那并不是说我们都悄悄地坚信我们才是这个星球最好的coder并且没有人能写出像我们一样的好代码。那是因为在写代码的时候会有一个积极的思维过程， 被动的阅读者没有获得这种亲身体验的好处。

        你再屏幕上读的代码可能出自多人之手。可能涉及到讨论和合作。可能一个版本花费了数周的时间才敲定，里面还包含了原作者一些未文档化的约束条件–但是你却不知道。

       作为一个reader，你所能看到的都是完成品，并且，除非你一点点深挖，否则你看到的就是屏幕上别人的单词。

        

        1.学会深挖

       当你一头扎入一个成熟的代码库时，你会觉得你不想是一个开发者，更像是考古学家、私家侦探、或者圣经学者。很好，因为你有一大堆事要处理。

       如果你足够幸运接触到一开始就用版本控制的代码库，庆祝吧。你接触到很多元数据将使你的理解不局限与代码，还有上下文，那将容易很多。我将假定你使用了Git，如果用了SVN也一样。

       git blame

       你可以使用git blame命令来获取作者名字，最后修改时间和每一行提交的哈希值。熟悉这些开发者。如果你运气好，作者可能只有几个，而且一部分还在和你一起工作，那他们可以作为你的资源。运气不好的话，那就可能是一大堆你不认识的开发者了。

       不管怎样，尽量去了解主要开发者。如果你遇到一个解决不了的奇怪问题，通过git blame找出作者直接去问他吧。

       git log

        使用git log功能来查看所有的历史提交记录。这个命令能打印信息，如果你想查询一些commit信息，别忘了用这个功能。git log | grep someFunction -c 3(-c 3可以显示匹配的3行内容)

        git log也可以显示单个文件的提交记录：git log -p index.js.注意谁最近在一直修改他，出问题的时候就可以直接找出来了。

        

        2.适时回顾

        你可以通过check out查询任何一次commit，让他完全就像是最近提交的一样。当你遇到一个很难追踪到的bug时，你可以通过查询最后一次正确提交开始追踪，或者你仅仅觉得无聊想看看你来之前，几年前的历史信息。

        如果你的项目托管到了Github或类似的网站上，你可以通过查看问题、pull请求和code review来获取大量信息。留意那些大量讨论的问题。那些可能就是你最终会遇到的痛点，提前了解该怎么解决。

 

        3.看规范

        规范是新的注解。看单元规范，理解那些功能和模块该怎么做，边界情况该怎么解决。查看集成文档了解用户在你的程序中是怎么进行交互的并且你的程序支持哪种工作流。

        

        4.把评论当做提示   

        如果你偶遇一个很困惑的功能并且看了相关评论后更困惑了，考虑下这个评论是不是已经过时了没有被维护。程序员的眼睛要有跳过这种绿色文本行的功能，这种评论可能是在描述一个这几个月（几年）都不存在的功能。

        

        5.找到主要的

        这可能看起来明显，但你要确保你知道代码是从哪里开始运行的并且是怎么设置的。看看文件包含的地方，被实例化的类，和被设置的控制选项。

        你可能在代码库的其他地方都见过他们。一些模块可能经常被用到并且从代码库中解耦出来。他们代表着更小更容易被消化的功能，你应该在处理更大的应用程序之前熟悉他们。

        运行git blame功能看看最近哪些地方改变了。近期大量的代码改变可能会指引你进入到最近几周团队面临的挑战中去。可能他们做好了一个新的库，可能他们继续在努力配置一个运行不怎么好的库，又或许他们只是更新了一个需要被定期更新的模板文件。

        试着从其他源文件中找到这些模块看看他们是怎么使用的。你能从直观概念中感觉到他们是怎么运行的。

 

        6.注意代码风格

        你学习这个应用程序的原因是你最终要编写他，因此要注意代码风格。当然，这些东西包括命名约定，空格约定，和大括号约定，但也包括代码约定。

        他一般抽象了多少层级呢?如果代码抽象了很多层，你就应该编写同样抽象层级的代码。

        如果你深挖了足够多的历史代码，你可以精确的找到哪个地方的代码已经抽象出来了。这段代码过去是什么样，并且以后又会是什么样？当你自己写的时候尽量跟随同样的约定。

        从更细的层面上讲，别的团队成员的代码是什么样的呢？如果他们倾向于使用for循环来遍历map，那你最好同样倾向于用for循环。

        如果你不喜欢一个约定，那就告诉你的团队以后要修改的地方，但别在同一个文件中混入大量不同风格的代码。一个文件越像一个人写的就越好。风格保持一直比写的漂亮更重要。

    

        7.期待找到垃圾代码

        你也许会发现从没用到的功能，或者从没用到的文件。你可能会发现几年都没碰一下的注释掉的代码(git blame).别犹豫，不用花太多时间去想它，并且不要害怕把他去掉。

        如果代码在这有他存在的原因，会有人在code review的时候打上一个flag的。你的行为将为下一个阅读者减少脑力开销。

 

        8.不要迷失

        记住，当你发现自己身处荒地时不要觉得不舒服。不要指望他是一个线性的前进过程，不要指望把他了解到100%。专注于你要解决的事并且知道该怎么深挖出你要的答案，你将会发现你会理解的非常快。