scribble

吕小荣

Blog Friends RSS About

如何提高对烂代码的理解速度?

本文是「参与大项目的酸甜苦辣」成长系列的一部分。

大项目之 吐槽架构
大项目之 如何提高对烂代码理解速度?
大项目之 如何应对无力感?


去年的一个场景

我和 Vincent 在一起看别人写的糟糕代码,他的思维在各种 Context 中跳来跳去,很快理解了各种垃圾方法的意图,宛如预先加载了所有的代码到大脑中。

我和他结对的时候,压根跟不上他的节奏。当时我全职做 Ruby 不到一年,把原因归结为「经验不足」。

今年的又一个场景

今年我和吴坚结对去理解别人代码(这次不算太烂),他看了10分钟的代码,就在各个文件的 Context 跳转自如。今年我也算是个中级程序员了,经验比较丰富了,依然不具备这种能力。

这种现象已经严重的影响到我的工作效率,所以有必要深刻的反思。

如何提高对优质代码的理解速度?

优秀的代码总有通用的模式,如果我一直遵循 Ruby / Rails Best Practice,当看到别人严格的遵守 Best Practice 的代码时,心领神会。

假如工作中需要我写一个 Redis List 的封装类,在定义方法时肯定会使用 shift/unshift/pop/push 等数组常用的方法。当我看到别人已经写好的源码时,作者和我设计意图的重合让我先天的具备了在源码不同文件的 context 中跳转的能力。

List#instane_methods

不断的学习和训练各种优秀设计(优秀的经验),会显著的加快对优质代码的理解速度,这一点我没有疑问。

如何提高对烂代码的理解速度?

我在这方面做的很差,有以下几个原因:

  1. 对烂代码的厌恶感。

    有时候花了几个小时看别人的烂代码,就会越看越生气,特别想把作者拖过来暴打一顿,甚至把他枪毙了。

    看到一个200行的 controller#action 时第一反应是「你把这个 action 当做万能方法吗?」;
    看到一坨 sql 语句时的第一反应「你是个 PHP 程序员吗?」

    这种厌恶感极其消耗心理能量。可厌恶有什么用呢,东家付工钱是为了让我干活,而不是来吐槽,问题终究还是需要人来解决。

    既不想改变自己,又要摆脱这种负面情绪,如何做到呢?暂且的方案「每天只花2个小时的时间吃屎」。

  2. 业务逻辑无用论。

    若一件事情对于我没有意义,就很难投入其中。去年对接电商的 CRM 时一开始十分烦躁,但是把看问题的角度提高到「这是我第一次写 API Wrapper Gem 」时,就看到其中的意义,然后愿意付出大量的时间和热忱。

    在接手一个项目时,潜意识里会把它分为:

    1. General Knowledge,比如项目中有趣的 Gem、设计方式、权限管理、Elasticsearch、Newrelic、MySQL 索引等等。这些知识既有趣又可提高自己的实力,所以我会刻意去花时间记忆。

    2. Project specific information,比如表的结构,字段含义,表之间的关系,订单处理流程。

    对于 General Knowledge,我愿意花费大量的时间去训练,变成自己的长时记忆。对于 Project specific information,我则顺其自然,每次做任务时都重新 load 到短时记忆中。

    在小项目中,这种方法游刃有余;但是在大项目中就完全不灵光了。项目太大,大脑无法完全 load 整个代码库,看代码时只能频繁的 IO 读取相应的模块。所以我觉得有必要把大项目部分 Project specific information 内化成自己的长时记忆,以便降低自己大脑的 IO 次数,加快完成任务的速度,处理垃圾代码时也更游刃有余?

    举个例子,如果 UML 熟烂于心,就不要频繁的查看各个 Model 了。

假如以上个人问题都得到纠正,我对烂代码的理解力依然低于 Vincent 和 吴坚,只能归因给工作记忆的差异吗?

半年之后,我再来回答这个问题。

下一步计划

  1. 摆正心态,每天仅花2个小时阅读虐心代码
  2. 提高 Project specific information 的重视程度,至少要背过 UML,而不是每次去查。

updated_at 2015-12-29 09:39:54

写下从事代码行数 200,000+ 大项目8个月后的一些感触,算是对当初的自答。

  1. Be patient. 一点点的啃,把自己工作职责范围内的活干好,为未来的重大决策积累资本。

  2. 现在对整个项目的理解依然是管中窥豹,永远无法了然于胸。但是已经可以在部分代码之间灵活的切换上下文了。Vincent Xie/Gene 能够在各个 context 之间娴熟的切换,主要原因可能并非他们强大的工作记忆,而是因为长久从事该项目所积累的长时记忆。

  3. 谋定后动,是编程的好习惯,也是参与大项目最大的心理阻碍。花时间梳理模型,通读代码,然后开工。这种策略在大项目上完全走不通。

  4. 停止抱怨。抱怨无用,且给人留下眼高手低的坏印象。


吕小荣
17 July 2015