1C——善与恶。 1C 左右霍利瓦尔点的排列

朋友们、同事们，最近关于 Habré 仇恨 1C 作为开发平台的文章及其维护者的言论越来越多。这些文章指出了一个严重的问题：大多数情况下，1C的批评者是从“不掌握它”的立场来批评它的，责骂事实上很容易解决的问题，相反，没有触及真正重要、值得的问题。与供应商协商并没有解决。我认为对1C平台进行冷静、平衡的审查是有意义的。它能做什么，不能做什么，它应该做什么但不做什么，还有，作为甜点，它会做什么，而你的 %technology_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：Enterprise”。我们不会过多谈论制造商及其政策（但我们必须做一点）我们不会讨论使用此框架编写的具体应用程序。技术是独立的，应用程序（即配置）也是独立的。

高层架构1C：企业

我提到“框架”这个词并不是无缘无故的。从开发者的角度来看，1C平台恰恰是一个框架。你需要像对待框架一样对待它。将其视为由某个运行时（分别为 JVM 或 CLR）执行的 Spring 或 ASP.NET。碰巧的是，在传统编程（“不是 1C”）的世界中，框架、虚拟机和特定应用程序的划分是很自然的，因为这些组件通常是由不同的制造商开发的。在1C世界中，并没有明确区分开发框架和运行时本身的习惯；此外，使用框架编写的具体应用程序也主要由1C本身开发。结果，出现了一些混乱。因此，在本文的框架内，我们必须同时从多个方面考虑1C，并沿着多个坐标轴对其进行分类。在每个坐标轴上我们都会放一把棕色物质铲子，看看现有解决方案的特点、优点和缺点。

对1C的观点

买家1C

买家购买一套自动化系统，可以快速解决自己业务的自动化问题。企业可以是一个小摊位，也可以是一个大型控股公司。显然，这些业务的需求是不同的，但两者都由单一平台代码库支持。

对于 1C 买家来说，这是一个快速的上市时间。快速地。比 Java、C# 或 JS 更快。平均的。医院周边。显然，使用 React 的名片网站效果会更好，但 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，”开发人员说。 “在平台上支持 OOP 需要花费多少钱，这会帮助我们增加盒子的销量吗？”1C 说。打开他销售业务问题解决方案的“棱镜”：

- 嘿，生意人，你想在你的 1C 中使用 OOP 吗？
- 这能帮助我解决我的问题吗？
- 谁知道...
——那就没必要了

这种方法可能好也可能坏，具体取决于谁在看它，但事实就是如此。谈到 1C 中没有功能 X 的事实，您需要明白它的存在不是有原因的，而是在“实施成本与利润金额”选择的背景下。

技术分类

“事实上，Odinesniks 尽最大努力使用由 1C 平台的方法学家和开发人员精心挑选的最佳模式。
当您为简单的托管表单编写愚蠢的代码时，实际上您正在使用 模型-视图-控制器 с 双向数据绑定 в 三层数据应用引擎, 调味 高级对象关系映射 根据 声明性元数据描述有自己的 独立于平台的查询语言，C 声明性数据驱动的用户界面、完全透明的序列化和面向领域的程序语言.

1C 开发人员与西方同事的不同之处在于公关。他们喜欢给任何废话冠以大名，然后像一个脏袋子一样带着它到处跑。”
A·奥列夫科夫

1C 平台具有经典的三层架构，其中心是应用服务器（或者对于小店主来说花费很少的钱进行仿真）。使用 MS SQL 或 Postgres 作为 DBMS。还支持 Oracle 和 IBM DB3，但这相当深奥；没有人知道如果在中高负载下在这些数据库上实施 2C 会发生什么。我相信1C自己也不知道这一点。

客户端部分可以是安装在用户计算机上的瘦客户端，也可以是 Web 客户端。关键特征是程序员不会编写两种不同的代码，他们用一种语言编写一个应用程序，如果有愿望或需要，您可以将其显示在浏览器中。谁想要一个真正的完整堆栈以及前端和后端的单一语言，node.js？直到最后他们都没有做到完全相同的事情。真正的完整堆栈是存在的，但你必须用 2C 来编写它。命运的讽刺，就是这样:)

