在曩昔的7年半时间里，我带过的软件实习生逾越一打，也看到过数以百计的学生和毕业生的档案。我发现许多作业他们都需求学习。或许你会说，我说的不便是某种特定的技术、算法、数学，或许其他特定方式的知识吗？没错，这的确是需求学习的，但却并不是最重要的作业。他们需求学习的最重要的东西是“自我标准”。这些标准便是：尽或许地写出最简练的代码；假设代码后期会由于改动而变得凌乱不胜就得重构；尽量删去没用的代码，并添加注释。
我花了许多时间来敦促这些实习生去学习这些内容。我经常会问他们，怎么样才干成为一名优异的程序员，他们也通常会回答说，代码应该清楚易懂易于保护。这的确是我想听到的动态，可是很少有年青的程序员真的能够始终如一地遵从这一点。
请谨记这一点，要懂得“自我标准”，也不能一旦代码“起效了”就立马置之脑后。假设一切的变量都命名差错，可是代码仍然能够完美地工作，那么这些代码必定乱糟糟得让人不忍直视。将功用代码改进为简练代码或许在短期内是看不到酬谢的：代码原本就能够作业，在清洁之后仍然能够作业。这便是为什么你需求“自我标准”这一进程了。这也是为什么实习作业是如此必要：一个好的上司是恰当重视代码质量的（即使所谓“好代码”的界说关于每个程序员都不相同），然后迫使实习生和初级程序员不得不重复修改。
下面我举的一些比如都是新手程序员写代码的时分经常呈现的：
名不虚传的函数/变量/类
这些函数、类和变量实践所做的事与其姓名所表达的含义并不共同。片面看姓名是正确的，可是联络实践的话，有的乃至是毫不相关的。
举个比如，我上一期的实习生写了两个类：EditorGUI和EditorObjectCreatorGUI。用于处理修改界面的代码。让我哭笑不得的是，用于创立新方针的是EditorGUI，而EditorObjectCreatorGUI只能经过处理不同的方针进行导航。两者的含义居然是截然相反的！即使代码还算相对简略，但我仍是花了恰当长的一段时间用来了解它，由于一开始我是在一种彻底相反的假定基础上来了解的。这种状况的解决方案十分简略：（yuanshanmedia）重命名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”）能够很快地检测出来。仅仅这句代码这么短，咱们往往会挑选哪个当地需求，就直接复制张贴。当然这样便是代码重复了，而正如每个人都知道的（yongjiacarpet），咱们应该防止重复代码，但假设复制的代码是如此之短，咱们往往会忘掉这一点，很自然地就直接copy了。此处咱们面临的问题也是清楚明了的：或许后边咱们查看某个纹路是否适合tree的办法就得变了，然后咱们就不得不施行“霰弹式修改”（即处处修改）战略，一处一处地修改。
此处的一般规矩是，假设是十分详细的代码，那就不要复制，即使原本的代码超级之短，调用函数乃至比直接写需求更多的代码，也应该封装成函数。
上面谈论的这些内容现已讲得十分透彻了。许多内容乃至你在大学中就学过。可是现在要面临的应战是你需求一步步地从被迫恪守到主动铭记于心养成一种习气。这也是为什么Ronimo中的实习生最重要的不是学习知识，而是学会自我标准。
随时随地看视频
