新手程序员典型错误分析：第1部分

你好世界！ 当您了解了所需的一切并最终被聘为实习生或初级员工后，您可能可以放松，对吗？不管怎么样！一切才刚刚开始……你周围有很多新的、难以理解的事情，如何不一出门就搞砸呢？这就是我们今天要讨论的内容。在这篇文章中，我想看看初学者常犯的错误，并根据我自己的经验给出一些如何避免这些错误的提示。那么，让我们开始吧：

1. 害怕向更有经验的同事寻求帮助

我们都是人，都害怕自己看起来很愚蠢，尤其是在我们新成立的、经验更丰富的同事眼中。一旦获得第一份工作，开发人员常常会屈服于这种恐惧，无法自拔地自我封闭，试图自己解决一切问题。同时，一个人周围可以有更有经验的同事，他们反过来能够初步引导他走上最正确的道路，这将有助于避免更多的错误和不必要的“坎坷”。因此，请记住：不要害怕提问：您是初学者，每个人都完全理解这一点。当你提出要求时，没有人会用棍子打你。也许甚至是相反的：你会更快地与同事交朋友，并开始更积极地与他们沟通。我还要说的是：你问和讨论各种技术问题越多，你就能越快地摆脱新手的困境，成长为你所在领域的专家。还有一条建议。不要忽视StackOverFlow。在这种情况下，我的意思是询问有关此资源的问题。一方面，需要一些时间才能得到问题的答案。但另一方面，你可能会立即了解解决当前问题的几种方法，并从稍微不同的角度来看待它。我还想指出的是，在 StackOverFlow 上写下评论和答案，澄清其他开发者提出的问题，除了因果报应之外，还有一个实际的好处：你有机会更深入地讨论和理解这个问题。

2.不要试图自己寻找信息

也许这个错误是前一个错误的反面。我的意思是，当你开始向你的同事和熟人拉扯每一个问题时。提问是好事，但你不应该问太多问题，否则你可能会感到无聊。如果出现一些难以理解的问题，首先要做的就是在最好的搜索引擎——Google 中运用你的搜索技巧。有人已经遇到了绝大多数难以理解的错误和其他问题。如果你用谷歌搜索一下，看到有多少人熟悉类似的问题，并且已经收到了适合在他们的工作中使用的全面答案，你会感到非常惊讶。基于此，你经常可以听到同事回答一个问题——“Google it”。您不应该被这个答案冒犯，因为毕竟，您的同事不是应该传达您工作领域的所有复杂性的私人老师。无穷无尽的互联网将帮助您进行此类指导。有时，程序员在 Google 搜索中也被称为黑带人士。因此，当我们陷入困境时，我们首先用谷歌搜索问题，如果没有找到解决方案（很少，但确实会发生），然后我们开始询问我们的同事。值得立即询问他们，不是在出现某种故障或难以理解的错误时，而是在选择解决问题的方法时。毕竟，他们能够超越你的视野，并立即判断这种或那种方法从长远来看会产生怎样的结果。

3.盲目复制粘贴

但谷歌搜索这个问题及其解决方案也有其缺陷。例如，盲目复制粘贴。当您发现类似的问题（但可能不完全相同）并且在其下面（例如在 StackOverFlow 上）有一个解决方案时，通常会发生这种情况。您可以自行复制并粘贴此解决方案，无需了解太多细节。然后您或您的项目同事发现了一些奇怪的错误或功能的不正确行为。没有人知道腿从哪里来。那么，当然，会找到有这个代码的地方，你的这个决定肯定不会受到赞扬。因此，当你在StackOverFlow（或其他地方）上找到现成的解决方案时，首先你必须详细分析它，它是什么，如何以及为什么。也许谷歌一下这个功能并查看它的文档。然后才将其实施到您的项目中。

4. 抛出错误的解决方案

在编写解决方案时，有时会变得越来越复杂并最终陷入死胡同。您正在尝试使其变得越来越复杂，以便使用这种方法以某种方式解决这个问题，而不是试图寻找另一种更可行的替代方案。也许你只是对自己所花费的精力和时间感到遗憾，所以你决定：无论如何，都不要放弃，而是这样解决问题。这并不完全是正确的做法。至少在编程方面是这样。越早尝试不同的方法，最终节省的时间就越多。因此，尽管您在这一方法上投入了大量时间，但不要害怕尝试其他方法。此外，这些将是您的经验点，因为您将尝试多种方法并更好地研究该领域。

