在编程中遇到3个代码问题：Hardcode，Govnokod和Schizokod。
让我们来谈谈。
硬编码
当程序员由于匆忙或懒惰而在不考虑变量的情况下编写代码时，这是一个众所周知的问题。 也许最常见的情况是站点的域。 它可能因环境而异，并且经常引起很多麻烦。 这里的一切都很简单。 在不同的平台上，这可以通过不同的方式解决。 最主要的是遵守平台内采用的协议和规则。
通常，此类问题可以快速发现并轻松解决。
戈夫诺科德
这是一个更困难的问题。 经常是主观的。 粗略地说，这违反了负责人，团队或社区所采用的代码风格。
根据平台，甚至有时在平台内部，存在不同样式的代码：
这来自php世界。 在其他社区，情况类似。 这还包括有关选项卡，2个空格后的选项卡或4个空格后的选项卡的故事，等等。
这里出现纯代码的问题，例如3-4页的长函数，这受到了批评。 这不一定总是很糟糕，但是通常可以使这些函数更短，将它们分成一系列短函数，每个短函数都可以解决自己的问题。
通常，可以通过软件和特定团队中公认标准的控制轻松解决这些问题。
特技飞行，当开发人员可以根据项目在不同样式的代码之间切换时。
当开发人员违反团队采用的代码风格或认为自己喜欢的（通常是唯一学习的）代码风格是唯一正确的代码时，这很糟糕。
没有正确的代码样式。 团队中有批准的样式或公认的样式。
也是一个比较简单的问题，很容易解决。
裂殖体
这是一个不太受欢迎的问题，但通常是最昂贵的问题。
精神分裂症-来自精神分裂症的概念。 挤压维基百科：
精神分裂症（源自其他希腊语：“分裂”，“分裂” +φρήν-“思想，思想，思想”），先前为拉特。 老年痴呆症（“过早性痴呆”）或精神分裂症是与思维过程和情绪反应崩溃有关的内源性多态性精神障碍或一组精神障碍。
有两个要点：分裂和痴呆。 哪些是schizocode的原因。
理想的代码是未编写的代码。 编解码器对此概念不熟悉。
简而言之，schizocode是违反Occam的Razor原理的代码。
挤压维基百科：
“奥卡姆剃刀（刀片）”是一种方法论上的原理，以英国和尚方济各会（名义哲学家威廉·奥克汉姆）的名字命名。 它以简化形式显示为：“您不应该在不需要的情况下将现有的内容相乘”
事实表明，开发人员没有充分的理由就开始使代码和体系结构复杂化。 或原因的分量仅存在于他们的想象中。
想象中的问题-不良软件的根源
有两个主要症状：拐杖处的自行车发明和抽象层的增加。
拐杖自行车的发明
有人表示，鉴于学习能力差，开发人员开始发明自行车/拐杖，而不是在平台和现有体系结构的框架内寻找最佳解决方案/方法。
范例：
- 编写自己的CMS / ptm框架，发现现有框架存在致命缺陷
- Symfony博客 尽管事实上全世界都在使用WordPress。
- 尽管有WooCommerce（世界排名第一），Magento（还不错），1C-Bitrix（最糟糕的是，比Laravel更好）的事实，但Laravel上的在线商店
- 我遇到的情况是版式位于Bootstrap上，但开发人员决定为标签编写自己的样式。 是什么导致您无法添加Bootstrap已经拥有的标签类？
- 冗余函数，方法和类没有演算，可以使用所用平台中的现成库和方法避免这种演算
抽象层的不受控制的传播：额外的类，继承，方法
细心的读者可能会注意到与govnokod发生冲突。 在一种情况下，问题在于函数或类太长，但问题在于相反地，实体存在过多的碎片。
在此应注意，这是极端情况之一，其边界并不总是容易观察到的。
一方面，尝试用3页上的一个函数或包含HTML和模板机制的类来解决所有问题是不好的，而将代码分解为多个函数/类/组件则更有利可图，每个函数/类/组件都可以解决自己的问题。 这是一个极端。
另一方面，将非常简单的代码分为5类，每类都有3-4行的3-4种方法，具有许多无用的继承，如果可以避免，则可以在最小继承甚至不继承的情况下进行一两个操作。
多余和不良抽象的后果
方法，类，继承的传播没有充分的理由-这是多余的代码和抽象层的增长。
一切都有价，还有额外的抽象：
- 新开发者培训受到宠爱
- 更多的代码，更多的故障点，更多的错误
- 诊断和代码调试很复杂
思想问题
抽象，继承，方法的层越多，对问题的更改，改进和诊断就越需要思想燃料。
并且燃料的工作量是有限的，并且通常其短缺需要非常大的开发成本。
每个进行诊断并更改分类码的开发人员都依赖于缺乏思想的动力。 但是，并非所有人都意识到这一点。
一段解释燃油想法的视频，并进行了1分钟的简单练习，使您可以通过一个简单的示例来回想一下燃油短缺的感觉：
它是否运行到OOP，类和继承中？
一点也不。 但是，这有些道理。 在实用的样式中，novokovodit较容易，但是schizokod很难做到。 一方面，OOP具有许多优点，但也为schizocode开拓了范围。
OOP，类和继承都不是坏事。 这些是工具。 我个人使用它们。
但是，我有一些自己的规则：
- 由于封装，我几乎总是写类，但通常我有足够的Singleton，静态方法和无状态
- 在存在常用方法的地方，我编写的函数通常只是类的方法的包装器，但有时函数只是没有类的函数，在适当的情况下这样做是好的。
- 有状态的类-是的，但只有在有充分理由的情况下，才会频繁地重复
- 继承更为罕见，只有在有充分理由的情况下（我试图减少抽象层并节省团队的思想和精力），继承才更加罕见。
总结
我们谈论很多有关硬编码和govnokode的信息，因为 它们是可以理解且容易理解的。 但是，schizocode通常不受惩罚，因为要识别和理解其危害程度会更加困难。 而且由此带来的危害可能超过一举而过的想象。
我的清单很简单：
- 在发明另一辆没人需要的拐杖自行车之前，最好先学习“最佳品种”原则
- 让我们少写schizocode
- 让我们学习遵守Occam的Razor原理，并且无缘无故地使代码复杂化
- 让我们保存思想和团队
好吧，我将很高兴评论支持宣言及其批评的观点。