在星期一的一天，我想到了这个想法-“但是我挖掘了新的核心”（相对较新，但稍后会更多）。 这个想法并非突然出现，但前提是：
- 测试任务，来自俄罗斯母亲的大型工作室之一（出现ORM的缩写），
- 编写简单模块的想法，
- 将来一位顾客希望开设一家商店的愿望。
因此，我想在茂密的热带丛林中分享这场运动的故事。
简短介绍
我不认为自己是Bitrix还是其他任何东西的编程专家。 这篇文章反映了我的观察，经验和想法。 建设性的批评以及理智上的纠纷（如苏格拉底遗赠的）都受到欢迎。 背景突出显示了三个未解决的广泛主题。 就像他们的主要方面一样- 程式设计 在Bitrix D7内核（ORM）框架内处理数据，尽管这是编写数据的基本因素。
在头上的游泳池
我认为，无处不在是数据处理工作的基础，没有它，我决定马上就去做。 谷歌 查看文档，希望获得详细的说明和示例的可用性，当然还要查看课程。 用轻松的手，希望有新鲜美味的东西。 不用担心，我去露营了。 乌云密布...
您需要了解的丛林或生存规则
规则1-提防不道德的旅行社
我决定从课程开始，看到了令我感兴趣的菜单项（模块和ORM），我以为有一堆文本和代码插入-一切都会很快，我们走吧……所以下一个错误就出了。 实际上，事实证明：
课程结构不佳 -没有考虑学习顺序，您会发现各章之间没有任何联系；
永久链接 -我不是在谈论文档链接，而是堆栈溢出链接和其他章节（在课程结束时，之间有大量的信息）非常分散注意力，这并不严重；
水和常用词 -您可以检查字符数；
粗体字用于突出显示重要的单词，术语，短语和句子。 也就是说，在所述功能的上下文中特别重要的是：
以自己的方式解释概念仍然是一个古老的话题（API-组件-模板，又称MVC）；
从文档中插入 -全部复制粘贴，有时只是为了填充一个地方；
来自开发人员的报价 -根本没有单词-_-，这是为什么？
过时的章节 -似乎无法删除它们；它们有时会加剧混乱。
实体（过时）或产品折扣设置之间的关系
当然，加号是，原则上讲，有课程。 可能是一个加分，因为仅根据其内容编写内容仍然是一项任务。 哦好 在复习了课程之后，主要是插入了代码，我决定尝试一下，但是仍然有文档。 开始下毛毛雨...
规则2-提防密集的灌木丛
使用了几个简单的样本 透明胶带 文档，我决定尝试对商品进行折扣。 然后雨开始了。 假核和复活节彩蛋：
- 折扣的两个模块 -是的，我想了很长时间-为什么要添加折扣，折扣存在于产品中，但是我无法通过
DiscountTable实体类获得DiscountTable 。 我不得不写支持。 答案是这样的：
DiscountTable-商品折扣，属于模块Trade Catalog，该功能已过时且未使用。 我们建议使用购物车规则。
- 缺少文档 -但您可以获取文档的链接-询问
我 期望她从2013年到2015年出现。 答案是：
用于创建篮子规则的文档仍在开发中。
- 没有考虑到工作方案 -我的下一个问题是合乎逻辑的-如何获得折扣？ 我收到了一个迷人的答案，并在支持下结束了沟通：
要获取适用于该产品的购物篮规则，您将需要创建一个购物篮对象并为该产品执行计算。
要添加产品折扣，请使用调用CCatalogDiscount :: Add（）
- 复杂的体系结构 -要创建多个表的复杂选择，必须使用特殊的关系对象，这些对象必须添加到
SomeTable::getMap()方法中。 这并不总是那么容易（某些实体描述类是自动生成的）。 而且，令人难以接受的事实是不可能仅以多维数组的格式获得复杂的样本。 关系的建立可能需要十几条线。 - 功能迷宫 -在D7中，有些地方会不断地被重写，同时支持所有变体。 可以通过以下方式实现相同的关系对象：
Entity\ReferenceField || Bitrix\Main\ORM\Fields\Relations || runtime （根据要求）
至少可以说，这一切令人非常沮丧，并使您愤慨。 除此之外，还有其他不便之处。
规则3-臭虫
Bitrix具有许多您经常会忘记的奇怪和侵入性的功能，但是它们再次在您的眼前闪烁：
- 类和文件命名规则 -您自己的叉车，将所有内容都简化为小写，不同的类和文件名；
- 连接第三方解决方案的方法 -例如作曲家或VUE
（它简单地包含在BX库中，没有任何明显的原因和附加组件） ;
UPD 1. Vue的修订深入探讨问题。
实际上，BX声称具有以下Vue包装器优点：
- 支持多语言（Bitrix Framework） -您可以将BX js中的某些功能添加到Vue组件中，并禁用它们的反应性；
- 全局事件总线 -用于应用程序之间的通信（如果有多个）；
- 组件继承 -语法糖，简单扩展；
- 组件的自定义 -语法糖，类似于替换（例如/ bitrix / components /和/ local / components /）；
- 该库的一个版本（在网站框架内） -这是合乎逻辑的，我并不立即考虑（感谢k0rinf ）。
- 支持旧代码 -一堆多余的，不必要的类和持续的混乱；
- 被遗忘的组件 -仅更新了iblock模块组件 ；
- 组件模板 -众所周知并且众所周知，具有随时可用的业务逻辑；
- 隐式逻辑和自定义问题 -更改订单脚本后，您可以捕获模块的细微错误和问题；
- 无处不在的静态 -您开始认为这是正常现象；
- 有争议的管理面板 -有时不方便也不适应，但要为其开发模块... mmm；
琐事，但它们总是在附近。
规则4-陌生人和本地人很危险
Bitrix还有一个好处（不是）-大型社区。 您可以找到任何信息，但是其正确性和相关性将是一个大问题。 通常，您只能学习如何创建拐杖或使用已经可以替代的古老代码。 但是也有一些弥赛亚可以为羊群出路。 其中之一说：
要使用信息块，请使用运行良好且稳定的旧内核。
我想我会这样做。
规则5-掠食者在附近某处
营销人员称赞产品。 Bitrix是无可争议的领导者的比较文章。 一堆 地板 程序员，就像我一样。 许多要求终止折磨的地点。 也是社区的祸害。
规则6-喝水
由于每个新问题以及缺乏适当的解决方案，道德下降， 你跳过一个动作 想法来了，但这就是浪费时间所需要的吗？ 框架，容器化和持续集成可能比这一半措施更好。 在这种情况下，只有坚决的决定 好，需求 保存情况。
规则7-热带雨很难
它完成了一个令人不快的事实，即尝试进行编程，搜索和构建信息，与专家交流并返回过去，学习新知识，这需要大量的时间，而缺乏清晰的结果-它会不断令人沮丧。
文明又名结论
在这里，您从丛林中出来。 破旧但还活着。 坏了但还是没有坏。 您疲倦的眼睛睁开，他们看到的一切。 一条真正值得走的路，以及需要特别照顾的路。
Bitrix是一个有争议的产品，说他 一般发展 发展不正确-不值得。 但是一味相信自己是最棒的，却没有注意到缺陷。
我自己决定，Bitrix-不。 当然，完全拒绝是行不通的，但是要开发一种产品，对于新的和已发布的内核，已经有5年没有出现对基本功能和可理解文档的支持了-我认为没有理由。 最好编写一个简单的解决方案，该解决方案将在旧内核上的各个项目中使用，然后学习新的解决方案。
当然，老人科学怪人值得一生，至少其中有两个值得一提的想法。 毕竟，我们不是在中世纪要烧死所有持不同看法的人。 还是值得您认为呢？
附言：如果您无法建立一致的思想链，那么本文将匆忙撰写。