5. 害怕提出有关当前任务的问题

项目工作通常归结为完成一些任务（任务）。例如，在Jira中。而且这些任务并不总是被详细和清晰地描述。它们通常是由团队领导编写的，如果发生这种情况，这些人也是人。他们也可能忘记添加某些内容，或者没有考虑到您对这个或那个功能不是很熟悉。好吧，或者您没有对该项目的任何访问权限（例如，访问数据库、日志服务器等）。而现在，接到任务，研究了几个多小时后，你仍然坐在那里一脸茫然地看着屏幕。您应该开始向此任务的创建者提出引导性/澄清性问题，而不是继续无济于事地解决这个问题。假设您在团队（例如 Microsoft Teams）中用于通信的应用程序中，或者直接作为此任务下的评论。一方面，如果您在个人消息中写下问题，很可能会更快得到答案，因为人们会立即看到该问题。另一方面，通过在 Jira 中提出问题，您有证据表明您正在做某事，即分析问题。有一种方法可以加快此过程：在 Jira 中以评论形式提出问题，并在私人消息中发送该评论的链接并请求查看。

6. 对团队领导期望过高

这又是前一点的反面。团队领导是开发团队的负责人。一般来说，这样的团队成员的大部分时间都花在各种类型的沟通上。同时，他也编写代码，以免忘记这一切是什么。嗯，如你所知，这是一个非常忙碌的角色。而每次打喷嚏时过度的抽搐显然不会让他开心。想象一下，如果每个团队成员都用一堆问题轰炸他。所以你可以发疯，对吧？如果你提出很多问题，他会花很长时间回答你，这并不奇怪。您可以采取哪些措施来减少向团队领导提出的问题数量：

• 更深入地研究该项目的文档，以减少盲点。
• 向其他团队成员提问。他们很可能与领导一样熟悉此功能，甚至更熟悉，因为很可能他们中的一个人编写了该功能。

或者，在 IDE 中，您可以查看注释：谁以及何时最后更改了特定行中的代码。这样我们就能找出谁最适合提出这个问题。你可能已经明白了，在向组长提问时，以及在向同事提问时，你需要尽量保持中庸之道——不要害怕提问，但也不要用太多的问题来纠缠他们。

7. 害怕代码审查

代码审查或代码审查是将代码上传到公共应用程序（公共分支，例如 master 或 dev）之前的一个阶段。这项检查是由与此任务无关的开发人员执行的，他们可以以全新的眼光发现在开发初始阶段未被注意到的代码风格中的错误、不准确或缺陷。如果有注释，它们将作为代码某些部分的注释保留。在这种情况下，执行此任务的开发人员必须根据审查纠正错误（或与审查者讨论他的决定，也许让他相信他的决定的正确性）。然后发回审稿，以此类推，直到审稿人没有意见为止。审阅者在上传代码之前充当“过滤器”。因此，许多新手程序员将代码审查视为批评和谴责。他们不欣赏她并且害怕她，这是错误的。正是代码审查使我们能够改进代码。毕竟，我们会收到有关我们做错了什么以及应该注意什么的重要信息。有必要将每次代码审查视为学习的一部分，这可以帮助您提高。当一个人对你的代码留下评论时，他会与你分享他的经验和最佳实践。对我来说，如果没有经过代码审查，你就不可能成为一名优秀的程序员。因为你不知道从外部有经验的人的角度来看，你的代码有多好，是否有错误。

8. 倾向于深奥的解决方案

通常不同的任务/问题可以有几种不同的解决方案。在所有可用的解决方案中，初学者通常使用最复杂和“深奥”的解决方案。这是真的：如果一个新手程序员昨天学习了许多不同的算法、模式、数据结构，那么他就会渴望实现其中的一个。是的，可以这么说，我想声明自己。相信我，我自己就是这样，我知道我在说什么:)我曾经遇到过这样的情况：我花了很长时间编写一个功能，结果发现它非常非常复杂。然后由高级+级别的开发人员重写。当然，我很想知道他改变了什么以及如何改变。我查看了他的实现，惊讶地发现它变得如此简单。而且代码也减少了三倍。同时，对该功能的测试没有改变也没有失败！也就是说，一般逻辑保持不变。由此我得出的结论是：最巧妙的解决方案总是简单的。认识到这一点后，编写代码变得更加容易，并且明显变得更加高级。那么，您会问什么时候值得使用模式和算法呢？那么，在使用它们的时候将会是最简单、最紧凑的方式。