云 SaaS 解决方案 1C:Fresh 也可以在浏览器模式下运行，在浏览器模式下，您不能购买 1C，但可以租用一个小型数据库并跟踪那里的沙瓦玛销售情况。只需在浏览器中，无需安装或配置任何内容。

此外，还有一个遗留客户端，在 1C 中称为“常规应用程序”。遗产就是遗产，欢迎来到 2002 年的应用程序世界，但我们仍在谈论生态系统的当前状态。

1C服务器部分支持集群并通过向集群添加新机器来扩展。这里有相当多的副本已经被破坏，文章中将有一个单独的部分来讨论这一点。简而言之，这与在 HAProxy 后面添加几个完全相同的实例并不完全相同。

应用程序开发框架使用自己的编程语言，大致类似于翻译成俄语的稍微改进的VB6。对于那些讨厌俄语的人，不相信“if”被翻译为“if”的人，提供了第二种语法选项。那些。如果您愿意，您可以用 1C 编写它，使其与 VB 没有区别。

这种编程语言是 1C 昵称对其平台憎恨的主要原因。让我们面对现实吧，这并非没有道理。该语言的构思尽可能简单，旨在至少在独联体国家中实现“开发者，开发者”的口号。在我看来，这种解决方案的商业本质是显而易见的：更多的开发者，更大的市场覆盖范围。根据从 45% 到 95% 的各种估计，这一点成为了现实。我马上就会说，用你认为的语言写作确实更容易。而且我了解相当多的编程语言。

让我们从语言开始吧。

1C编程语言

同时系统的优点和缺点。提供轻松的输入和可读性。另一方面，它自8年发布版本2002以来就没有更新过，在道德上已经过时了。有人会说“主要缺点是没有 OOP”，他们错了。首先，巴解组织不仅不喜欢努拉利耶夫，也不喜欢托瓦尔兹​​。其次，OOP 仍然存在。

从开发人员的角度来看，他拥有一个框架，其中基类显示在 DBMS 上。开发人员可以采用基类“Directory”并从中继承“Clients”目录。它可以向其中添加新的类字段，例如 INN 和 Address，并且如果需要，它还可以重写（覆盖）基类的方法，例如 OnWrite/AtRecord 方法。

该框架的设计方式很少需要更深层次的继承，在我看来，OOP 中的限制是有道理的。 1C 专注于领域驱动开发，让您首先思考正在开发的解决方案的主题领域，这很好。不仅没有诱惑，而且也不需要仅仅为了在某处显示来自域的一些数据而编写 10 个不同的 DTO 和 ViewModel。 1C 开发人员始终使用一个实体进行操作，而不会用十几个具有相似名称的类（代表同一实体，但来自不同的方面）来混淆感知上下文。例如，任何 .NET 应用程序都必须包含五个或两个 ViewModel 和 DTO，用于序列化为 JSON 以及从客户端到服务器的数据传输。大约 10-15% 的应用程序代码将用于使用 AutoMapper 等笔或拐杖将数据从一个类传输到另一个类。必须编写此代码，并且必须付费给程序员来创建和维护它。

事实证明，1C语言如果不复杂到主流语言的水平就很难开发，从而失去了简单性的优势。供应商的任务本质上要解决什么：发布一个标准解决方案，任何在街上遇到的学生都可以根据所需的质量水平进行定制（即完成从摊位到大型工厂的案例）。如果你是摊子，就带一个学生；如果你是工厂，就带一个执行伙伴的大师。事实上，实施伙伴以大师的价格出售学生并不是该框架的问题。从架构上来说，框架必须解决这两个问题，标准配置的代码（我们卖给企业并承诺定制）应该能够被学生理解，而大师应该能够理解你想要的任何东西。

在我看来，这种语言真正缺失的是什么，迫使你写得超出你能力范围的东西，就是浪费了客户付出的时间。

• 在级别上打字的可能性，例如 TypeScript（因此，IDE 中的代码分析工具更加发达，重构，更少的攻击性门框）
  函数作为第一类对象的可用性。概念稍微复杂一些，但典型样板代码的数量可以大大减少。恕我直言，由于数量的减少，学生对代码的理解甚至会增加
