新手程序员常见错误分析，pt。1个

你好世界！一旦你学会了你需要知道的一切并最终开始作为实习生或初级开发人员工作，你就可以放松了，对吧？没有。一切对你来说才刚刚开始……你被许多新的和难以理解的事物所包围。你怎么不把它搞砸了？这就是我们今天要讨论的内容。在这篇文章中，我想分析菜鸟常见的错误，并根据我自己的经验给出一些关于如何避免这些错误的建议。 那么，让我们开始吧，不用多说：

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

我们都是人。我们都害怕看起来很愚蠢，尤其是在我们更有经验的新同事眼中。当开发人员开始他们的第一份工作时，他们常常被这种恐惧所引导，并在沉重的压力下退缩到自己身边，试图自己解决所有问题。此外，一个人周围可能有更有经验的同事，这些同事反过来又能为他或她指明最有前途的方向，帮助避免更多的错误和不必要的“麻烦”。所以请记住：不要害怕提问。您是初学者，每个人都非常了解这一点。当你提出要求时，没有人会用棍子打你。甚至可能会发生相反的情况：你会更快地与同事成为朋友，并开始享受与他们更积极的交流。我' 我会说得更多：你提出和讨论各种技术问题的次数越多，你就能越快地摆脱你的新手绿色皮肤并成长为你所在领域的专家。还有一条建议。不要陌生计算器。我是专门谈论在这个资源上提问的。一方面，需要一些时间才能得到您问题的答案。但另一方面，您可能会很快学会多种解决问题的方法，并从稍微不同的角度看待问题。我还想指出，撰写评论/答案和撰写澄清其他开发人员提出的关于 StackOverflow 问题的问题有实际好处：您有机会辩论和深入研究问题，更不用说业力提升了。

2. 不尝试自己搜索信息

这个错误可以被认为是前一个错误的反面。在这里我的意思是当你开始纠缠你的同事和熟人关于你遇到的每一个问题或小问题时。问是好的，但不要过度提问。否则，人们可能只会觉得你很烦人。如果你对某件事感到困惑，首先要做的就是在最好的搜索引擎——谷歌上锻炼你的搜索技巧。其他人已经遇到了绝大多数无法理解的错误和其他问题。如果您用谷歌搜索您的问题并看到熟悉类似问题的人数，并且已经收到您可以在自己的工作中应用的详尽答案，您会感到非常惊讶。这就是为什么您会经常听到您的同事回复“Google it”。大学教师' 不要被这个答案冒犯——你的同事不是你的私人老师，他必须传达你工作领域的所有微妙之处。无边无际的互联网将是你的良师益友。有时程序员也被称为在 Google 搜索中获得黑带的人。所以如果我们有一个“打嗝”，我们首先用谷歌搜索这个问题。如果找不到解决方案（这种情况很少见，但确实会发生），我们才会开始询问同事。直接问题是为了获得关于应该选择哪种方法来解决问题的建议，而不是当你遇到减速带或无法理解的错误消息时你会做什么。毕竟，他们可能能够超越您的首选方法，并立即预测任何给定方法从长远来看会走向何方。

3、盲目复制粘贴

但是谷歌搜索问题及其解决方案有其缺陷。比如盲目的复制粘贴。当您发现类似的问题（但可能不完全相同）和相关的解决方案时，通常会发生这种情况，例如，在 StackOverflow 上。您获取此解决方案并复制并粘贴它，而无需进一步深入研究细节。然后您或您的同事会在您的代码中发现一些奇怪的错误或不正确的行为。没有人能立即猜出它们来自哪里。最终当然会找到复制代码的地方，你的解决方案肯定不会被表扬。因此，当您在 StackOverflow（或其他任何地方）上找到现成的解决方案时，您必须首先彻底了解 what、how 和 why。也许谷歌相关功能并阅读它的文档。只有在你完成之后，你才应该将它添加到你的项目中。

4.坚持错误的解决方案

在编写解决方案时，有时会发现它不断地变得越来越复杂，最终走到了死胡同。然后你尝试使解决方案更加详尽，以便以某种方式使其发挥作用，而不是寻找另一个更合适的替代方案。也许你觉得自己投入了很多时间和精力，因此决定无论如何都不会放弃，你会用现有的方法解决问题。这不是完全正确的态度。至少在编程方面。越早尝试不同的方法，最终节省的时间就越多。因此，无论您在当前方法上投入了多少时间，都不要害怕尝试其他方法。更重要的是，通过尝试多种方法并更深入地研究该主题，您

5. 害怕询问有关您当前任务的问题

从事软件开发项目通常归结为执行特定任务。例如，在吉拉. 这些任务并不总是清晰详细地概述。任务描述通常由团队负责人撰写，他们也不过是凡人。他们可能会忘记添加一些东西，或者没有说明您不熟悉这个或那个功能的事实。或者，您可能没有对该项目的任何访问权限（例如，对数据库、日志服务器等的访问权限）。而现在，你接到了任务，研究了两个多小时，却还坐在那里，茫然地盯着屏幕。与其继续尝试理解这一点，但没有成功，您应该开始向创建任务的人寻求澄清或指导。例如，在你的团队用于交流的应用程序（例如 Microsoft Teams）中，你可能会就任务提出问题或直接发表评论。一方面，如果您将问题写在个人消息中，您可能会更快得到答复，因为对方会立即看到您的问题。另一方面，通过在 Jira 中提问，您可以证明您正在做某事，即分析问题。有一种方法可以加速此过程：在 Jira 的评论中提出您的问题，然后在 DM 中，添加指向您评论的链接并要求查看。

