朋友和同事们最近在Habré文章上戴着反对1C的帽子，以此作为发展的平台，其倡导者的演讲也变得越来越频繁。 这些文章强调了一个严重的问题：1C批评家通常从“没有掌握”的角度对其进行批评，批评实际上容易解决的问题，相反，在没有涉及到真正重要的问题的情况下，存在讨论并且没有由供应商解决。 我认为对1C平台进行清醒和平衡的评估是有意义的。 她所知道的方式，她不知道的地方，应该做但不应该做的事情，以及甜蜜的一面，她在爆炸中做了什么，而您在％tech_name％上的开发人员将做一百年，扔掉超过一个年度预算。
这样一来，您作为领导者或架构师就可以清楚地了解-对于1C而言哪个任务有利可图，以及在哪里用热铁燃烧。 作为“非1C”世界的开发者，您可以看到1C中的内容，因为它引起了很多麻烦。 作为1C开发人员，您可以将系统与其他语言的生态系统进行比较，并了解您在软件开发坐标系中的位置。
剪裁下-为1C，批评家1C，Java，.NET以及一般情况提供了许多粗略的草图...风扇正在运行，欢迎大家！
关于我自己
从2004年左右开始，我就熟悉了这个主题。 从6岁起我就可能在编程，从那一刻起，我就获得了一本有关Fortran教授的书，里面有关于猫，麻雀和毛毛虫的漫画。 我从书中的图片中拆解了猫写的程序，并弄清楚它们在做什么。 是的，当时我没有一台真正的计算机，但是我被画在了页面上，老实说我按下了纸质按钮，输入了猫X监视的命令。
然后是学校的BK0011和BASIC，大学的C ++和汇编器，然后是1C，以至于太懒了以至于无法回忆。 在过去的15年中，我不仅从事编码方面的工作，而且主要从事1C方面的工作，主要从事1C方面的工作。 在此处设定目标，管理和人员。 在过去的5年中，我从事社会有益的活动，包括为其他1C昵称开发开发和自动化工具，并撰写文章和书籍。
确定讨论主题
首先，让我们决定要讨论的内容，因为字母“ 1C”可以理解很多东西。 在这种情况下，字母“ 1C”仅表示现代第八版的“ 1C：企业”的开发框架。 我们不会谈论太多有关制造公司及其政策的信息（但一定要说一点），也不会讨论使用此框架编写的特定应用程序。 单独使用技术，又称为配置应用程序-单独使用。
高层架构1C：企业
我故意提到“框架”一词。 从开发人员的角度来看，1C平台正是框架。 您需要像对待框架一样对待它。 考虑它是由某些运行时（分别为JVM或CLR）执行的Spring或ASP.NET。 碰巧的是，在普通的编程世界（“不是1C”）中，自然而然地将它们分为框架，虚拟机和特定应用程序，这是因为这些组件通常是由不同的制造商开发的。 在1C世界中，通常没有明确分配开发框架和实际运行时的习惯，此外，使用该框架编写的特定应用程序基本上也由1C自己开发。 结果，出现了一些混乱。 因此，在本文的框架内，我们将不得不同时考虑多个方面的1C并根据多个坐标轴对其进行分类。 在每个坐标轴上 铲入棕色物质 考虑现有解决方案的功能，优点和缺点。
1C观点
买方为1C
买方获得了一个自动化系统，他可以在该系统上快速解决使自己的业务自动化的问题。 一个企业可以是一个小摊位，也可以是一个大的股份。 显然，这些业务的需求是不同的，但是两者都由平台的单个代码库支持。
对于买方而言，1C可以快速推向市场。 快点 比Java，C＃或JS快。 平均而言。 在医院 显然，在响应中的名片站点会更好，但是WMS系统的后端将在1C上更快地启动。
1C工具
每种技术解决方案都有适用范围。 1C不是通用语言，它没有脱离其框架而存在。 建议您在需要时使用1C：
- 服务器应用
- 财务申请
- 具有现成的UI，ORM，报告，XML / JSON / COM / PDF / YourDataTransferingFormat
- 支持后台流程和工作
- 具有基于角色的安全性
- 具有可编写脚本的业务逻辑
- 具有快速的原型和较短的上市时间
如果需要，则不需要1C：
- 机器学习
- GPU计算
- 计算机图形学
- 数学计算
- CAD系统
- 信号处理（声音，视频）
- 数十万个rps的高负载HTTP调用
1C作为制造公司
值得了解1C作为软件制造商的业务。 1C公司通过自动化销售针对业务问题的解决方案。 大小不一的另一家企业，却只卖那种东西。 实现此目标的方法是业务应用程序。 用于记帐，工资核算等。要编写这些应用程序，公司使用其自己的平台来开发业务应用程序。 专为这些业务应用程序的常见任务量身定制：
- 财务会计
- 轻松定制业务逻辑
- 异构IT环境中的广泛集成机会
作为制造商，1C认为这是使您能够与合作伙伴和客户合作的双赢策略。 您可以对此进行争论，但是公司会这样进行自我宣传：针对业务问题的现成解决方案，可以由合作伙伴快速定制，并内置到任何IT环境中。
1C的所有要求或“愿望清单”，作为一个框架，应仅通过此棱镜考虑。 开发人员说：“我们希望在1C中实现OOP”。 1C说：“在平台上支持OOP的成本是多少，这将有助于我们增加盒子的销量吗？” 打开销售业务解决方案的“棱镜”：
“嘿，您要在1C中使用OOP吗？”
“这会帮助我解决问题吗？”
-怎么知道...
-那不用了
这种方法可能是好是坏，具体取决于谁在看，但这只是事实。 说到1C中没有特征X的事实，您需要了解它并不是有原因的，而是在选择“实现成本与利润规模”的情况下。
技术分类
“事实上，odnosniks正在使用最佳模式，这些模式是由有爱心的方法学家和1C平台开发人员精心选择的。
当您以简单，易于管理的形式编写愚蠢的代码时，实际上是在三层数据应用程序引擎中使用带有双向数据绑定的 model-view-controller，并基于声明性元数据进行了 高级对象关系映射 description ，具有自己独立于平台的查询语言 ，具有声明式数据驱动的用户界面，完整的透明序列化和面向领域的程序语言 。
1C开发人员与西方开发人员的不同之处在于PR。 他们喜欢给任何废话起个大名，然后像书面的麻袋一样匆忙处理。”
奥列夫科夫
1C平台具有经典的3层体系结构，其中心是应用程序服务器（或者它的仿真对小店主来说是很少的钱）。 作为DBMS，可以使用MS SQL或Postgres。 还支持Oracle和IBM DB2，但这更多是深奥的，没有人知道如果在中等和高负载下在这些基础上实现1C将会发生什么。 我相信1C公司本身也不知道这一点。
客户端部分可以是安装在用户计算机上的瘦客户端，也可以是Web客户端。 关键特性是程序员不必编写2种不同的代码，而是用一种语言编写一个应用程序，并且可以根据需要在浏览器中进行设置。 谁想要一个可靠的完整堆栈以及用于前端和后端的单一语言node.js？ 直到最后，他们都没有做完全一样的事情。 存在一个实际的完整堆栈，但是您必须使用1C进行编写。 具有讽刺意味的命运，诸如此类的事情:)
在浏览器模式下，“ 1C：新鲜云” SaaS解决方案也可以使用，您不能购买1C，但要租一小部分基地并保留此处的销售记录。 仅在浏览器中，无需自己安装或配置任何东西。
此外，还有一个旧版客户端，在1C中将其称为“常规应用程序”。 遗产，它是遗产，在2002年进入了应用程序世界，但是我们仍在谈论生态系统的当前状态。
服务器端1C支持群集，并通过向群集添加新计算机来进行扩展。 这里有很多副本被打碎了，关于这一点，本文将有一个单独的部分。 简而言之，这与在HAProxy之后添加几个完全相同的实例并不完全相同。
应用程序开发框架使用其自己的编程语言，该语言大致类似于稍作改进的VB6，已翻译成俄语。 对人 讨厌一切俄罗斯人 建议不要使用“ if”被翻译为“ if”的人使用第二种语法。 即 如果需要，可以写入1C，以便在外观上不会与VB区分开。
这种非常编程的语言是1C昵称帽子进入其平台的主要原因。 坦白地说，并非没有道理。 该语言被认为是尽可能简单的，旨在至少在CIS级别上实现“ DEVELOPERS，DEVELOPERS”的口头禅。 我认为，这种解决方案的商业本质显而易见：更多的开发人员，更多的市场覆盖。 根据各种估计，这一比例从45％变为95％。 我必须马上说，用您认为真的很容易的语言写作。 而且我知道很多编程语言。
我们将从语言开始。
1C编程语言
同时，系统的优缺点。 提供易于输入的可读性。 另一方面，自2002年发布第8版以来，它尚未更新，并且已经过时。 有人会说“主要缺陷-没有OOP”，这是错误的。 首先，巴解组织不仅不喜欢努拉利耶夫，而且不喜欢托瓦尔兹。 其次，OOP仍然存在。
从开发人员的角度来看，他可以使用一个框架，该框架具有显示在DBMS上的基类。 开发人员可以采用基类“ Directory”，并从中继承目录“ Clients”。 它可以向其中添加新的类字段，例如TIN和Address，并且在必要时还可以覆盖基类的方法，例如OnWrite / Prizapisi方法。
该框架的设计方式使得很少需要更深层次的继承，并且我认为OOP中的限制是有道理的。 1C专注于域驱动开发，首先让您考虑正在开发的解决方案的主题领域，这很好。 不仅存在诱惑，而且还需要编写10个不同的DTO和ViewModel来仅显示域中的某些数据。 1C开发人员始终使用一个实体进行操作，而不会用数十个名称相似但代表另一实体的类来阻塞感知上下文。 例如，任何.NET应用程序都必须包含五个或两个ViewModel和DTO，以便在JSON中进行序列化以及将数据从客户端传输到服务器。 应用程序中大约10-15％的代码将使用笔或拐杖（例如AutoMapper）将数据从一类转移到另一类。 该代码需要编写，程序员必须为其创建和维护付费。
事实证明，如果不将1C语言复杂化到主流语言水平，就很难开发它，从而失去了简单性的优势。 实际上，供应商的任务正在解决：发布一个标准解决方案，该标准解决方案可以由在街上被困的任何学生定制，并具有适当的质量水平（即从摊位到大型工厂的承保范围）。 如果您是摊位，请带一个学生，如果您是工厂，请从一个实施伙伴那里带一个专家。 实施合作伙伴以老师的价格出售学生的事实不是框架问题。 在架构上，框架应该解决这两个问题，学生应该理解典型配置的代码（我们将其出售给企业，并提供定制服务），并且上师将理解您想要的。
在我看来，该语言确实缺乏什么，这迫使我写很多东西，然后烧毁了客户支付的时间。
- 可以在例如TypeScript级别上进行键入（结果是，IDE中代码分析的方法更加完善，重构，攻击性降低了）
作为第一类对象的功能的存在。 一个稍微复杂的概念，但是可以大大减少标准代码中样板代码的数量。 恕我直言，学生的理解代码甚至会由于数量的减少而增加 - 通用集合，初始值设定项的文字。 同一件事-减少需要编写和/或通过眼睛查看的代码量。 填充集合超过1C编程时间的9000％。 不使用语法糖编写代码就很长，昂贵且容易出错。 通常，与可用的开放框架以及所有企业Java的总和相比，1C解决方案中的LOC数量超出了所有可能的限制。 该语言非常冗长，并且会退化为数据量，内存，IDE制动，时间，金钱...。
- 最终的结构我有一个假设，即由于没有成功将其翻译成俄语而导致这种结构缺失：)
- 自己的数据类型（无OOP），来自VB6的类型类似物。 允许您不使用BSP中的注释和构造这些结构的魔术方法来代表结构。 我们得到：更少的代码，明确的提示，更快的问题解决方案，更少的错字错误和缺少的结构属性。 现在，用户结构的类型完全属于标准子系统库的开发团队，据我所知，该团队仔细地编写了关于所传递参数结构的预期属性的注释。
- 在Web客户端上使用异步调用时缺少糖。 警报处理形式的回调地狱是由于主要浏览器的API突然更改而引起的临时拐杖，但是您不可能一直这样生活，异步代码“由学生理解”的优势正越来越少。 在此处的主IDE中添加对此范式的任何支持，情况将会变得更糟。
这是一个紧迫的问题，很明显列表可能会更大，但是请不要忘记它仍然不是通用语言，不需要多线程，lambda函数，访问GPU和快速浮点计算。 这是一种业务逻辑脚本语言。
一位使用这种语言做了很多工作的程序员对js或c＃感到厌倦。 这是事实。 他需要发展。 另一方面，供应商要承担销售这些功能的成本，而不是实施这些功能后收入的增加。 在这里，我没有任何关于公司眼下的重要信息。
开发环境
这里的一切也不顺利。 有两个开发环境。 第一个是交付中包含的配置器。 第二个是企业开发工具环境，它是在Eclipse的基础上开发的，缩写为EDT。
配置器提供了全方位的开发任务，支持所有功能，并且是市场上的主要环境。 根据谣言，由于自身内部的技术债务众多，道德上过时的也不会发展。 内部API的开放可以改善这种情况（以与Snegopat A. Orefkov的友谊形式或在独立的基础上），但事实并非如此。 实践表明，如果只有供应商不干涉，社区将在IDE中提交其功能。 但是我们拥有我们所拥有的。 配置器在2004-2005年很漂亮，它与当时的Visual Studio非常相似，在某些地方甚至更凉爽，但在那个时候却卡住了。
此外，自那时以来，平均标准解决方案的数量已经增长了数倍，如今，IDE愚蠢地无法应对它所提供的代码量。 可用性和重构功能甚至不为零，而是红色。 所有这些并没有增加开发人员的热情，他们梦想将其倾倒在其他生态系统中并继续在该生态系统中乱糟糟，但要在一个不会吐露其行为的宜人环境中。
作为替代方案，提出了从头开始编写的基于Eclipse的IDE。 像其他任何软件一样，在那里，源文件以文本文件的形式存在，并存储在GIT，请求请求分支，所有这些文件中。 缺点-多年来，它一直没有脱离beta状态，尽管每个版本都变得越来越好。 我不会写有关EDT的缺点，今天它是一个缺点，明天是一个固定的功能。 这样的描述的相关性将很快消失。 今天，可以在EDT中进行开发，但是不寻常的是，您需要为应对许多IDE错误做好准备。
如果通过提到的“ 1C棱镜”观察情况，您将得到类似的结果：新IDE的发布不会增加盒子的销售，但是可以减少DEVELOPERS的外流。 从开发人员的舒适度来看，很难说待生态系统等待什么，但是Microsoft已经通过向移动开发者提供服务为时已晚来描述移动开发人员。
发展管理
, , , , , 1 git, blame, code-review, , etc. , . , , , . -, KDiff- . gitconverter , , , gitsync , -. open-source 1 . API , , IDE.
, 1 git Jira, Crucible, Allure 1 SonarQube — , , , 1.
行政管理
. -, , - ( 1). , , , , — highload — , " ". , , 1 - . , , . .
, . , 1: , , . , , ELK , , — . . , 1 — . , . , , , 1- , , . SAP. , , , - . . SAP . - 1 , . 这是一个谬论。
1
— . , , . . — , . 1 , — . , , 1 — , .. . , , , , .
, 1 , , .
码头工人
1 . , , highload — . , +1 . , , .
— 1 - . 1 Reporting, , -, , , , .. , , . , UI , , .
1, , , , .
, PDF . .NET , . , . , PDF. , . - , , dto- JSON, , , , — PDF. 1, , .
- / 3. , , , , - . , , 3 , .
.NET visual studio ? ? - .
1 - . , . , 1. . , , . -, , — . :
- Unicode. , , ? 2019 ASCII ( legacy). . . - - varchar . 2015 gitlab LDAP- - , JetBrains IDE . 1 . . , , . , - . Java- . . ? .
- /. 1 . — . identity ( ", "), , , ( ). , , , — , , , .
- . 1 — . . - identity ( !), GUI, ( ). ? ?
- . 1 () . — ! , : ( ), . , . , — , .
- . , - . . — . : , .
- . , . , -, , , — . ( UI) — .
- Reporting. BI- ETL-. , . , , .. 1 , , . , . -- , --. : reporting, , , .
- . - .NET PDF . . PDF? 1- PDF +1 . + 40 , . 1 , . , , 1 , 3D OpenGL. ?
当限制功能或以折衷的方式实现是将来的重要架构优势时，所有这些仅是少数示例。 甚至是折衷或不是最有效的选择-它已经出现在包装盒中，被认为是理所当然的。 它的独立实现将是不可能的（因为这样的决定需要在项目的开始而不是在项目开始时做出，并且通常没有架构师），或者是一些昂贵的迭代。 在以上每个项目中（这不是体系结构解决方案的完整列表），您都可以nakosyachit并设置阻止扩展的限制。 无论如何，作为商人，您需要确保您的程序员（从头开始制作“系统”）拥有直截了当的手臂，并且可以立即执行良好的系统操作。
是的，就像在任何其他复杂系统中一样，1C本身具有以某种方式阻止缩放的解决方案。 但是，我会重复考虑各种因素，拥有成本，已经提前解决的问题数量-我认为市场上没有一个有价值的竞争对手。 以相同的价格，您可以获得财务应用程序框架，具有UI和Web枪口的集群平衡服务器，带有应用程序的移动应用程序，报表，集成等等。 在Java世界中，您需要雇用一个前端，后端团队，调试自写服务器代码的低级代码，并分别为2个移动OS的2个移动应用程序付费。
我并不是说1C可以解决所有情况，但是对于内部公司应用程序，当您不需要品牌UI时，还需要什么？
美中不足
可能1C可以拯救世界，而其他所有编写公司系统的方式都是错误的。 这根本不是真的。 从商人的角度来看，如果您选择1C，那么除了要加快产品上市时间外，还必须考虑以下缺点：
- 服务器可靠性 它需要真正高素质的专家，有能力确保其平稳运行。 我不知道来自供应商的针对此类专家的完整培训计划。 有准备通过“专家”考试的课程，但是，我认为这还不够。
- 支持。 请参阅上一段。 要获得供应商的支持，您需要购买它。 由于某些原因，这在1C行业中是不被接受的。 而使用SAP，几乎有必要购买，而且不会打扰任何人。 没有公司的支持，也没有该州的专家-有了1C故障，您可以一对一地保持联系。
- 不过，在1C上您什么也做不了。 这是一个工具，与每个工具一样，它也具有适用性限制。 在具有1C的环境中，非常需要有一个“非1C螺母”系统架构师。
- 良好的1C昵称并不比其他语言的优秀程序员便宜。 尽管，不管他们使用哪种语言，糟糕的程序员聘用起来都很昂贵。
让我们点
- 1C是用于业务的快速应用程序开发（RAD）的框架，并且是为此而定制的。
- 三链接，支持主DBMS，客户端UI，相当好的ORM和报告
- 与可以执行1C无法完成的系统的集成的充足机会。 如果您想进行机器学习，请获取Python，然后通过http或RabbitMQ将结果合并到1C
- 不要努力在1C中做所有事情，您需要了解其优势并将其用于自己的目的
- 倾向于挖掘技术框架小工具并每隔N年重做一次新引擎的开发人员对1C感到无聊。 那里的一切都很保守。
- 由于制造商对他们的关注很少，因此开发人员感到无聊。 语言无聊，IDE较弱。 他们需要现代化。
- 另一方面，无法通过应用和研究他们喜欢的其他技术找到娱乐的开发人员是糟糕的开发人员。 他们会发牢骚并进入另一个生态系统。
- 不允许其1C昵称在Python中作呕的雇主是坏雇主。 他们将以询问的心态丢掉员工，而猴子编码器将取代他们的位置，他们同意一切，将公司软件拖入沼泽。 您仍然必须重写它，所以也许早一点投资Python是更好的选择？
- 1C是一家商业公司，仅根据自己的兴趣和权宜性来实现功能。 她不能为此受到指责，企业必须考虑利润，这就是生活
- 1C通过销售解决业务问题而不是Vasya的开发人员问题的解决方案来获利。 这两个概念是相关的，但是优先级恰好是我所说的。 当开发商Vasya准备为1C：Resharper的个人许可证付款时，他将很快出现，“ Resharper” A。Orefkova对此进行了确认。 如果供应商支持他，但不与他抗争，那么您会发现开发人员将会有一个软件市场。 现在，在这个市场上有一个半决赛者，结果令人怀疑，所有这些都是因为与IDE的集成是负面的，并且一切都是在拐杖上完成的。
- 多工具专家的做法将被遗忘。 现代应用程序太庞大了，以至于无法从代码方面和业务使用方面记住它们。 服务器1C也变得越来越复杂，不可能在一个员工中保留所有类型的专业知识。 这将需要专业人才，这意味着1C尼克行业的吸引力以及薪资的增加。 如果在Vasya之前以薪水三合一的方式工作，现在您需要雇用两名Vasya，而Vasya之间的竞争可以刺激他们水平的总体增长。
结论
1C是非常值得的产品。 在我的价格范围内，我一点都不了解类似物，如果有类似物，请在评论中写下。 但是，开发人员从生态系统中流出的现象变得越来越明显，无论如何这都是“人才流失”。 该行业渴望现代化。
如果您是开发人员，请不要以1C循环学习，也不要以为其他语言的一切都是魔术。 当你在六月-也许。 一旦您需要解决更大的问题，就必须寻找现成的解决方案，以期更长，并更深入地完成。 根据“多维数据集”的质量水平，您可以从中构建解决方案-1C非常非常好。
但是-如果您来雇用1C昵称，那么可以将1C昵称放心地放在首席分析师身上。 他们对任务，主题领域和分解技能的理解非常完善。 我确信这完全是由于在1C开发中强制使用DDD。 首先训练一个人思考任务的含义，主题领域的对象之间的联系，并且具有集成技术和数据交换格式的技术背景。
请注意，理想的框架不存在，请多多关照。
对所有人都好！
PS：非常感谢您为本文提供帮助。