• 通用集合文字、初始值设定项。同样的事情 - 减少需要编写和/或用眼睛查看的代码量。填充集合占用了 9000C 编程时间的 1% 以上。在没有语法糖的情况下编写此代码是很长、昂贵且容易出错的。一般来说，与可用的开放框架以及所有企业 Java 的总和相比，1C 解决方案中的 LOC 数量超出了所有可以想象的限制。该语言很冗长，这会退化为数据量、内存、IDE 制动器、时间、金钱......
• 最后的结构我有一个假设，由于他们没有找到将其成功翻译成俄语的事实，因此该结构丢失了:)
• 自己的数据类型（无 OOP），类似于 VB6 中的 Type。它将允许您不使用 BSP 中的注释和构造这些结构的魔术方法来键入结构。我们得到：更少的代码、通过点的提示、更快的问题解决方案、更少的由于拼写错误和缺少结构属性而导致的错误。现在，用户结构的类型完全取决于标准子系统库的开发团队，值得赞扬的是，该团队仔细地对传递的参数结构的预期属性编写了注释。
• 在 Web 客户端上处理异步调用时没有任何糖分。以ProcessingNotifications形式出现的callback-hell是主要浏览器API的突然变化所导致的临时拐杖，但你不能一直这样生活；异步代码的“学生理解”优势正在丧失；越来越多。如果主 IDE 不支持这种范例，情况会变得更糟。

这是紧迫的问题之一，显然这个列表可能会更大，但我们不能忘记这仍然不是一种通用语言，它不需要多线程、lambda 函数、访问 GPU 和快速浮点计算。这是一种业务逻辑脚本语言。

一个已经经常使用这种语言工作的程序员，研究 js 或 c#，会对这种语言的框架感到厌倦。这是事实。他需要发展。对于供应商来说，天平的另一面是实施指定功能的成本与实施后收入的增加。在这里我没有任何关于公司目前认为什么是重要的信息。

开发环境

这里的事情进展也不顺利。有两种开发环境。第一个是交付中包含的配置器。二是企业开发工具环境，简称EDT，是在Eclipse基础上开发的。

该配置器提供全方位的开发任务，支持所有功能，是市场上的主要环境。据传言，由于其本身存在大量技术债务，它在道德上也已经过时，没有发展。这种情况可以通过开放内部API（以与 雪人 A. Orefkova 或独立的基础上），但事实并非如此。实践表明，社区会在IDE中编写自己的功能，只要供应商不干涉。但我们有我们所拥有的。配置器在 2004-2005 年很棒，很让人想起那个时代的 Visual Studio，在某些地方甚至更酷，但它停留在那个时代。

此外，从那时起，平均标准解决方案的体积已经增长了数倍，而今天的 IDE 根本无法应对所输入的代码量。可用性和重构能力甚至不是零，它们处于亏损状态。所有这些并没有增加开发人员的热情，他们梦想转移到其他生态系统并继续在那里编写代码，但在一个愉快的环境中，其行为不会向你吐口水。

作为替代方案，我们提供了一个基于 Eclipse 构建的从头开始编写的 IDE。与任何其他软件一样，源代码以文本文件的形式存在，存储在 GIT、拉取请求分支等中。不利的一面是，它多年来一直没有离开测试版状态，尽管每次发布都变得越来越好。我不会写 EDT 的缺点，今天它是一个减号，明天它是一个固定功能。这种描述的相关性很快就会消失。如今，可以在 EDT 中进行开发，但这并不常见；您需要为一定数量的 IDE 错误做好准备。

如果通过前面提到的“1C棱镜”来看情况，你会得到这样的结论：新IDE的发布并不会增加盒子的销量，但开发者的流出可能会减少。很难说生态系统在开发者舒适度方面会发生什么，但微软已经因为太晚向移动开发者提供服务而搞砸了。

开发管理

这里的一切都比编写代码要好得多，尤其是最近，当社区的努力揭示了管理自动化的问题时，推出了原型，要求将 1C 存储库扔进垃圾堆并使用 git、快速指责、代码审查、静态分析、自动部署等。该平台添加了许多功能，提高了开发任务的自动化水平。然而，所有这些功能都是专门为我们自己的大型产品的开发而添加的，当时很明显我们离不开自动化。有自动合并、与 KDiff 的三向比较等等。在Github上发布 git转换器，坦率地说，他在意识形态上被拖离了该项目 gitsync，但进行了修改以适应供应商公司的流程。感谢开源领域顽固的人们，1C 的开发自动化取得了进展。恕我直言，配置器的开放 API 也将改变主要 IDE 的道德落后状态。

