游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

阐述程序员看不懂代码的原因及解决办法

发布时间:2012-11-26 16:23:20 Tags:,,

作者:Robert Dieterich

任何网络技术人员都应该熟悉RTFM这个缩略词,其全称为“Read the Freaking Manual”(去读他妈的手册)。它是回复那些只要查阅文件便可解决问题的标准答案。

在程序员领域,RTFM的自然变体是RTFC,即“Read the Freaking Code”(去读他妈的代码)。在任何指定的程序中,按其定义,源代码能够最准确地描述程序的运作模式。除去错误评论与误导性的变量名称,源代码是唯一完全正确的文件编译形式。源代码若无法演变为出色文件就要归结于它的阅读难度太大。事实上:

read_code(from sws-sag.com)

read_code(from sws-sag.com)

大部分程序员都无法阅读代码

程序员无法阅读代码?难道这不是他们的职责范畴?也许,这听起来很怪,但事实正是如此,原因如下。

从最严格的意义上说,几乎所有程序员都能阅读代码,比如,他们可以解析一行代码,合理解释它们的作用。但具备理解大量代码,以及隐含在代码编写过程中的构思与意图,注意某些缺失代码、推断代码之后演变的能力则大不相同。可惜,许多编程团队均缺少这种能力。也就是说,大部分程序员仅能阅读一些代码,其实他们缺乏代码理解能力。

为此,原话应调整为:

由于大部分程序员缺乏代码理解力,因此,他们无法有效地阅读代码。

有着Joel on Software美称的Joel Spolsky也在他的博文中提出了相似看法:

编写代码比阅读代码更具难度。

那么原因何在?以下是我认为出现该现象的主要原因。

首先,阅读代码应牢记大量数据。在编写代码时,你只需记住变量、算法、数据等,而后编写相关性能。而在阅读代码时,你不仅要记住目前研究的性能数据,而且还应识记相关的潜在功能数据。为了充分理解代码以便利用,你应根据代码中暗藏的提示信息,在头脑中构造一个设计模型。在编写代码时,你可以忽略某些特例与误差,寄希望于在发挥核心逻辑时获得代码。大多数时候,在你阅读代码时,当中已存在特例与误差。因此,你不仅要记住更多数据,而且还应推断代码的设计目的与用途,让它符合某个软件项目的更大愿景。难怪,不少程序员一想到要理解大量代码库便畏畏缩缩,然后选择自己编写。其实,他们是自我设限,认为自己无法阅读代码。

造成代码阅读障碍的另一个原因是程序员的自豪感。编写代码可归结为个人努力。当你投入大量时间深入思考某个问题,并为此编写代码时,你极易眷恋自己创造的代码。这种方式的优势在于,可以鼓励程序员不断完善该代码,但这会导致程序员独霸某个特定问题,偏向采用自己的代码予以解决。这种自豪感容易造成程序员忽略他人方法,且难以将其与自己的方法进行公平比较。实际上,如果程序员在一开始便抱有厌恶情绪,他们将无法发挥脑力去理解那些代码。

最近,我的老板就程序员自豪感方面发表了见解,其大意可归结如下:

在阅读别人的代码时,你不能带着轻视之感。如果你不尊重那些程序员,你将无法理解这些代码。

对于许多程序员,阅读代码的最大障碍是认为“编写该代码的程序员可能比我更加厉害”的这种心理。

你会有同样感受。阅读代码具有难度,因为这是心理与情感的双重负担。这就是问题所在,我们该如何解决?

坦白讲,我希望自己知道答案。在招聘方面,我提议最好测试他们的代码理解能力。而对于正在一起工作的人员,你应努力找出能够积极阅读并深入理解代码的程序员,以此避免团队重写现存代码。如果你拥有这些人才,你应支持他们的做法,并鼓励其他人员向他们学习。

单个程序员也应学会阅读代码,这种能力并非与生俱来,而是通过练习不断学习掌握。不要害怕接触那些第一眼看起来似乎十分难懂的代码。通过努力研究,你能够理解它。你应牢记自己能够理解那些代码,即使不如相应的程序员灵活。你只能通过阅读代码,才能像他们一样睿智。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Most Programmers Can’t Read Code

by Robert Dieterich

This is a cross-post from my blog, Game Dev Without a Cause.