6. 对团队领导寄予不切实际的高期望

同样，这是前一点的反面。团队负责人是开发团队的负责人。通常，您的团队领导将大部分时间花在各种沟通上。然而，他或她也编写代码，以便不忘记关于编程的一切。如您所知，团队负责人的生活非常忙碌。每次你需要打喷嚏时拉着你的团队领导的袖子显然是不愉快的。想象一下团队中的每个成员都用一堆问题轰炸领导。这会让任何人发疯，对吧？如果你堆积了很多问题，那么你的团队领导将不得不花很多时间来回答你。可以做些什么来减少针对团队领导的问题数量：

• 更深入地探索项目文档以减少盲点的数量。
• 将您的问题转给您的其他团队成员。他们可能和领导一样熟悉这个功能，甚至可能更熟悉，因为这个功能很可能是由他们中的一个人编写的。

或者，您可以查看 IDE 中的注释，了解特定行中的代码最后一次更改的人员和时间。这正是您如何找出最适合提出问题的人。正如您可能已经意识到的那样，当涉及到向团队负责人提问时，就像向同事提问一样，您需要尝试找到一个快乐的媒介——不要害怕提问，但也不要问太多他们中的。

7. 害怕代码审查

代码审查就是这样一个阶段，发生在你将你的代码提交到一个公共应用程序（到一个共享分支，例如 master 或 dev）之前。此检查由未参与该任务的开发人员执行，他们的新鲜眼光可以检测您的代码风格中的错误、不准确或缺陷，这些错误、不准确或缺陷在您最初编写代码时没有被注意到。如果有批评，它们将作为对代码某些部分的评论留下。在这种情况下，编写代码的开发人员必须更正审查中发现的错误（或与审查者讨论他的决定，可能说服他或她他们是正确的）。然后代码一次又一次的提交review，直到reviewer没有更多意见为止。在提交代码之前，审阅者充当“网关”。挑战在于许多新手程序员将代码审查视为批评和谴责。他们不欣赏代码审查并且害怕它们。他们不应该。代码审查正是让我们改进代码的原因。毕竟，我们收到了关于我们做错了什么以及什么值得关注的重要信息。您应该将每次代码审查视为学习曲线的一部分，这可以帮助您变得更好。当有人评论您的代码时，他或她正在与您分享经验和最佳实践。我个人认为如果不进行代码审查，您就无法成为一名优秀的程序员。因为你甚至不知道你的代码的质量，也不知道有经验的局外人是否会指出错误。不欣赏代码审查并且害怕它们。他们不应该。代码审查正是让我们改进代码的原因。毕竟，我们收到了关于我们做错了什么以及什么值得关注的重要信息。您应该将每次代码审查视为学习曲线的一部分，这可以帮助您变得更好。当有人评论您的代码时，他或她正在与您分享经验和最佳实践。我个人认为如果不进行代码审查，您就无法成为一名优秀的程序员。因为你甚至不知道你的代码的质量，也不知道有经验的局外人是否会指出错误。不欣赏代码审查并且害怕它们。他们不应该。代码审查正是让我们改进代码的原因。毕竟，我们收到了关于我们做错了什么以及什么值得关注的重要信息。您应该将每次代码审查视为学习曲线的一部分，这可以帮助您变得更好。当有人评论您的代码时，他或她正在与您分享经验和最佳实践。我个人认为如果不进行代码审查，您就无法成为一名优秀的程序员。因为你甚至不知道你的代码的质量，也不知道有经验的局外人是否会指出错误。做错了什么以及值得关注的地方。您应该将每次代码审查视为学习曲线的一部分，这可以帮助您变得更好。当有人评论您的代码时，他或她正在与您分享经验和最佳实践。我个人认为如果不进行代码审查，您就无法成为一名优秀的程序员。因为你甚至不知道你的代码的质量，也不知道有经验的局外人是否会指出错误。做错了什么以及值得关注的地方。您应该将每次代码审查视为学习曲线的一部分，这可以帮助您变得更好。当有人评论您的代码时，他或她正在与您分享经验和最佳实践。我个人认为如果不进行代码审查，您就无法成为一名优秀的程序员。因为你甚至不知道你的代码的质量，也不知道有经验的局外人是否会指出错误。

8. 做出神秘决定的倾向