如今，将 1C 源代码存储在 git 中，并在 Jira 中存储与问题相关的提交、Crucible 中的评论、Jenkins 的按钮以及关于 1C 中代码测试的 Allure 报告，甚至 SonarQube 中的静态分析 - 这远不是新闻，而是大量进行 1C 开发的公司的主流。

管理

这里有很多话要说。首先，这当然是一台服务器（1C服务器集群）。这是一件美妙的事情，但由于它是一个完全黑匣子，并且以特定的方式记录了足够的细节 - 掌握在多台服务器上以高负载模式启动不间断操作是少数穿着奖章上刻有“技术问题专家”字样。值得注意的是，原则上，管理 1C 服务器与管理任何其他服务器没有什么不同。它是一个基于网络的多线程应用程序，消耗内存、CPU 和磁盘资源。为遥测收集和诊断提供充足的机会。

这里的问题是供应商没有为这个诊断提供任何特殊的现成解决方案。是的，有1C：仪表和控制中心，它们甚至相当不错，但它们非常昂贵，并不是每个人都有。社区中有许多用于连接 Grafana、Zabbix、ELK 和标准管理集中的其他事物的开发，但没有一个解决方案适合大多数人。任务等待着它的英雄。如果您是一家计划在 1C 集群上启动的企业，那么您需要一名专家。你自己的内部或外部，但你需要它。有一个单独的角色具有服务器操作的权限是很正常的，并不是每个 1C 用户都应该知道这一点，您只需要了解需要这样的角色即可。我们以 SAP 为例。在那里，如果要求程序员在应用程序服务器上配置某些内容，他很可能甚至不会从椅子上站起来。他可能只是愚蠢，他不会感到羞耻。在 SAP 方法中，为此有一个单独的员工角色。由于某种原因，在 1C 行业中，人们认为这应该以相同的工资合并在一名员工身上。这是一个错觉。

1C服务器的缺点

只有一个缺点——可靠性。或者，如果你愿意的话，也可以说是不可预测性。服务器突然出现的奇怪行为已经成为人们谈论的话题。专家手册中甚至描述了一种通用的补救措施 - 停止服务器并清除所有缓存 - 甚至建议使用批处理手册来执行此操作。如果您的 1C 系统开始执行理论上不应该执行的操作，则需要清除会话数据缓存。据我估计，全国只有三个人知道如何在没有这个程序的情况下操作1C服务器，并且他们不分享秘密，因为......他们以此为生。也许他们的秘密是他们清理会话数据，但他们不会告诉任何人，伙计。

除此之外，1C 服务器与任何其他应用程序都是相同的应用程序，并且通过阅读文档和敲击手鼓以大致相同的方式进行管理。

码头工人

在生产中使用容器化 1C 服务器的实用性尚未得到证实。服务器不是通过简单地在均衡器后面添加节点来集群的，这将生产容器化的好处降到了最低，并且在高负载模式下在容器中成功运行的实践尚未建立。因此，只有开发人员使用Docker+1C来搭建测试环境。它非常有用、实用，可以让您使用现代技术并从配置器的沮丧中休息一下。

商业组件

从投资的角度来看，1C 可以帮助您解决由于应用程序类的广泛功能而快速启动业务想法的问题。开箱即用的 1C 提供了非常不错的报告、与任何内容的集成、Web 客户端、移动客户端、移动应用程序、对各种 DBMS 的支持，包括。免费、跨平台的服务器和已安装的客户端部分。是的，应用程序的 UI 会是黄色的，有时这是一个缺点，但并非总是如此。
通过选择 1C，企业可以获得一套软件解决方案，使他们能够构建非常广泛的应用程序，并且市场上有很多开发人员想要比 Javaists 更少的钱，同时更快地产生结果。

例如，向客户发送 PDF 发票的任务可以在学生工作一个小时内解决。 .NET 中的相同问题可以通过购买专有库或由严肃的大胡子开发人员进行几天或几周的编码来解决。有时，两者同时发生。是的，我只是谈论 PDF 生成。我们还没有说这笔帐单将来自哪里。 Web 前端必须创建一个表单，操作员将在其中输入数据，后端必须创建用于传输 JSON 的 dto 模型、用于存储在数据库中的模型、数据库本身的结构、迁移到数据库、形成图形显示这个帐户，然后才显示 - PDF。在 1C 上，整个任务从头开始，恰好在一小时内完成。

