年轻程序员最需要学什么?自律!

在过去的七年半中,我在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实习过的人学到的最重要的东西不是知识,而是自律。

收藏 3 评论

关于作者:XfLoops

新浪微博:@XfLoops 个人主页 · 我的文章 · 10

相关文章

可能感兴趣的话题



直接登录
最新评论
  • jason 在校 2015/01/14

    楼主很有见地啊!不过在下以为,自律确实是治本之道,但是培养起来很难,尤其在当下国内的IT环境。需要自律的背后就是懒。懒不是说要写很多代码,而是懒于去思考,懒于去折腾。

    而这个懒的背后,就是缺少积极的环境。在公司,领导看重的是业绩,看重的是完成了多少任务,很少去想完成的质量,可想而知,下面的人就会怎么做了。

    当然,这是外界的因素。外界的因素,不一定是主导因素,但会是大多数人的主导因素。

    从个人的角度来说,自律对做任何事情都是很重要的,但是也是有前提的,试想,谁会自律去做一件自己不怎么喜欢更谈不上热爱的事情?大多数人是正常的,这个正常是社会需要的,所以大多数人不会成为一个领域的高手和大师。

  • Daniel   2015/01/14

    不错不错,值得学习。

跳到底部
返回顶部