9.自行车的发明

这个概念也被称为轮子的发明。其本质在于，开发人员针对已经存在的问题实现自己的解决方案，并且比程序员发明的解决方案好很多倍。一般来说，发明自己的自行车会导致时间的损失和开发人员工作效率的降低，因为可能找不到远离最佳的解决方案，或者可能根本找不到。与此同时，我们不能放弃独立决定的可能性。程序员必须正确导航可能出现在他面前的任务，以便使用现成的解决方案或发明自己的解决方案及时有效地解决它们。一方面，在大学和课程中，我们面临着各种各样的任务，这些任务应该有助于我们动手制造自行车。但这只是乍一看。其实这样做的目的是为了发展算法思维，更深入地掌握语言的语法。此类任务还有助于更好地理解算法/结构，并且在必要时为他们提供实现高级类似物的技能（但这很少需要）。在现实生活中，在绝大多数情况下，没有必要发明自己的轮子，因为满足我们需求的类似物早已存在。也许，根据您的经验，您将不知道您需要的这个或那个功能的实现是否存在。这时候就需要用到本文的第一点，即向更有经验的同事寻求帮助。他们将能够指导您（例如，向 Google 提供建议）或建议特定的实施（某些库）。

10. 不要编写测试

所有初学者都不喜欢编写测试。新手呢：非新手也不喜欢编写测试，但他们更好地理解为什么需要它。当你完全不懂的时候，你会想：为什么要写它们？一切正常，并且不能有任何错误。但是您如何确定您的更改不会破坏系统其他部分的某些内容？如果你推行的变革带来的破坏大于他们的收益，你的同事将不会感激。这就是测试可以发挥作用的地方。测试覆盖的应用程序越多越好（也称为覆盖率）。如果应用程序已被测试很好地覆盖，那么通过运行所有测试，您可能会发现可能因更改而损坏的地方。正如我在上面的示例中所说，在重构功能时，测试没有失败，这都是因为一般逻辑没有改变。这意味着测试还可以显示某个功能的逻辑是否发生了变化。因此，即使您不喜欢编写测试，它们也有毫无疑问的好处，并且值得在它们上花费时间。

11.过度评论

许多开发人员都患有完美主义，初学者也不例外。但有时这种愿望的副作用是他们开始评论每个人、每件事。即使是不需要的，因为它是如此明显：

Cat cat = new Cat(); // cat Object

并非所有新手程序员都会立即意识到注释代码并不总是一件好事，因为代码会变得更加混乱且难以阅读。如果代码改了，但是没有注释怎么办？事实证明，他会欺骗我们，只会让我们感到困惑。那为什么会有这样的评论呢？通常，编写良好的代码不需要注释，因为其中的所有内容都已经是显而易见且可读的。如果您写了注释，则意味着您已经破坏了代码的可读性，并且正在尝试以某种方式平滑这种情况。最好的方法是首先编写可读的代码，而不必补充注释。我还忍不住提到了方法、变量和类的正确命名，即我自己遵守的一条规则： 最好的注释是没有注释，而不是它，而是清晰描述这一点的正确命名或您的应用程序中的该功能。

12. 错误的命名

通常，初学者会伪造类、变量、方法等的名称。例如，当他们创建一个类时，其名称根本没有描述其用途。或者用一个短名称创建一个变量，例如x，当创建另外两个名为n和y 的变量时，就很难记住x的作用。在这种情况下，您必须仔细思考代码并在显微镜下研究此功能（可能使用调试器），以便简单地了解那里发生了什么。这就是我上面提到的代码中的正确命名对我们有所帮助的地方。正确的名称可以提高代码的可读性，从而节省熟悉时间，因为使用名称大致描述其功能的方法要容易得多。在代码中，一切都由名称组成（变量、方法、类、文件对象等），这一点在创建正确、干净的代码时变得非常重要。值得记住的是，名称应该传达含义：例如，为什么变量存在、它做什么以及如何使用它。我会一次又一次地指出，描述变量的最佳注释是它的正确名称。为了更深入地研究注释和正确命名，我建议你阅读永恒的经典：《干净的代码》。创建、分析和重构”，罗伯特·马丁。至此，本文第一部分（反思）就结束了。 待续…