各种任务/问题通常可以有几种不同的解决方案。在所有可用的解决方案中，初学者倾向于使用最复杂和神秘的解决方案。这是有道理的：就在昨天，新手程序员学习了很多不同的算法、模式和数据结构，因此他们迫不及待地想要实现其中的一些。相信我，我就是那样的人，所以我知道我在说什么 :) 我曾遇到过很长一段时间都在实现某些功能的情况。结果非常非常复杂。然后高级开发人员重写了我的代码。当然，我很想看看他改变了什么以及如何改变它。我查看了他的实现，并对它的简单程度感到惊讶。而且代码少了三倍。同样令人惊讶的是，此功能的自动化测试没有被删除或更改！换句话说，一般逻辑保持不变。由此，我得出的结论是最巧妙的解决方案总是很简单。意识到这一点后，编码变得容易多了，我的代码质量也跳到了一个更高的水平。那么什么时候值得应用设计模式和奇特的算法，你会问？应用它们将是最简单和最紧凑的解决方案。

9. 重新发明轮子

轮子是很久以前发明的一种耐用解决方案。在这种反模式中，开发人员针对已经解决的问题实施他或她自己的专有解决方案。有时这些现有的解决方案比程序员想出的要好。通常，重新发明轮子会导致时间浪费和生产力下降，因为您找到的解决方案可能远非最佳解决方案，或者，您可能根本找不到。也就是说，我们不能排除创建我们自己的独立解决方案的可能性：如果我们这样做了，那么剩下的就是复制和粘贴编程。无论是使用现成的解决方案还是创建定制的解决方案，程序员都应该以出现的特定编程任务为指导，以便胜任和迅速地解决它们。一方面，在大学和在线课程中，我们被各种各样的任务轰炸，这些任务似乎旨在帮助我们重新发明轮子。但乍一看：这里的真正目的是培养算法思维和更深入地掌握语言语法。此类任务还可以帮助您更好地理解算法和数据结构，并在必要时为您提供实施更复杂对应物的技能（这有时是必要的，但极为罕见）。在现实生活中，绝大多数情况下你不需要自己发明轮子，因为满足你需求的轮子早已存在。也许您的经验不足使您无法了解所需功能的实现。这是您需要采纳本文第一点中给出的建议的地方，即，向更有经验的同事寻求帮助。他们将能够指导您（例如，在您的 Google 搜索中为您指明正确的方向）或建议具体的实施方式（例如，某些图书馆）。

10. 没有写测试

所有新手都不喜欢写测试。但是我们为什么要在这里挑出新手呢？更多经验丰富的开发人员也不喜欢编写测试，但他们更了解为什么需要测试。当你完全是绿色的时候，你想知道为什么要写它们。一切正常，所以不会有任何错误。但是您如何确保您的更改不会破坏系统中其他地方的某些东西？如果您推行弊大于利的变革，您的同事将不会感激。这是测试来拯救我们的地方。测试覆盖的应用程序代码越多越好（这称为代码覆盖率或测试覆盖率）。如果应用程序具有良好的测试覆盖率，那么您可以运行所有测试以查找将被您的代码破坏的地方。正如我在上面的例子中所说的，当高级开发人员重构代码时，测试没有失败。这是因为一般逻辑没有改变。我们使用测试来证明某些功能的逻辑是否发生了变化。因此，即使您不喜欢编写测试，它们也绝对有用并且非常值得花时间在上面。

11. 过度评论

许多开发人员患有完美主义，新手也不例外。当他们开始评论每个人和每件事时，有时他们只会表现出这种倾向的一个方面。甚至进行不必要的注释，因为代码非常明显：

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

并不是所有的新手程序员都能立即意识到注释代码并不总是好的，因为多余的注释会使代码混乱并难以阅读。如果代码发生变化，但旧注释没有更新怎么办？那他们只会误导我们，使我们迷惑。那为什么要发表这样的评论呢？通常，编写良好的代码不需要注释，因为其中的所有内容都已经显而易见且可读。如果您需要写注释，那么您已经破坏了代码的可读性并且正在尝试以某种方式补救这种情况。最好的方法是从一开始就编写可读代码，即不需要注释的代码。我也忍不住提到需要遵循正确的方法、变量和类命名约定。这是我的规则： 最好的注释要么没有注释，要么正确命名，清楚地描述您的应用程序中的功能。

12. 糟糕的命名

新手在类、变量、方法等的命名上玩得既快又松散。例如，创建一个名称根本无法描述其用途的类。或者他们用短名称声明一个变量，例如x。他们在另外两个名为n和y 的变量时被创建，记住 x 负责什么变得非常困难。面对这种情况，您必须仔细考虑代码，在显微镜下分析它（可能使用调试器），研究功能，以便简单地了解发生了什么。这就是我上面提到的正确命名约定对我们有所帮助的地方。正确的名称可以提高代码的可读性，从而减少您熟悉代码所需的时间，因为当方法的名称大致描述其功能时，使用方法要容易得多。代码中的一切都由名称（变量、方法、类、对象、文件等）组成，因此在创建正确、干净的代码时这一点变得非常重要。您应该记住，名称应该传达含义，例如变量存在的原因，它的作用，以及它是如何使用的。我会不止一次地指出，对变量最好的注释是给它起一个好名字。为了更深入地研究评论和正确的命名，我推荐阅读永恒的经典：“整洁代码：敏捷软件工艺手册”，作者 Robert Martin。关于这一点，本文的第一部分（我的思考）已经结束。待续...