碰巧的是，我大部分有意识的生活都是用PHP编程的。 我们的大脑可以从任何来源感知信息，而不会受到该来源权威的干扰。 粗略地说，如果您喜欢PHP，则会自动为本文的作者添加信誉点，如果您不喜欢，则会自动将其删除。 这个过程发生在无意识的水平上，本质上是感知的棱镜，一方面防止我们陷入对任何权威程度的信息的无休止的分析，但另一方面限制了我们寻找新的，更相关的信息。 最糟糕的是，很少有意识地检查来源的可信度（因为它需要时间和资源以宝贵的卡路里的形式），所以我有相同的可能性成为正开发商，家庭主厨，没有公主的水管工或经过基因改造的人猫 不要严格判断我的文章，我有爪子。
阅读他人的代码也是如此：如果作者坐在您宝座的左手，已经在您的公司工作了10年以上，并且比您赚了零，这绝对不同于被炒鱿鱼的作者-太糟糕了，您被他录用了。 但是实际上，这里和那里的代码只有一组字节，对不参考源权限的情况进行评估就很有用。
当我们阅读别人的密码时，各种各样的情绪都会来拜访我们：钦佩，笑声，发怒，失望，完全拒绝。 知道在任何情况下任何情绪的表现都是原始环境中必需的以进化方式形成的神经系统的较低（第一）水平的自动响应，这是很有用的。 在产生“消极”情绪的情况下，这种回答的主要任务是启动具有一个目标（生存）的“命中或逃逸”行动机制。 在我们当前的办公环境中，分析别人的代码时，这样的答案变得非常无用，甚至有害，因为您在上面花了宝贵的时间和资源，另外，您还用神经递质污染了大脑，以降低反应速度，从而降低了机智。 好消息是，这个答案可以重新编程。 您可以抑制负面的情绪反应，也可以清点它们，例如，在以前生气的地方大笑。 与愤怒不同，笑声会向大脑抛出有益，美味，有用的神经递质，使人愉悦，增强经验并激发您继续工作。
为了重新编程情绪，您需要在思维上进入一个元位置，以便评估自己的情况并评估自己，而不是谴责别人的代码。 为什么这段别人的代码令我反感？ 真的是业余爱好者写的吗，现在我必须受得那么好而且经验丰富？ 如果我是如此的优秀和有经验，那么为什么我在理解别人的代码并按照我认为合适的方式重写代码时遇到问题？ 也许我只是没有足够的RAM来实现这种面条？ 也许这篇文章的作者知道我不知道的东西？
现代化的开发工具可让您几乎即时将他人的代码转换为更易于理解和使用的结构。 函数或变量的命名很差-ctrl + shift + R，并在几秒钟之内被永久调用。 制表符代替空格，不便之处在于，缩进的缩进和埃及风格的右花括号异常分散-Ctrl + shift + F和格式已恢复！ 注释多余或过时-Ctrl + D，不是。 如果您改变了感知的棱镜，阅读别人的代码可能会变成有趣的交互式侦探游戏。
代码只是一种工具。 无论他被写得多么糟糕和可怕，在特定的时间和地点，他都成功地解决了一个特定的问题，这意味着他已经“有道理”。 业务需求发生了某些变化，没有考虑到某些问题-代码已损坏或过时，这是正常的。 该代码具有以多种方式发展的能力：逐渐地，层层覆盖并具有革命性，从头开始编写。 当然，当程序员预见未来，并在初始阶段将代码中可能进行进一步开发的时候，这是很好的。 但是，这把斧头在两侧都很锋利，您在预测未来时可能会犯错误，未来可能根本就不会出现，并且时间和资源将不可避免地丢失。 了解代码对您的质量要求非常重要。 如果这是一个庞大的分布式系统，并且由您的世界各地的同事在与您联系不紧密的公司中为其编程的模块，那么是的，使用流行的模式将模块包装在服务容器中是有意义的，即使您无法想象为什么需要。 但是，如果这只是一家公司的小型本地CRM，那么它们的模块之间是如此严格地相互依赖，以至于禁用任何模块都会从根本上阻止整个系统的工作。在这种情况下，可以直接调用其他人的方法，这样可以减少类的数量并简化您的操作内存并减少调试问题的时间。 但是，当小型的本地CRM变成您的公司希望在公共领域销售的可扩展产品时，就会出现这种情况。 业务需求已更改。 应该责怪程序员没有预见到这一点吗？
标准化
代码只是一种工具，但是它的创造只是纯粹的创造力。 任何问题都可以通过无数种最多样化的方式来解决。 其中一些比其他一些生产力更高-这是客观评估的一个例子。 其中一些比其他的更具可读性-这是主观评估的一个例子。 即使您使整个办公室确信某些代码不可读，仍然会有至少一位作者不同意您的意见。 代码的标准化旨在将纯粹的创造力转化为最常规的操作，以使其他程序员更容易理解您的代码。 也就是说，实际上，这样可以让您换一个更温顺，更便宜的专家来代替。 几十年后，这完全是人工智能。 值得记住的是，如果某个标准与常识相违背，则在某些地方违反该标准，甚至完全放弃该标准或将其替换为另一个更合适的标准可能是有意义的。
成熟的标准从“选择标准时，要注意社区的普及”这一立场推销自己。 我不知道他们刚出来时如何推销自己。 主要思想是，选择特定标准不是您首先要考虑的因素。 人气和社区是非常惰性的，并且几十年来可能会拒绝更好的新标准。 特别是如果它们具有革命性。
特别要注意那些已经在文化中彻底确立自己地位的标准，仅仅是因为它们比其他类似标准要早出现。 一个典型的例子是QUERTY和Dvorak布局之间的圣战。 第二个显然更好，但是第一个受到打击（仍然很流行），仅仅是因为不愿再接受新培训的大量用户所致。
一直以来，在编程文化中都发现了类似的例子。 PSR标准代表4个空格而不是制表符，而忽略了一个显而易见的事实：大多数PHP程序员的开发环境已经从控制台编辑器更改为成熟的IDE，在这种情况下，制表符在许多方面都更加方便：只需按一下Backspace即可将其删除，并且您可以配置各个长度标签品尝。
在应用此标准或该标准时，请提出以下问题：您对谁更方便？ 谁更不舒服？ 谁将从“命名lowerKamelKeysom方法的名称”规则中受益？ 显然，只有那些习惯于称呼他们的人才可以。 其他所有人都会感到不舒服，他们将不得不适应，而浪费时间和资源绝对是从零开始的，因为事实是
a）现在我们有了神奇的IDE，可以用不同的颜色突出显示代码的不同元素，
b）程序员有能力从一个项目跳到另一个项目，编码标准可能会有所不同。
就个人而言，在开发项目时，我使用：
- CamelCase用于命名类和方法
- $ CamelCase用于命名包含对象实例的变量
- $ snake_case用于命名包含简单类型的变量
我将类名与方法名区分开来没有问题，因为第一个是名词，第二个是动词。 此外，背光有助于解决问题。 但这是我的个人品味，我不会将其强加给任何人。 这是个人感知的棱镜，对于每个人的头部都是独立的。 有人“很幸运”立即进入流行的标准，有人“不幸”地开始了另类职业的职业生涯，而有人通常发展了自己的职业。 我正带您一个事实，那就是与其重新培训他人，不如重新培训自己以理解任何标准的代码，这是有意义的。 甚至超出标准。
当然，这个地方的标准化拥护者会很生气，这使我有很多理由反对。 本文不是为他们准备的，我是为那些对了解事物的本质感兴趣的人写的，试图想象作者的真实想法和追求的目的。
能够理解别人的代码
在绝大多数程序员中引起呕吐冲动的触发器（一个主观评估的例子）。 对您来说，这从来都不奇怪，对于我们来说，从头开始重写所有代码通常比理解别人的代码容易吗？ 在其他任何行业中，我们的行为方式都是不同的：首先我们学习阅读，然后写作。 首先使用（电器，建筑物），然后进行设计。 在我看来，重点在于我们的教育（特别是编程领域）。 我们被教导使用一些新近获得的知识，以最直接，最快捷的方式实现目标。 结果，我们将它们（知识）准确地结合在一起，直到“它”起作用为止，进行一点测试并将其发送给老师进行审核。 在我看来，最好在此过程中增加一个步骤，在此过程中，我们将代码与主代码进行比较，尽管这不是理想的且不是唯一正确的代码，但它提供了替代的解决方案，通常更为优化和易读。
至于触发器，为了将其关闭，就足以将自己放在精神上，将自己置于客户的位置，客户一生都在注视即将离任的程序员，他们声称前辈的工作是粪便，您需要重写所有内容以使其良好。 客户没有能力确定您是在说真话还是懒于理解别人的代码。 为了获得他在此问题上的信任，您应该深入研究他人的代码，并找到几个巨大的安全漏洞，并向客户展示它们。 但是即使在这种情况下，从业务的角度来看，“强化”也可能更有利可图。 特别是如果这是具有特定期限和金钱的外包。 应该责怪程序员吗？
结论
哇，嘘用字母I写。 代替早餐，而是通过搅拌器喝咖啡和黄油。
看得更深，想得更广泛，寻找替代方案。 永远不要停止发展。