程序员需要学习哪些技巧

在过去的七年半中，我在Ronimo游戏公司指导过十几个程序员实习生，审阅了数百份简历。我发现他们中的大多数都需要学习一件事情。你可能以为这是某一技术、算法、数学，或其它形式的某方面知识。当然，他们的确需要弥补这些知识，但是在我看来，这些都不是最重要的。他们要去学习的最重要的一件事是：自律。这种自律体现在：编写尽可能清晰的代码；重构代码以消除因后续开发中的变化所造成的混乱；移除从未用过的代码并且添加注释。

我指导实习生的大部分时间不是在高级技术或引擎细节的解释上，而是让他们写出更好的代码。我总是会问实习申请者：要成为一名优秀的程序员，你们认为哪些是重要的？他们的回答通常是：代码要清晰，易懂，便于维护。这当然是我想听到的，但是很少有年轻的程序员能从一而终地去实践。

做到这些需要自律，因为这意味着代码不能停留于“实现了功能”。假设所有的变量都被随意地命名，代码依然能够完美运行，但是阅读性很差。从短期看，从“功能型代码”到“清晰型代码”带来的回报很少：代码原本就可以运行，对其清理之后代码仍然可以运行。这就是为什么需要自律来完成这一步，这也是为什么参加实习会很有帮助：一个好的导师会非常注重代码的质量（尽管不同的人对“好的代码”有不同的定义），从而要求实习生进一步改进完善，走到下一个阶段。

下面给出几个例子，这些是我在新手程序员所写的代码里经常看到的问题：

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

这些函数、变量、类所做的事情并不是他们名字所暗示的那样，这些名字具有欺骗性。显然名字应该反映真实的内容，但让我吃惊的是，名不副实这种情况常常出现。

举个例子，我最近偶然看到以前一个实习生写的两个类：EditorGUI 和 EditorObjectCreatorGUI，这代码本是用来处理编辑器里的界面。令我吃惊的是，创建新对象的按钮的代码放在了 EditorGUI 里面，而EditorObjectCreatorGUI则是处理不同对象间的操作，这都跟名字所暗示的完全相反！尽管代码比较简单，但我花了好大一会儿才弄明白，因为我基于类名称作出了完全错误的假设。这个案例的解决办法很简单：重命名为 EditorObjectCreatorGUI和 EditorObjectNavigationGUI，仅仅做一小步就可以大大提高阅读性。

命名不准确这种情况我见到很多。之所以频繁发生，是由于代码在不断地演变。最初选择那个命名时可能是正确的，但一到代码完成之后，命名可能就变得不准确甚至错误的了。这个陷阱提醒我们应该始终把命名记在心上，在你添加一段代码的时候就要弄清楚，这与函数或类的名称是否相称。

推荐阅读：《程序员最头疼的事：命名》

混淆不清的类

另一个问题是混淆不清的类，即一个类做了很多不相关的事情。当你长时间专注于同一块代码时，就可能这个问题。新功能用最简单的方法实现，到了某种程度，类就会变得臃肿，做了很多不相关的事情。有时候类变得臃肿不在于代码规模的大小：一个类可能只有几百行，但它却包含了不属于本类功能的代码。

举个例子，如果一个GUI类需要“分析哪些纹理可供使用”（设想有个按钮用于选择纹理），如果GUI类是唯一一个需要这种分析结果的类，那么在GUI类里实现它是很合理的。但是，这时一个完全不相关的gameplay类也需要这种分析结果的信息，因此你将GUI类传递给gameplay类来查询纹理信息。这个时候GUI类就多出一种东西了：它是GUI类，同时也是TextureAnalyser类。这个案例的解决方案很简单：从TextureAnalyser类分割出一个独立的类，这个类可同时被GUI类和gameplay类使用。

避免这种问题的最好方法是在每次写代码前三思：我在这里添加的功能跟类的名称符合吗？如果不符合，那么就要对类重命名，或者将其分割成独立的类，或者把这段代码放到其他的类中。

如果想不出来一个跟类非常匹配的名字，这通常是代码异味（Bad Smell）。如果找不到合适的名字描述这个类，可能因为它所做的事情太混杂了。这时可以将它分割成几个部分，并且每个部分用一个恰当的名字来描述。

体积庞大的类

这问题跟上面所说混淆不清的类很相似：随着时间的推移，越来越多的代码被添加到一个类里，使得其变得臃肿。在这种情况下尽管放在一个类是很合理的，但是类的体积变得很大。超大的类处理起来是很麻烦的，当很多代码对同一个私有成员变量进行操作时，bug就很容易出现，并且人也很容易忽略很多细节。

分割一个超大的类是件相当无聊的工作。当代码高度交错时，这也具有很大的挑战性。分隔代码需要高度的自律，因为这只是对已有的代码进行增加或修改而保持原有的功能不变。

Ronimo公司有一个规定，保持类的代码在500行以下，函数的代码在50行以下。有时候这是不可行也不合理的，但是通常来说，不管哪一个类或函数超出了这个规定，我们都会寻找办法将其重构或者分割成更小的，更易于管理的片段。（这让我很好奇：你觉得这个限制应该是多少行？可以在评论中留言。）

代码注释

实习申请人给我们发过来的样本代码几乎都有一些被注释的代码块，但并没有说明为什么会做这个注释。是代码存在错误需要修改吗？还是代码过旧需要更新？注释掉的代码为什么会在这里？当我们问起申请人时，他们对这些被注释的代码也显得很疑惑，但是奇怪的是，总会有一些原因不明的被注释的代码。

代码重复

另一个我经常看到的问题是有相似功能的代码重复出现。

举个例子，从纹理名字也许可以看出这东西的用途，如TreeBackground.dds。为了知道这个纹理是否可以用于一棵树，我们检查以Tree开头的文件名。也许当使用SDK后我们能很快找到，使用beginsWith（”Tree”）就行了。这个代码很短，如果需要用到它，直接粘贴到那儿就可以了。这就是代码重复，并且人人都知道代码重复是应该避免的，如果重复的代码很短，那么最吸引人的做法是直接复制粘贴。在这儿的问题很明显：以后如果要检查这个纹理是否适用于别的东西，我们就要进行散弹式修正，一个地方一个地方修正了。

通常比较好的做法是，如果代码功能特殊，不要去复制，而是把它放到一个函数里。尽管代码很短很短，并且调用一个函数比粘贴需要写更多的代码，但是你要学会这么做，这也需要高度的自律。

本文所讨论的主题很浅显，大多数人在上大学一年级的时候已经学过了。难就难在从知道这些东西到实际花时间遵循它们，再到把它们记在心里。这就是为什么所有在Ronimo实习过的人学到的最重要的东西不是知识，而是自律。