年轻程序员需要学习的5大经验

在过去的7年半时间里,我带过的软件实习生超过一打,也看到过数以百计的学生和毕业生的档案。我发现很多事情他们都需要学习。或许你会说,我说的不 就是某种特定的技术、算法、数学,或者其他特定形式的知识吗?没错,这的确是需要学习的,但却并不是最重要的事情。他们需要学习的最重要的东西是“自我规 范”。这些规范就是:尽可能地写出最简洁的代码;如果代码后期会因为改动而变得凌乱不堪就得重构;尽量删除没用的代码,并添加注释。

我花了很多时间来敦促这些实习生去学习这些内容。我经常会问他们,怎么样才能成为一名优秀的程序员,他们也通常会回答说,代码应该清晰易懂易于维护。这的确是我想听到的声音,但是很少有年轻的程序员真的能够始终如一地贯彻这一点。

请谨记这一点,要懂得“自我规范”,也不能一旦代码“起效了”就立马置之脑后。如果所有的变量都命名错误,但是代码依然可以完美地运行,那么这些代 码绝对乱糟糟得让人不忍直视。将功能代码改进为简洁代码可能在短期内是看不到回报的:代码原本就可以工作,在清洁之后依然可以工作。这就是为什么你需要 “自我规范”这一步骤了。这也是为什么实习工作是如此必要:一个好的上司是相当注重代码质量的(即使所谓“好代码”的定义对于每个程序员都不一样),从而 迫使实习生和初级程序员不得不反复修改。

年轻程序员需要学习的5大经验

下面我举的一些例子都是新手程序员写代码的时候经常出现的:

名不副实的函数/变量/类

这些函数、类和变量实际所做的事与其名字所表达的含义并不一致。片面看名字是正确的,但是联系实际的话,有的甚至是毫不相关的。

举个例子,我上一期的实习生写了两个类:EditorGUI和EditorObjectCreatorGUI。用于处理编辑界面的代码。让我哭笑不 得的是,用于创建新对象的是EditorGUI,而EditorObjectCreatorGUI只能通过处理不同的对象进行导航。两者的含义居然是截然 相反的!即使代码还算相对简单,但我还是花了相当长的一段时间用来理解它,因为一开始我是在一种完全相反的假设基础上来理解的。这种情况的解决方案非常简 单:重命名EditorObjectCreatorGUI为EditorObjectNavigationGUI即可,这样就易于理解多了。

这种情况我看到过很多。之所以会发生这种情况是因为代码在工作过程中发生了演变。在选择名字的时候可能还是正确的,但到了写完代码的那一刻,就名不副实了。关键是要时刻铭记命名法则。你得明白你添加的东西是否依然符合函数和类的名称。

混乱的类

另一个问题是类很乱:类做了很多不相关的事情。新功能的添加很简单,但是慢慢的,你会发现你的代码变得臃肿不堪,各种不相关的功能随处可见。有时候,臃肿与否也并不指的是类的大小:某个类可能只有几百行,但依然囊括了不属于它的代码。

为什么会发生这种情况呢?举个例子:假设由于某种原因,某个GUI类需要分析什么样的纹理可行(可能是有按钮要用来选择纹理)。如果这个GUI类是 唯一需要这个分析结果的类,那么在GUI类中这样做是有意义的。然而,由于某种原因,一个完全无关的gameplay类也需要这些信息。所以你需要将这些 纹理查询的信息从GUI类传给gameplay类。这时候,其实这个GUI类已经变大了:因为它里面其实还包括了TextureAnalyser类。解决 方法也简单:将TextureAnalyser类分割为一个单独的类,GUI类和gameplay类都可以使用它。

关于这一条经验法则很多人提出质疑:要是我添加的功能仍然适合原来这个类的名字呢?如果的确不适合,那么我就必须重命名,或者将其分割成单独的类,抑或用代码写成一个不同的类吗?

如果你不能为你的类想出一个合适的名字,给人的感觉就会不舒服。如果你不能在类的名字中描述它的目的,那么就会显得乱七八糟。有时候我们还需要将某个臃肿的类分割成几部分,并各自取一个恰当的名字。

过于庞大的类

这和上一点——混乱的类有些类似:很多东西一点一点地都添加到类中,然后它不可避免地就臃肿了。在这种情况下,这样一个类仍然是有意义的,但就是长 得太大个了点。这么个庞然大物不但繁琐,而且很容易出现bug,因为大量的代码需要用于操作同一个私有成员变量,所以我们很容易忽视一些细节。

分割一个已经长得很大的类其实是相当枯燥的。这也会成为一个挑战,如果类中的代码高度交织在一起的话。再加上它已经在工作,修复时不能添加新功能,这样一来,我不得说,分割一个过于庞大的类,不能严格地自我规范是不行的。

根据在Ronimo的普遍经验,类保持在500行代码以下、函数保持在50行代码以下是最合适的。不过有时候,这样做反倒不可行,也不明智。但是一般说来,一旦类或函数超出了那个界限我们就可以想办法重构,并将之分割为更小更易于管理的片段了。

关于代码注释

几乎所有的示例代码都会包含注释好了的代码片段,而不说明为什么。这段代码需要修复吗?旧的代码是否已经被取代了?为什么那儿要写这些代码?大家都知道没有注释的代码常常不知所言,但不知何故,很多人都会忘记在自己的代码上注释。

并行逻辑和代码重复

还有一个问题就是我经常能在若干个代码段处看到相似的逻辑。

例如,我们可以从纹理这个名称知道它大概的目标对象,比如说是“TreeBackground.dds”。为了知道纹理是否可以用于tree,我们 检查了文件名以便知道它是不是以“tree”开的头。可能使用SDK的话我们用filename.beginsWith(“tree”)可以很快地检测出 来。只是这句代码这么短,我们往往会选择哪个地方需要,就直接复制粘贴。当然这样就是代码重复了,而正如每个人都知道的,我们应该避免重复代码,但如果复 制的代码是如此之短,我们往往会忘记这一点,很自然地就直接copy了。此处我们面对的问题也是显而易见的:也许后面我们检查某个纹理是否适合tree的 方法就得变了,然后我们就不得不实行“霰弹式修改”(即到处修改)策略,一处一处地修复。

此处的一般规律是,如果是非常具体的代码,那就不要复制,即使原本的代码超级之短,调用函数甚至比直接写需要更多的代码,也应该封装成函数。

相关推荐