一个完整的会计系统，适用于一个小摊位，只需 3 小时即可完成购买/销售的业务流程，包括销售报告、按购买和销售价格进行的货物会计、按仓库细分、访问权限控制、网络客户端和移动应用程序。 。好吧，我忘了申请了，申请不是三小时后，而是六小时后。

.NET 开发人员从在干净的计算机上安装 Visual Studio 到向客户演示该任务需要多长时间？开发成本又如何呢？一样。

1C 作为平台的优势

1C之所以强大，并不是因为它有什么特定的东西是世界上最好的。相反，在每个单独的子系统中，您都可以在世界软件中找到更有趣的类似物。然而，综合多种因素，我并没有看到类似1C的平台。这就是商业成功之所在。该平台的优点分散在整个平台中，当您看到其他平台是如何实现这一点时，这些优点最为明显。基本上，这些甚至都不是特征，而是相反——为了支持一种特定范例而拒绝特征。举几个例子：

1. 统一码。到底还有什么可以更简单呢？ 2019 年没有必要使用单字节 ASCII 编码（除了与古老遗留编码的集成）。绝不。但不是。无论如何，某些表中的某人使用单字节 varchar 并且应用程序将出现编码问题。 2015 年，由于编码工作不正确，gitlab 的 LDAP 授权失败；JetBrains IDE 仍然无法在所有文件名中使用西里尔字母。 1C 提供应用程序代码与数据库层的高质量隔离。在那里不可能在低级别上键入表格，并且在那里也不可能出现数据库级别无能的初级人员。是的，无能的后辈可能还会出现其他问题，但问题的种类要少得多。现在您将告诉我您的应用程序设计正确，并且数据库访问层已按照应有的方式隔离。再看看您的企业自定义 Java 应用程序。密切而诚实。你的良心困扰你吗？那我为你感到高兴。
2. 文件/参考书的编号。在1C中它绝对不是最灵活的也不是最好的。但他们在银行软件和自行编写的会计系统中所做的事情——嗯，这只是黑暗。要么身份被卡住（然后“哦，为什么我们有漏洞”），要么相反，他们将制作一个与 DBMS 级别的锁定一起工作的生成器（并将成为瓶颈）。事实上，完成这个看似简单的任务是相当困难的——一个端到端的实体枚举器，具有基于一组特定键的唯一性部分、前缀，以便在并行数据输入期间不会阻塞数据库。
3. 数据库中记录的标识符。 1C 做出了一个意志坚定的决定——所有链接标识符都是绝对合成的，仅此而已。而且分布式数据库和交易所也不存在问题。其他系统的开发人员固执地创建类似身份的东西（它更短！），将它们拖到 GUI 中，直到需要创建几个相关实例（然后它们就会被发现）。你没有这个吗？诚实地？
4. 列表。 1C 具有相当成功的机制来对（大）列表进行分页和导航。让我立即预订 - 并正确使用该机制！总的来说，这个话题相当令人不愉快，无法理想地解决：它要么直观且简单（但客户端存在巨大记录集的风险），要么分页有这样或那样的弯曲。那些做传呼的人常常做得歪歪扭扭。那些制作诚实滚动条的人添加了数据库、通道和客户端。
5. 托管表格。毫无疑问，在网络客户端中，界面不能完美运行。但它有效。但对于许多其他会计和银行系统来说，创建远程工作场所是一个企业级项目。免责声明：幸运的是，对于那些最初在网络上制作的人来说，这不会产生影响。
6. 移动应用。最近，您还可以在同一生态系统中编写移动应用程序。这里比网络客户端稍微复杂一些；设备的具体情况迫使您专门为它们编写，但是，您不需要雇用单独的移动开发人员团队。如果您需要一个应用程序来满足公司的内部需求（当公司问题的移动解决方案比黄色 UI 设计更重要时），您只需使用开箱即用的相同平台即可。
7. 报告。我所说的这个词并不是指具有大数据和 ETL 流程滞后的 BI 系统。这是指运营人员报告，可让您评估此时此地的会计状况。余额、相互结算、重新评级等1C 带有一个开箱即用的报告系统，可以在用户端进行灵活的分组、过滤器和可视化设置。是的，市场上有更酷的类似物。但不在一体化解决方案的框架内，而且价格有时比一体化解决方案更高。更常见的是，情况甚至相反：仅报告，但比整个平台更昂贵，而且质量更差。
8. 可打印的表格。那么，使用.NET来解决通过电子邮件向员工发送PDF格式的工资单的问题。现在是打印发票的任务。将它们的副本保存到同一个 PDF 中怎么样？对于 1C 昵称来说，将任何布局输出到 PDF 都是 +1 行代码。这意味着 + 40 秒的工作时间，而不是使用其他语言的几天或几周。 1C 中的打印表单布局非常容易开发，并且功能强大，足以与付费同行竞争。是的，1C 电子表格文档中可能没有太多交互机会；您无法使用 OpenGL 快速获得具有缩放功能的 3D 图表。但这真的有必要吗？

