自 2018 年初以来，我一直在团队中担任领导/老板/首席开发人员的职位 - 你想怎么称呼它就怎么称呼它，但重点是我对其中一个模块以及所有工作的开发人员完全负责在上面。 这个职位让我对开发过程有了新的视角，因为我参与了更多的项目并更积极地参与决策。 最近，由于这两件事，我突然意识到理解的程度对代码和应用程序的影响有多大。
我想说的一点是，代码（以及最终产品）的质量与设计和编写代码的人对自己所做的事情的了解程度密切相关。
你现在可能会想，“谢谢，队长。 当然，如果能够大致了解您所写的内容，那就太好了。 否则，你还不如雇一群猴子去敲任意键，然后就这样了。” 你是绝对正确的。 因此，我理所当然地认为你认识到对你正在做的事情有一个总体的了解是必要的。 这堪称零层次的理解，我们就不详细分析了。 我们将详细了解您到底需要了解什么以及它如何影响您每天做出的决定。 如果我提前知道这些事情，就会节省我很多浪费的时间和有问题的代码。
尽管你不会在下面看到一行代码，但我仍然相信这里所说的一切对于编写高质量、富有表现力的代码非常重要。
第一层理解：为什么它不起作用？
开发人员通常在职业生涯的早期就达到了这个水平，有时甚至没有其他人的任何帮助——至少根据我的经验。 想象一下，您收到了一份错误报告：应用程序中的某些功能无法运行，需要修复。 你将如何进行？
标准方案如下所示：
- 找到导致问题的代码段（如何做到这一点是一个单独的主题，我在关于遗留代码的书中介绍了它）
- 对此片段进行更改
- 确保错误已修复且未发生回归错误
现在让我们关注第二点——对代码进行更改。 此过程有两种方法。 首先是深入研究当前代码中到底发生了什么，识别错误并修复它。 第二：凭感觉移动 - 添加，比如说，+1 到条件语句或循环，看看该函数是否在所需的场景中工作，然后尝试其他方法，依此类推。
第一种方法是正确的。 正如 Steve McConnell 在他的《Code Complete》一书中解释的那样（顺便说一句，我强烈推荐这本书），每次我们更改代码中的某些内容时，我们都应该能够自信地预测它将如何影响应用程序。 我是凭记忆引用的，但如果错误修复没有按您预期的方式工作，您应该非常警惕，并且应该质疑您的整个行动计划。
总结一下前面所说的，为了在不降低代码质量的情况下进行良好的错误修复，您需要了解代码的整个结构和特定问题的根源。
第二个层次的理解：为什么它有效？
这一级别的理解比前一级别要直观得多。 我当时还是一个开发新手，在老板的帮助下学会了它，随后又反复向新人解释了事情的本质。
这次，假设您同时收到两个错误报告：第一个是关于场景 A 的，第二个是关于场景 B 的。在这两种场景中，都发生了错误。 因此，您首先要解决第一个错误。 使用我们为 XNUMX 级理解而开发的原则，您可以深入挖掘与问题相关的代码，找出为什么它会导致应用程序按照场景 A 中的方式运行，并进行合理的调整以产生您想要的结果。 。 一切都很顺利。
然后您转到场景 B。您重复该场景试图引发错误，但是——令人惊讶！ - 现在一切都按其应有的方式进行。 为了证实您的猜测，您撤消了在处理错误 A 时所做的更改，错误 B 又回来了。 您的错误修复解决了这两个问题。 幸运的！
你根本没有指望这一点。 您已经想出了一种方法来修复场景 A 中的错误，但不知道为什么它对场景 B 有效。在这个阶段，很容易认为这两项任务都已成功完成。 这是非常合乎逻辑的：重点是消除错误，不是吗？ 但工作还没有完成：你仍然需要弄清楚为什么你的行为纠正了场景 B 中的错误。为什么？ 因为它可能遵循错误的原则，然后你就需要寻找其他出路。 以下是此类案例的几个示例：
- 由于该解决方案不是针对错误 B 量身定制的，因此考虑到所有因素，您可能会在不知不觉中破坏功能 C。
- 可能还潜伏着第三个错误，与相同的功能相关，并且您的错误修复依赖于它来保证场景 B 中系统的正确运行。 现在一切看起来都很好，但是有一天，第三个错误将会被注意到并修复。 那么在场景 B 中，错误会再次出现，如果只是出现就好了。
所有这些都会给代码带来混乱，并且有一天会落在你的头上 - 很可能是在最不合时宜的时刻。 你必须鼓起你的意志力，强迫自己花时间去理解为什么一切似乎都有效，但这是值得的。
第三层次的理解：为什么它有效？
我最近的见解正是与这个水平相关，如果我早点想到这个想法，它可能会给我带来最大的好处。
为了说得更清楚，让我们看一个例子：你的模块需要兼容函数X，你对函数X不是特别熟悉，但是有人告诉你要兼容它，你需要使用F框架。与 X 集成的模块与他完全兼容。
你的代码从F框架诞生的第一天起就完全没有接触过它，所以实现它不会那么容易。 这将对模块的某些部分产生严重后果。 然而，你全身心投入到开发中：你花了几周的时间编写代码、测试、推出试点版本、获取反馈、修复回归错误、发现不可预见的复杂情况、未满足最初商定的最后期限、编写更多代码、测试、获取反馈沟通、纠正回归错误——这一切都是为了实现 F 框架。
在某些时候，你突然意识到 - 或者可能从某人那里听到 - 也许框架 F 根本不会为你提供与功能 X 的兼容性。也许所有的时间和精力都投入到了完全错误的事情上。
在我负责的一个项目中，也发生过类似的事情。 为什么会发生这种情况？ 因为我对函数 X 是什么以及它与框架 F 的关系知之甚少。我应该做什么？ 要求分配开发任务的人清楚地解释预期的行动过程如何导致期望的结果，而不是简单地重复对其他模块所做的事情或相信他们的话，这就是功能 X 需要做的事情。
这个项目的经验告诉我，在我们清楚地了解为什么要求我们做某些事情之前，不要开始开发过程。 直接拒绝。 当你接到任务时，第一反应就是立即接受，以免浪费时间。 但“冻结项目直到我们了解所有细节”的政策可以将浪费的时间减少几个数量级。
即使他们试图向你施加压力，强迫你开始工作，尽管你不明白这样做的理由，也要抵制。 首先，弄清楚为什么要给你这样的任务，并确定这是否是实现目标的正确途径。 我必须以艰难的方式学习这一切 - 我希望我的例子能让那些读到这篇文章的人生活得更轻松。
第四层理解：？？？
编程总是有更多东西需要学习，我相信我只是触及了理解主题的表面。 在多年的代码工作中，您还发现了哪些其他层次的理解？ 您做出的哪些决定对代码和应用程序的质量产生了积极影响？ 哪些决定最终被证明是错误的并给你上了宝贵的一课？ 在评论中分享您的经验。
来源： habr.com