scribble

吕小荣

Blog Friends RSS About

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

Published on 2015-07-17

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

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


去年的一个场景

我和 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. 停止抱怨。抱怨无用,且给人留下眼高手低的坏印象。


吕小荣 at 11:07
Edit this page