代码之家  ›  专栏  ›  技术社区  ›  poseid

阅读源代码[已关闭]

  •  4
  • poseid  · 技术社区  · 17 年前

    如果您阅读了其他人的源代码,您如何处理这些代码?你在寻找什么样的模式(数据类型、循环、控制流的使用等等)?你能阅读别人的代码多久而不感到无聊?到目前为止,你发现的最令人兴奋的模式是什么?

    6 回复  |  直到 17 年前
        1
  •  8
  •   Toon Krijthe    17 年前

    起初,我忽略了改变代码的冲动。这有时很难做到。但是,先了解后改变可以为自己节省很多讨厌的“学习经验”

    接下来,如果格式不正确,请重新格式化。如果有代码格式化程序,请使用它。这是因为您倾向于查看缩进,如果缩进不好,那么您对代码的理解也是有问题的。

    然后,如果有复杂的数据结构,我喜欢画一个小图表。这里的挑战是让它尽可能简单。挂在墙上的大型图表很有趣,但大多数时候,它们看起来很麻烦。所以这是浪费时间。

    如果您最终理解了一段代码的功能,请编写一条注释。这是很重要的,否则你下次来的时候就不会明白了。

    下面的步骤是创建单元测试。现在,您不仅可以测试代码,还可以测试您对代码的理解。

    最后,如果你理解它,并且你知道它可以(并且需要)更好,那么改变它。但是一定要运行测试。除非每个解决的bug都给你钱。

        2
  •  3
  •   JesperE    17 年前

    这是一个时髦的新名词 Code Spelunking .

        3
  •  1
  •   joel.neely    17 年前

    除了明显的“自上而下的工作”一般方法外,这取决于 为什么?

    这在很大程度上取决于语言。如果是OOPL,我可能会这样做:

    1. 首先寻找主要的类关系,并尝试理解每个类的主要职责。
    2. 查看类之间的交互以了解它们是如何协作的。
    3. 如果理解这些方法很重要,请查看这些非平凡的方法 他们在工作,而不是在工作 他们要负责。
        4
  •  1
  •   poseid    17 年前

    谢谢,如果我理解正确,第一步是识别上下文,第二步是识别API,并将API放在上下文中。我只是意识到这有点像看一栋建筑或一件艺术品,你可以关注所用的材料,或部分的功能,尝试不同的视角,判断部分如何融入整体。。。发现过程中有一个很好的部分: here - how mathematicans think

        5
  •  0
  •   Slavo    17 年前

        6
  •  0
  •   Colonel Sponsz    17 年前

    挑选一个你在最终产品中理解的项目,看看它是如何组合在一起的。如果你已经有了单元测试,那么它们将是一个很大的帮助。

    推荐文章