自2018年初以来，我一直是团队的负责人/首席/首席开发人员-随心所欲，但最重要的是，我完全负责其中一个模块以及所有从事该模块的开发人员。 这个职位使我对开发过程有了新的认识，因为我参与了更多的项目，并且更加积极地参与了决策。 最近，由于这两种情况，我突然意识到理解的程度对代码和应用程序有多大影响。
我要表达的想法是，代码（和最终产品）的质量与设计和编写代码的人员对自己在做什么的了解密切相关。
您现在可能在想：“谢谢，盖帽。 当然，很高兴了解您所写的内容。 否则，如果获得相同的成功，您可以雇用一组猴子用锤子敲击任意键，然后对此冷静下来。” 你是绝对正确的。 因此，我认为这是理所当然的：您意识到，必须对自己的工作有一个大致的了解。 这可以被称为零了解度，我们将不对其进行详细分析。 我们将详细分析确切需要理解的内容以及它如何影响您每天做出的决定。 如果我事先知道这些事情，这将为我节省大量的时间和可疑的代码。
尽管您在下面看不到任何代码行，但我仍然认为这里所说的一切对于编写高质量的表达性代码都非常重要。
第一级理解：为什么它不起作用？
根据我的观察，开发人员通常在职业生涯的早期就达到了这一水平，有时甚至没有别人的帮助。 想象您有一个错误报告：该应用程序中的某些功能不起作用，您需要对其进行修复。 你会怎么做？
标准方案如下所示：
- 找到导致问题的代码（如何完成是一个单独的主题，我在过时的代码书中对此进行了披露）
- 更改此代码段
- 确保该错误已修复，并且没有回归错误
现在，让我们关注第二点-更改代码。 此过程有两种方法。 第一：深入研究当前代码中到底发生了什么，找出错误并进行修复。 第二：接触-在条件语句或循环中添加+1，例如，看看此功能在正确的情况下是否有效，然后尝试其他操作，等等。
第一种方法是正确的。 正如Steve McConnell在其《代码完成》一书中所解释的（顺便说一句，我强烈推荐），每次我们更改代码中的某些内容时，我们都应该能够自信地预测这将如何影响应用程序。 我引用了记忆，但是如果错误修正无法如您预期的那样起作用，那么对于您应该非常谨慎，您应该质疑整个行动计划。
总结以上内容，为了执行可靠的错误修复而不会降低代码的质量，您需要了解代码的整体结构和特定问题的根源。
第二层理解：为什么起作用？
与以前相比，该级别的直观性要低得多。 作为新手开发人员，我非常感谢老板，后来我又向初学者反复说明了此问题的实质。
这次，让我们假设您一次收到了两个错误报告：第一个是关于方案A，第二个是关于方案B。在这两个方案中都出了问题。 因此，您首先被发现第一个错误。 在第一层理解的原则指导下，您深入研究与问题相关的代码，找出为什么它迫使应用程序的行为与方案A中的行为完全相同，并进行合理的调整以使结果完全符合您的要求。预期的。 一切都很好。
然后转到场景B。您重复脚本以尝试引起错误，但是-令人惊讶！ -现在一切正常。 为了确认您的猜测，您取消了在处理错误A的过程中所做的更改，错误B再次返回。 您的错误修复解决了这两个问题。 好运！
您根本没有指望它。 您想出了一种方法来纠正方案A中的错误，却不知道为什么它适用于方案B。在此阶段，很容易决定两个任务都已成功完成。 这很合乎逻辑：关键是要消除错误，不是吗？ 但是工作尚未结束：您仍然必须弄清楚为什么您的操作纠正了方案B中的错误。为什么？ 然后，他可能正在遵循错误的原则，然后您将需要寻找另一种方法。 这是这种情况的几个例子：
- 考虑到所有因素，由于该解决方案不能专门针对错误B，因此您可能在不知不觉中破坏了功能C。
- 与某个功能相关的第三个错误也有可能被隐藏了，而您的错误修正使系统可以在脚本B上正常运行。 现在一切看起来都不错，但是美好的一天，这个第三个错误将被发现并修复。 然后，在方案B中，再次发生错误，如果只是在那里，也将发生错误。
所有这些都将随机性引入了代码中，总有一天它会落在您的头上-最有可能在最不适当的时刻出现。 您必须将自己的意志集中在拳头上，以迫使自己花时间了解一切似乎都起作用的原因，但这是值得的。
第三层理解：为什么起作用？
我最近的见解恰恰与此水平有关，如果我早些时候想到这个想法，它可能会给我带来最大的好处。
为了使它更清楚，让我们看一个例子：您的模块必须与函数X兼容。您对函数X并不是特别熟悉，但被告知您需要使用F.框架来与它兼容。其他与X集成的模块可以正常工作和他在一起。
从生命的第一天开始，您的代码就根本没有接触过F框架，因此实现它并不是那么容易。 这将对模块的某些组件产生严重的后果。 尽管如此，您还是要着手开发：编写代码数周，测试，推出试用版，获取反馈，修复回归错误，发现无法预料的复杂性，不适合最初约定的时间范围，编写更多代码，进行测试，得出相反的结论连接，纠正回归错误-所有这些都是为了实施框架F。
在某个时候，您突然意识到-或也许有人听到了-也许F框架根本不会给您与X函数的兼容性，也许所有这些时间和精力都没有应用对此。
在我负责的项目的工作过程中，曾经发生过类似的事情。 为什么会这样呢？ 因为我不太了解功能X的本质，以及它与框架F的关系，我该怎么办？ 要求负责开发任务的人员清楚地说明计划的行动计划如何导致期望的结果，而不是简单地重复对其他模块所做的工作，或者说功能X必须起作用。
这个项目的经验教会了我拒绝开始开发过程，直到我们对为什么要执行某些操作有了清楚的了解。 拒绝纯文本。 当您收到任务时，第一个冲动就是立即处理它，以免浪费时间。 但是“冻结项目直到我们进入所有细节”的政策可以将浪费的时间减少几个数量级。
即使他们试图给您施加压力，也迫使您开始工作，尽管您不了解这样做的合理性，但还是要抵抗。 首先，找出为您分配此类任务的目的，并确定这是否是实现目标的正确途径。 我必须通过痛苦的经历来学习所有这一切-希望对于那些阅读本文的人，我的榜样将使生活更加轻松。
第四级理解：
在编程中总是要学习一些东西，我想我只是触及了理解主题的最顶层。 在使用代码的这些年中，您还发现了其他哪些理解水平？ 做出了哪些对代码和应用程序质量有良好影响的决定？ 哪些决定被证明是错误的，并教您了宝贵的一课？ 在评论中分享您的经验。