Any technically-inclined person on the net should be familiar with the acronym RTFM which stands for the phrase “Read the Freaking Manual” (the non-family-friendly version is more colorful, of course). It’s the standard response to a question that you think wouldn’t have been asked had the asker read the (freaking) manual in the first place.

For the programming set, a natural variant for RTFM is RTFC, “Read the Freaking Code”. For any given program, the source code is, by definition, the most accurate description of how a given program will behave. Barring inaccurate comments and misleading variable names, source code is the only form of documentation guaranteed to be 100% accurate. What keeps source code from being great documentation is that it is so hard to read. It’s so hard in fact that:

Most Programmers Can’t Read Code

Programmers can’t read code? But isn’t that their job? Strange as it may seem, it’s true and there are reasons for this.

Now that I have your attention, I’ll take a moment to admit my cheekiness in the above statement. Almost any programmer can read code in the strictest sense, i.e. they can parse a given line of code and have a reasonable idea of what it will do. But, being able to understand large amounts of code, the designs and intentions implicit in how code is written and by whom, taking note of what code is not there, and being able to extrapolate on how the code will evolve over time, is a different story. These abilities can be unfortunately rare in many programming teams. In other words, most programmers have some facility in code reading, but they are actually deficient in code comprehension.

So, to refine my original statement:

Because most programmers have poor code comprehension,

Most Programmers Can’t Read Code Effectively

Joel Spolsky of Joel on Software fame made a similar observation with this line from one of his posts:

It’s harder to read code than to write it.

So why is code so much harder to read than to write? There are a couple of reasons that I think are primarily responsible for this phenomenon.

The first reason code is harder to read than to write has to do with the sheer amount of data you need to keep in your head in order to read code. When you write code, you only need to remember the variables, algorithms, data, etc. relevant to the feature your are currently writing. On the other hand, when you read code, you need to keep data not just about the feature you are currently investigating but data about other potentially relevant functionality. In order to understand code well enough to leverage it, you need to build up a working model of the design in your head gleaned from clues hinted at by the code you read. While you write code, you can ignore exception and error cases with the expectation that you’ll get to them once you get the core logic working. In most case, when reading code, all those exception and error cases are already implemented and embedded into the code that you’re reading. Not only do you have to keep several times more stuff in your head when you’re reading code versus writing it, but you also have to pretend that you’re Sherlock Holmes as you try to deduce the intended design and usage of the code you see and fit it into a larger mental picture of the software project. It’s no wonder so many programmers chicken out at the thought of understanding a large codebase and opt to just write their own. They essentially mind-trick themselves into thinking that they are too dumb to read code.

The other major factor that confounds reading code is pride. Programmer pride. Writing code is a surprisingly personal endeavor. When you spend a lot of time thinking deeply about a problem and crafting code to solve that problem, you can easily become emotionally attached to the code that you created. This can be advantageous because it encourages programmers to constantly refine their favorite code, but it also leads to programmers having territorial feelings over a particular problem domain and biases towards their own code. This sort of pride can make it extremely difficult for a programer to read someone else’s implementation and fairly compare it with their own. Indeed, if they start reading code with the assumption that they won’t like it, they will never be able to apply the brain power necessary to understand the code they are supposed to read.

My boss said something recently that spoke to this element of programmer pride and I’ll paraphrase it here:

You can’t look down on someone when you read their code. If you don’t respect the person writing the code, you won’t be able to apply the energy needed to understand it.

For many programmers, the toughest barrier preventing them from reading code may be saying to themselves: “The person who wrote this just might be smarter than I am.”

There you have it. Reading code is hard because it can be both mentally and emotionally taxing. So that’s the problem, now what can we do about it?

Honestly, I wish I knew. For recruiting, my best recommendation is to try to find ways to test for code comprehension. For folks you already work with, try to find the programmers who actively read code, are able to grok it, and are able to leverage that understanding so your team doesn’t have to write code that has already been written. Once you find these guys, hold them up and encourage others to follow their example.

As for individual programmers, learn to read code. The skills needed to read code are not innate, they are learned and honed through practice. Don’t be scared of trying to read code that seems inscrutable at first glance. With enough work, you will be able to understand it. Remember that you are smart enough to understand any code that comes before you, just not as smart as the guy who actually wrote it. The only way to get as smart as that guy is by reading his code.(source:gamasutra)


上一篇:

下一篇: