如何阅读代码(译)

做者: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%。专一于你要解决的事而且知道该怎么深挖出你要的答案,你将会发现你会理解的很是快。
相关文章
相关标签/搜索