这些只是少数几个示例，其中限制功能或实施妥协被证明是未来的重要架构优势。即使是妥协或不是最有效的选择 - 它已经在盒子里并且被认为是理所当然的。它的独立实现要么是不可能的（因为这样的决定必须在项目开始时做出，而没有时间这样做，也根本没有架构师），要么需要多次昂贵的迭代。在列出的每个点（这不是架构解决方案的完整列表）中，您都可能搞砸并引入阻碍扩展的限制。无论如何，作为一名商人，您需要确保您的程序员在“从头开始构建系统”时能够直接处理微妙的系统问题。

是的，与任何其他复杂系统一样，1C 本身也有在某些方面阻碍扩展的解决方案。然而，我再说一遍，基于综合因素、拥有成本以及已经提前解决的问题数量，我在市场上看不到值得竞争的竞争对手。以相同的价格，您可以获得一个财务应用程序框架、一个集群平衡服务器、一个 UI 和 Web 界面、一个移动应用程序、报告、集成和许多其他功能。在 Java 世界中，您需要聘请前端和后端团队，调试大量自制服务器代码，并分别为 2 个移动操作系统的 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 的个人许可证时，它会很快出现，A. Orefkova 的“Resharper”就是证明。如果供应商支持它，而不是反对它，那么就会出现一个面向开发人员的软件市场。现在这个市场上有一个半玩家的结果值得怀疑，而这一切都是因为与 IDE 的集成是负面的，而且一切都是拄着拐杖完成的。
• 多机操作员的做法将被遗忘。现代应用程序太大，无论从代码方面还是从业务使用方面都难以记住。 1C 服务器也变得更加复杂；一名员工不可能掌握所有类型的专业知识。这应该会带来对专家的需求，这意味着1C职业的吸引力和薪资的增加。如果说以前瓦斯亚是三合一，工资一份，那么现在你需要雇佣两个瓦斯亚，瓦斯亚之间的竞争可以促进他们水平的整体提升。

结论

1C是一款非常值得的产品。在我的价格范围内，我根本不知道任何类似的东西，如果有的话请在评论中写下。然而，开发者从生态系统中流出的现象越来越明显，无论怎么看，这都是一种“人才流失”。该行业渴望现代化。
如果你是一名开发人员，不要沉迷于 1C，也不要认为其他语言的一切都很神奇。当你还是个大三学生的时候，也许吧。一旦需要解决更大的问题，就必须更长时间地寻找现成的解决方案并更集中地完成。就构建解决方案的“块”的质量而言，1C 非常非常好。

还有一件事 - 如果您来雇用 1C 昵称，那么 1C 昵称可以安全地被任命为首席分析师的职位。他们对任务、主题领域和分解技能的理解非常出色。我确信这正是由于1C开发中强制使用DDD造成的。一个人被训练首先思考任务的意义，思考主题领域的对象之间的联系，同时具有集成技术和数据交换格式的技术背景。

请注意，理想的框架并不存在，请照顾好自己。
一切都好！

PS：非常感谢 斯佩苏里克 寻求文章准备方面的帮助。

只有注册用户才能参与调查。 登录拜托

您的企业有1C吗？

• 13,3%一点也不。71

• 30,3%有，但仅限于会计部门的某个地方。其他平台上的核心系统162

• 41,4%是的，主要业务流程均在其上运行221

• 15,0%1C必须死，未来属于%technology_name%80

534 位用户投票。 99 名用户弃权。

来源： habr.com