1C - 善と悪。 1C 付近のホリバール内の点の配置

友人や同僚の皆さん、最近、開発プラットフォームとしての 1C に対する憎悪を込めたハブレに関する記事や、その擁護者によるスピーチが頻繁に掲載されています。 これらの記事は、1 つの深刻な問題を特定しました。ほとんどの場合、1C の批判者は「それを習得していない」という立場からそれを批判し、事実上簡単に解決できる問題を叱責し、逆に、本当に重要で価値のある問題には触れていません。議論しており、ベンダーによって解決されていません。 私は、XNUMXC プラットフォームについて冷静かつバランスの取れたレビューを行うことが理にかなっていると信じています。 できること、できないこと、やるべきなのにやらないこと、そしておまけに、すごいことをやってくれること、そして %technology_name% の開発者はそれを捨てて XNUMX 年もやり続けるだろう複数の年間予算。

その結果、管理者または建築家は、1C を使用することがどのようなタスクに有益であるか、また、どこを熱いアイロンで焼き切る必要があるかを明確に理解できるようになります。 「非 1C」の世界の開発者として、1C で何が問題を引き起こしているのかを知ることができるでしょう。 そして、1C 開発者として、自分のシステムを他の言語のエコシステムと比較し、ソフトウェア開発の座標系における自分の位置を理解できるようになります。

カットの下には、1C、1C の批判者、Java、.NET、そして一般的に、多くの激しい攻撃が含まれています...ファンはいっぱいです、ようこそ!

私について

私はこの話題については 2004 年頃からよく知っていました。 私はおそらく 6 歳の頃からプログラミングを続けてきました。猫、雀、毛虫の漫画が載った Fortran 教授の本を手に入れたその瞬間からです。 本の絵から猫が書いたプログラムを解析して、何をするのかを調べました。 そうです、当時私は本物のコンピューターを持っていませんでしたが、本の見開きに絵があり、正直に紙のボタンを押して、猫 X にスパイしたコマンドを入力しました。

学校では BK0011 と BASIC、大学では C++ とアセンブラ、それから 1C と、覚えるのが面倒なくらい他にもたくさんありました。 過去 15 年間、私はコーディングだけでなく 1C 全般に主に 1C に携わってきました。 ここでタスク、管理、devops を設定します。 過去 5 年間、私は他の 1C ユーザーのための開発ツールや自動化ツールの開発、記事や書籍の執筆など、社会的に役立つ活動に従事してきました。

話し合いのテーマを決めましょう

「1C」という文字には多くの意味があるため、まず、これから話す内容を定義しましょう。 この場合、「1C」という文字は、最新の第 1 バージョンの開発フレームワーク「XNUMXC: Enterprise」のみを意味します。 メーカーとそのポリシーについてはあまり話しません (ただし、少しは話す必要があります) このフレームワークを使用して作成された特定のアプリケーションについては話しません。 テクノロジーは別のものであり、アプリケーション、つまり構成も別のものです。

高レベルのアーキテクチャ 1C: エンタープライズ

私が「フレームワーク」という言葉について言及したのは当然のことです。 開発者の観点から見ると、1C プラットフォームはまさにフレームワークです。 そして、それをフレームワークとまったく同じように扱う必要があります。 これは、何らかのランタイム (それぞれ JVM または CLR) によって実行される Spring または ASP.NET と考えてください。 従来のプログラミング (「1C ではない」) の世界では、フレームワーク、仮想マシン、および特定のアプリケーションに分割するのが自然です。これらのコンポーネントは通常、異なるメーカーによって開発されているためです。 1C の世界では、開発フレームワークとランタイム自体を明確に区別する習慣はなく、また、フレームワークを使用して記述された特定のアプリケーションも、主に 1C 自体によって開発されます。 その結果、多少の混乱が生じます。 したがって、記事の枠組みの中で、1C をいくつかの側面から一度に検討し、いくつかの座標軸に沿って分類する必要があります。 そして、各座標軸に茶色の物質のシャベルを置き、既存のソリューションの特徴、長所、短所を見ていきます。

1Cの視点

1C 購入者向け

購入者は、自分のビジネスの自動化に関する問題を迅速に解決できる自動化システムを購入します。 ビジネスは小さな屋台の場合もあれば、大規模な持株会社の場合もあります。 これらのビジネスのニーズが異なることは明らかですが、どちらも単一のプラットフォーム コード ベースでサポートされています。

1C の購入者にとって、これは市場投入までの時間が短縮されます。 速い。 Java、C#、または JS よりも高速です。 平均。 病院の周り。 React を使用した名刺 Web サイトの方が優れた結果になることは明らかですが、WMS システムのバックエンドは 1C でより速く起動されます。

ツールとしての1C

各技術ソリューションには適用範囲の制限があります。 1C は汎用言語ではなく、そのフレームワークから独立して存在するわけではありません。 次の場合には 1C を使用することをお勧めします。

• サーバーアプリケーション
• 財務が表示されるアプリケーション
• 既製の UI、ORM、レポート、XML/JSON/COM/PDF/YourDataTransferingFormat を使用
• バックグラウンドプロセスとジョブのサポート付き
• 役割ベースのセキュリティを使用する
• スクリプト可能なビジネスロジックを使用
• プロトタイプを迅速に作成でき、市場投入までの時間が短い

必要な場合は 1C は必要ありません。

• 機械学習
• GPU計算
• コンピューターグラフィックス
• 数学的計算
• CADシステム
• 信号処理（音声、映像）
• 数十万 RPS の高負荷 http 呼び出し

ものづくり企業としての1C

ソフトウェアメーカーとしての 1C のビジネスが何であるかを理解することは価値があります。 1C 社は、自動化を通じてビジネス上の問題に対するソリューションを販売しています。 規模の大小にかかわらず、さまざまなビジネスがありますが、それが彼女の売り物です。 この目標を達成するための手段がビジネス アプリケーションです。 会計、給与計算などのアプリケーションを作成するために、同社は独自のビジネス アプリケーション開発プラットフォームを使用しています。 これらの同じビジネス アプリケーションの一般的なタスク向けに特別に調整されています。

• 財務会計
• ビジネスロジックの簡単なカスタマイズ
• 異種混在の IT 環境における幅広い統合の可能性

メーカーとして 1C は、これがパートナーやクライアントと Win-Win モードで協力できる戦略であると信じています。 これには異論もあるかもしれませんが、大まかに言うと、これが同社の宣伝方法です。ビジネス上の問題に対する既製のソリューションであり、パートナーがすぐにカスタマイズでき、あらゆる IT 環境に統合できます。

枠組みとしての 1C に対するすべての主張や要望は、もっぱらこのプリズムを通して見るべきです。 「私たちは 1C で OOP を実現したいと考えています」と開発者は言います。 「プラットフォームで OOP をサポートするにはどれくらいの費用がかかりますか。これはボックスの売上増加に役立ちますか?」と 1C は言います。 ビジネス上の問題に対するソリューションを販売するという彼の「プリズム」を開きます。

- ビジネスの皆さん、1C に OOP を導入したいですか?
- これは私の問題の解決に役立ちますか?
- 知るか...
- それなら必要ない

このアプローチは見る人によって良くも悪くもなりますが、それが現状です。 1C に機能 X がないという事実について言えば、機能 X には理由があって存在するのではなく、「実装コストと利益の額」という選択の文脈で存在していることを理解する必要があります。

技術分類

「実際、Odinesniks は、思いやりのある方法論者と 1C プラットフォームの開発者によって慎重に選択された最良のパターンを使用するために最善を尽くしています。
単純なマネージ フォーム用の愚かなコードを記述するとき、実際には次のコードを使用しています。 モデル ビュー コントローラー с 双方向データバインディング в XNUMX 層データ アプリ エンジン、味付き 高レベルのオブジェクト関係マッピング に基づいて 宣言的なメタデータの説明独自のものを持っている プラットフォームに依存しないクエリ言語は、C 宣言型データ駆動型ユーザー インターフェイス、完全な透過的シリアル化、ドメイン指向のプログラム言語.

1C 開発者が西側の開発者と異なるのは PR です。 彼らはどんなくだらないものに大げさな名前を付けて、汚れた袋のようにそれを持ち歩き回るのが大好きです。」
A.オレフコフ

1C プラットフォームは古典的な 3 層アーキテクチャを備えており、その中心にアプリケーション サーバー (または小規模商店主向けの少額の費用でのそのエミュレーション) があります。 DBMS として MS SQL または Postgres が使用されます。 Oracle と IBM DB2 のサポートもありますが、これはかなり難解であり、中負荷および高負荷の下でこれらのデータベースに 1C を実装すると何が起こるかは誰にもわかりません。 このことは1C自身も分かっていないのではないかと思います。

クライアント部分は、ユーザーのマシンにインストールされたシン クライアントまたは Web クライアントのいずれかです。 主な特徴は、プログラマーが 2 つの異なるコードを作成するのではなく、1 つのアプリケーションを XNUMX つの言語で作成し、必要に応じてブラウザーに表示できることです。 真のフルスタックとフロントエンドとバックエンド用の単一言語、node.js を望んでいた人がいるでしょうか? 彼らは最後までまったく同じことをすることができませんでした。 実際のフルスタックは存在しますが、XNUMXC で記述する必要があります。 運命の皮肉、そんなこと :)

クラウド SaaS ソリューション 1C:Fresh はブラウザ モードでも動作します。このモードでは 1C を購入することはできませんが、小さなデータベースをレンタルして、そこで shawarma の売上を追跡します。 何もインストールしたり設定したりすることなく、ブラウザ上で行うだけです。

さらに、1C では「通常のアプリケーション」と呼ばれるレガシー クライアントがあります。 レガシーはレガシーです。2002 年のアプリケーションの世界へようこそ。しかし、私たちはまだエコシステムの現状について話しています。

1C サーバー部分はクラスタリングをサポートし、新しいマシンをクラスタに追加することで拡張します。 ここではかなり多くのコピーが壊れており、これについては記事の別のセクションで説明します。 つまり、これは、HAProxy の背後にまったく同じインスタンスを XNUMX つ追加することとまったく同じではありません。

アプリケーション開発フレームワークは独自のプログラミング言語を使用します。この言語は、ロシア語に翻訳されたわずかに改良された VB6 にほぼ似ています。 ロシア語のすべてが嫌いな人、「if」が「if」と翻訳されることを信じない人のために、1 番目の構文オプションが提供されます。 それらの。 必要に応じて、VB と区別できないように XNUMXC で記述することもできます。

まさにこのプログラミング言語こそが、1C のニックネームがプラットフォームに対して嫌悪感を抱く主な理由です。 正直に言って、理由がないわけではありません。 この言語は可能な限りシンプルに考えられ、少なくとも CIS の規模で「開発者、開発者」というマントラを満たすように設計されました。 私の意見では、そのようなソリューションの商業的本質は、より多くの開発者とより大きな市場範囲ということによって明確に見えます。 さまざまな推定によれば、これは 45% から 95% まで実現しました。 すぐに言っておきますが、あなたが考える言語で書くのが本当に簡単です。 そして、私はかなり多くのプログラミング言語を知っています。

まずは言語から始めましょう。

1Cプログラミング言語

同時に、システムの長所でもあり、短所でもあります。 簡単な入力と読みやすさを提供します。 一方で、8 年のバージョン 2002 のリリース以来更新されておらず、道徳的に時代遅れです。 「主な欠点は OOP がないことです」と言う人もいますが、それは間違いです。 第一に、PLOはヌラリエフだけでなくトーバルズ氏も好きではない。 そして第二に、OOP はまだ存在します。

開発者の観点から見ると、DBMS 上に表示される基本クラスを備えたフレームワークを自由に使えることになります。 開発者は基本クラス「Directory」を取得し、そこから「Clients」ディレクトリを継承できます。 INN や Address などの新しいクラス フィールドを追加できます。また、必要に応じて、基本クラスのメソッド (OnWrite/AtRecord メソッドなど) をオーバーライド (オーバーライド) することもできます。

このフレームワークは、より深い継承がほとんど必要ないように設計されており、私の意見では、OOP の制限は理にかなっています。 1C はドメイン駆動開発に焦点を当てており、まず開発中のソリューションの主題領域について考えさせます。これは良いことです。 誘惑がないだけでなく、ドメインのどこかからデータを表示するためだけに 10 個の異なる DTO と ViewModel を作成する必要もありません。 1C 開発者は、同じエンティティを別の側から表す、類似した名前を持つ多数のクラスで認識のコンテキストを混乱させることなく、常に 10 つのエンティティを操作します。 たとえば、.NET アプリケーションには、JSON へのシリアル化とクライアントからサーバーへのデータ転送のために、必ず 15 つまたは XNUMX つの ViewModel と DTO が含まれます。 また、アプリケーション コードの約 XNUMX ～ XNUMX% は、AutoMapper などのペンや松葉杖を使用して、あるクラスから別のクラスにデータを転送するのに費やされます。 このコードは作成する必要があり、プログラマーはそれを作成および保守するために報酬を受け取る必要があります。

1C 言語は、主流言語のレベルまで複雑化せずに開発するのが難しいため、単純さという利点が失われていることがわかりました。 本質的に解決されているベンダーのタスクは何ですか。路上で見つけた学生なら誰でも、必要な品質レベルでカスタマイズできる標準ソリューションを発行することです (つまり、露店から大規模工場までをカバーするケースが完成します)。 あなたが屋台の場合は学生を連れて行き、工場の場合は実施パートナーから指導者を連れて行きます。 実施パートナーが指導者の価格で学生を販売しているという事実は、このフレームワークには問題ありません。 アーキテクチャ的には、フレームワークは両方の問題を解決する必要があり、標準構成のコード (カスタマイズを約束して企業に販売しました) は学生が理解できる必要があり、専門家は必要なことを何でも理解できる必要があります。

私の意見では、この言語に本当に欠けているもの、つまり能力以上の文章を書かざるをえないものは、顧客が支払った時間を無駄にしているものなのです。

• TypeScript などのレベルでの入力の可能性 (その結果、IDE のコード分析ツールがより開発され、リファクタリングが行われ、攻撃的な枠が減少します)
  ファーストクラスオブジェクトとしての関数の可用性。 概念は少し複雑ですが、典​​型的な定型コードの量は大幅に削減できます。 私見ですが、量が減った分、学生のコードへの理解はさらに深まると思います。
• ユニバーサル コレクション リテラル、初期化子。 同じことです - 記述したり、目で確認したりする必要があるコードの量を減らします。 コレクションの充填には、9000C プログラミング時間の 1% 以上が費やされます。 糖衣構文を使用せずにこれを記述すると、長くなり、コストがかかり、エラーが発生しやすくなります。 一般に、1C ソリューション内の LOC の量は、利用可能なオープン フレームワーク、および一般にすべてのエンタープライズ Java を組み合わせたものと比較して、考えられるすべての制限を超えています。 この言語は冗長であり、これがデータ量、メモリ、IDE ブレーキ、時間、費用にまで影響します。
• 最後に、この構造がロシア語にうまく翻訳できなかったために欠落しているという仮説があります:)
• 独自のデータ型 (OOP なし)、VB6 の Type の類似物。 これにより、BSP 内のコメントを使用して構造を入力したり、これらの構造を構築するマジック メソッドを使用したりする必要がなくなります。 コードの減少、ドットによるヒント、問題の迅速な解決、タイプミスや構造のプロパティの欠落によるエラーの減少が得られます。 現在、ユーザー構造の型指定は標準サブシステム ライブラリの開発チームに全面的に委ねられており、その名誉のために、渡されたパラメータ構造の予期されるプロパティに関するコメントを慎重に記述しています。
• Web クライアントで非同期呼び出しを操作する場合、砂糖は必要ありません。 ProcessingNotifications の形式でのコールバック地獄は、メイン ブラウザの API の突然の変更によって引き起こされる一時的な問題ですが、常にこのように生活することはできません。非同期コードの「学生の理解」という利点は失われつつあります。だんだん。 メイン IDE でこのパラダイムのサポートを追加しないと、事態はさらに悪化します。

これは差し迫った問題の XNUMX つであり、リストがさらに大きくなる可能性があることは明らかですが、これはまだ汎用言語ではなく、マルチスレッド、ラムダ関数、GPU へのアクセス、および高速な言語を必要としないことを忘れてはなりません。浮動小数点計算。 これはビジネス ロジックのスクリプト言語です。

すでにこの言語で多くの作業を行っており、js や C# を検討しているプログラマーは、この言語のフレームワーク内では退屈してしまいます。 事実です。 彼には成長が必要だ。 ベンダーにとってのスケールのもう一方の側面は、指定された機能の実装コストと実装後の収益の増加です。 ここでは、会社の目から見て現在何が重要であるかについては何も情報を持っていません。

開発環境

ここでも物事は順調に進んでいません。 開発環境はXNUMXつあります。 XNUMX つ目は、納品物に含まれるコンフィギュレーターです。 XNUMX つ目は、Eclipse に基づいて開発された Enterprise Development Tools 環境 (略して EDT) です。

コンフィギュレーターは、あらゆる開発タスクを提供し、すべての機能をサポートしており、市場の主要な環境です。 噂によると、それ自体が技術的負債を抱えているため、道徳的にも時代遅れであり、発展していません。 この状況は、（友人との友好関係の形で）内部 API をオープンすることで改善される可能性があります。 雪だるま A.オレフコワまたは独立したベースで）しかし、これは当てはまりません。 実際、ベンダーが介入しない限り、コミュニティは IDE に独自の機能を記述することがわかっています。 しかし、私たちは持っているものを持っています。 コンフィギュレーターは 2004 年から 2005 年にかけて素晴らしく、当時の Visual Studio を非常に彷彿とさせました。一部の場所ではさらにクールでしたが、当時のままでした。

さらに、平均的な標準ソリューションの量はそれ以来数倍に増加しており、今日では IDE は供給されるコードの量にまったく対応できなくなっています。 ユーザビリティやリファクタリング能力はゼロではなく、赤字です。 これらすべてが開発者に熱意をもたらすわけではなく、他のエコシステムに移動してそこでたわごとのコードを書き続けることを夢見ていますが、その動作で顔に唾を吐きかけることのない快適な環境で。

代わりに、Eclipse 上に構築された、最初から書かれた IDE が提供されます。 そこでは、他のソフトウェアと同様に、ソースはテキスト ファイルの形式で存在し、GIT、プル リクエスト ブランチなどに保存されます。 マイナス面としては、リリースごとに改善されているにもかかわらず、何年もベータ版の状態から抜け出せていないことです。 EDT のデメリットについては書きません。今日はマイナスですが、明日は固定機能です。 そのような説明の関連性はすぐに薄れてしまいます。 現在、EDT で開発することは可能ですが、これは異例であり、ある程度の数の IDE のバグを覚悟する必要があります。

前述の「1C プリズム」を通して状況を見ると、次のようなことがわかります。新しい IDE のリリースによってボックスの売上は増加しませんが、開発者の流出は減少する可能性があります。 開発者の快適さという点でエコシステムに何が待っているのかを言うのは難しいが、マイクロソフトはすでにモバイル開発者にサービスを提供するのが遅すぎて、彼らを台無しにしている。

開発管理

ここでのすべては、コードを書くよりもはるかに優れています。特に最近、コミュニティの努力によって管理の自動化の問題が明らかになり、1C リポジトリをゴミ箱に捨て、git、クイック責任、コードレビューを使用することを要求するプロトタイプが立ち上げられました。 、静的分析、自動デプロイなど。 開発タスクの自動化レベルを高める多くの機能がプラットフォームに追加されました。 ただし、これらすべての機能は、自動化なしではやっていけないことが明らかになったときに、自社の大規模製品の開発のためにのみ追加されました。 自動マージ、KDiff との XNUMX 者間比較などがありました。 Github で公開されました gitコンバータ率直に言って、彼はイデオロギー的にプロジェクトから引きずり出されました gitsyncですが、ベンダー企業のプロセスに合わせて変更されています。 オープンソースの頑固な人たちのおかげで、1C での開発自動化が軌道に乗りました。 コンフィギュレータ用のオープン API (私見ですが) も、メイン IDE の倫理的後進性を変えるでしょう。

現在、Jira の問題にリンクされたコミットを含む 1C ソースを Git に保存し、Crucible でレビューし、Jenkins と Allure からのボタンを押して 1C でのコード テストのレポートを保存しています。 SonarQube での静的解析 - これはニュースではなく、むしろ 1C 開発が多い企業では主流です。

行政

ここで言いたいことはたくさんあります。 まず、これは当然サーバー (1C サーバー クラスター) です。 素晴らしいことですが、これは完全にブラック ボックスであるため、十分な詳細が文書化されていますが、特定の方法で、複数のサーバー上で高負荷モードでの中断のない操作の起動をマスターできるのは、 「技術問題の専門家」と刻まれたメダル。 原則として、1C サーバーの管理は他のサーバーの管理と何ら変わらないことに注意してください。 これは、メモリ、CPU、ディスク リソースを消費するネットワーク ベースのマルチスレッド アプリケーションです。 テレメトリの収集と診断のための十分な機会を提供します。

ここでの問題は、ベンダーがこの診断に対する既製のソリューションに関して特別なものを何も提供していないことです。 はい、1C: Instrumentation and Control Center があります。これらは非常に優れていますが、非常に高価であり、誰もが持っているわけではありません。 コミュニティには、Grafana、Zabbix、ELK、その他の標準管理セットを接続するためのアイデアが多数ありますが、大多数に合う単一のソリューションはありません。 その任務は主人公を待っています。 また、1C クラスターでの立ち上げを計画している企業の場合は、エキスパートが必要です。 内側からでも外側からでも、あなたにはそれが必要です。 サーバー操作に関するコンピテンシーを備えた別の役割があるのは通常のことですが、すべての 1C ユーザーがこれを知っている必要はありません。そのような役割が必要であることを理解する必要があるだけです。 SAPを例に考えてみましょう。 そこでは、プログラマは、アプリケーション サーバー上で何かを設定するよう求められても、おそらく椅子から立ち上がることすらできないでしょう。 彼はただ愚かなだけかもしれないし、恥じることはないでしょう。 SAP 方法論では、これに対して別の従業員の役割があります。 何らかの理由で、1C 業界では、これを同じ給与の XNUMX 人の従業員に統合する必要があると考えられています。 それは妄想です。

1Cサーバーの欠点

まさにマイナスが1つあります - 信頼性です。 または、予測不可能性をお好みの場合に使用します。 サーバーの突然の奇妙な動作がすでに話題になっています。 サーバーを停止してすべてのキャッシュをクリアするという普遍的な解決策は、専門家のハンドブックにも記載されており、これを行うバッチブックも推奨されています。 1C システムが理論的にもすべきではないことを実行し始めた場合は、セッション データ キャッシュをクリアする必要があります。 私の推定によると、この手順を使わずに XNUMXC サーバーを運用する方法を知っている人は全国で XNUMX 人だけであり、彼らは秘密を共有していません。 彼らはこれから生きていくのです。 おそらく彼らの秘密は、セッションデータを消去しているのに、それについては誰にも話していないことです。

それ以外の点では、1C サーバーは他のアプリケーションと同じアプリケーションであり、ドキュメントを読んでタンバリンをたたくというほぼ同じ方法で管理されます。

デッカー

実稼働環境でコンテナ化された 1C サーバーを使用することの有用性はまだ証明されていません。 バランサーの背後にノードを追加するだけではサーバーはクラスター化されないため、実稼働コンテナ化の利点が最小限に抑えられ、高負荷モードのコンテナーで正常に動作する方法が確立されていません。 その結果、開発者のみが Docker+1C を使用してテスト環境をセットアップします。 そこでは、それは非常に便利で応用的であり、最新のテクノロジーを使って遊んだり、コンフィギュレーターの落胆から休憩したりすることができます。

商用コンポーネント

投資の観点から見ると、1C ではアプリケーション クラスの幅広い機能により、ビジネス アイデアを迅速に立ち上げるという問題を解決できます。 1C はすぐに使用でき、非常に適切なレポート機能、あらゆるものとの統合、Web クライアント、モバイル クライアント、モバイル アプリケーション、さまざまな DBMS のサポートを提供します。 サーバー部分とインストールされたクライアント部分の両方をクロスプラットフォームで無料で利用できます。 はい、アプリケーションの UI は黄色になります。これがマイナスになる場合もありますが、常にそうとは限りません。
1C を選択することで、企業は非常に幅広いアプリケーションを構築できる一連のソフトウェア ソリューションを手に入れることができます。また、Javaist よりも少ない資金で、同時により早く結果を出したいと考えている市場の多くの開発者も同様です。

たとえば、PDF の請求書をクライアントに送信するタスクは、学生の 1 時間の作業で解決できます。 .NET における同じ問題は、独自のライブラリを購入するか、ひげを生やした厳格な開発者が数日または数週間コーディングすることで解決できます。 場合によっては、両方を同時に行うこともあります。 はい、私は PDF の生成についてのみ話しました。 この法案がどこから出てくるかについてはまだ述べていません。 Web フロントエンダーは、オペレーターがデータを入力するフォームを作成する必要があり、バックエンダーは、JSON を転送するための dto モデル、データベースに保存するためのモデル、データベース自体の構造、データベースへの移行、グラフィカル データベースの形成を作成する必要があります。このアカウントそのものを表示し、それからのみ - PDF を表示します。 XNUMXC では、ゼロからのタスク全体がちょうど XNUMX 時間で完了します。

売買の 3 つのビジネス プロセスを伴う小規模な屋台向けの本格的な会計システムは 3 時間で完了します。販売レポート、購入価格と販売価格での商品の会計処理、倉庫別の内訳、アクセス権管理、Web クライアントおよびモバイル アプリケーションが含まれます。 。 さて、申請のことを忘れていました。申請は XNUMX 時間ではなく XNUMX 時間で完了しました。

.NET 開発者がクリーンなコンピューターに Visual Studio をインストールしてから顧客にデモンストレーションするまで、このタスクにどれくらい時間がかかりますか? 開発費はどうなるのでしょうか？ 同じこと。

1Cのプラットフォームとしての強み

1C が強いのは、世界最高であるという特別な何かがあるからではありません。 それどころか、個々のサブシステムでは、世界中のソフトウェアの中でより興味深い類似物を見つけることができます。 しかし、さまざまな要因を総合すると、1C に似たプラットフォームは見当たりません。 ここに商業的な成功があります。 このプラットフォームの利点はプラットフォーム全体に散在しており、これが他のプラットフォームでどのように行われているかを見ると最もよくわかります。 基本的に、これらは機能ですらではなく、逆に、ある特定のパラダイムを支持して機能を拒否することになります。 いくつかの例:

1. ユニコード。 これ以上簡単なことはないでしょうか？ 2019 年には、シングルバイト ASCII エンコーディングを使用する必要はありません (古いレガシーエンコーディングとの統合を除く)。 一度もない。 しかし、そうではありません。 いずれにせよ、あるテーブルの誰かがシングルバイトの varchar を使用すると、アプリケーションはエンコーディングで問題が発生します。 2015 年に、gitlab の LDAP 認証はエンコーディングの誤った処理が原因で失敗しましたが、JetBrains IDE は依然としてファイル名にキリル文字が含まれるすべての場所で機能しません。 1C は、アプリケーション コードをデータベース層から高品質に分離します。 そこでは低レベルでテーブルを入力することは不可能であり、データベースレベルで無能な後輩の側枠を使用することは不可能です。 確かに、無能な後輩による他の問題もあるかもしれませんが、問題の種類ははるかに少ないです。 ここで、アプリケーションが正しく設計されており、データベース アクセス層が本来あるべきように分離されていることがわかります。 企業のカスタム Java アプリケーションをもう一度見てください。 親密かつ誠実に。 あなたの良心があなたを悩ませていますか？ それなら嬉しいです。
2. 文書/参考図書の番号付​​け。 1C では、それは間違いなく最も柔軟ではなく、最高でもありません。 しかし、彼らが銀行業務ソフトウェアや自作の会計システムで行っていることは、まさに暗闇です。 ID が行き詰まるか (そして、「ああ、なぜ穴があるんだろう」となります)、あるいは逆に、DBMS レベルでロックを使用して動作するジェネレーターを作成することになります (そしてボトルネックになります)。 実際、この一見単純なタスクを実行するのは非常に困難です。エンティティのエンドツーエンドの列挙、特定のキーのセットに基づく一意性セクション、プレフィックスを使用して、並列データ入力中にデータベースをブロックしないようにする必要があります。 。
3. データベース内のレコードの識別子。 1C は強い意志を持った決定を下しました。すべてのリンク識別子は完全に合成されており、それだけです。 また、分散データベースや交換には問題はありません。 他のシステムの開発者は、アイデンティティのようなもの (短いものです!) を頑固に作成し、関連するインスタンスをいくつか作成する時期が来るまで、それを GUI にドラッグします (その後、それらは検出されます)。 これ持ってないの？ 正直に？
4. リスト。 1C には、(大きな) リストをページングしてナビゲートするための非常に優れたメカニズムがあります。 仕組みを正しく使って、今すぐ予約しましょう！ 一般に、このトピックは非常に不快であり、理想的に解決することはできません。直観的で単純である (ただし、クライアントに巨大なレコードセットが存在するリスクがある) か、ページングに何らかの問題があるかのどちらかです。 ページングを行う人は、多くの場合、不正な方法でページングを行っています。 正直なスクロールバーを作成する人は、データベース、チャネル、クライアントを追加します。
5. 管理されたフォーム。 確かに、Web クライアントではインターフェイスが完全には機能しません。 しかし、それはうまくいきます。 しかし、他の多くの会計システムや銀行システムにとって、リモート ワークプレイスの構築はエンタープライズ レベルのプロジェクトです。 免責事項: 幸いなことに、元々 Web 上で作成した人にとっては、これは影響しません。
6. モバイルアプリ。 最近では、同じエコシステム内でモバイル アプリケーションを作成することもできます。 ここでは、Web クライアントの場合よりも少し複雑です。デバイスの仕様により、デバイス専用に記述する必要がありますが、それでも、モバイル開発者の別のチームを雇うことはありません。 企業の内部ニーズに対応するアプリケーションが必要な場合 (黄色の UI デザインよりも企業の問題に対するモバイル ソリューションの方が重要な場合)、同じプラットフォームをそのまま使用するだけです。
7. 報告。 この言葉は、ビッグデータを使用し、ETL プロセスに遅れをもたらす BI システムを意味するものではありません。 これは、現時点での会計の状態を評価できる運用スタッフのレポートを指します。 残高、相互決済、再グレーディングなど1C には、ユーザー側でグループ化、フィルター、視覚化を柔軟に設定できるレポート システムが付属しています。 はい、市場にはもっとクールな類似品があります。 ただし、オールインワン ソリューションの枠組み内ではなく、価格がオールインワン ソリューションよりも高くなる場合があります。 そして多くの場合、その逆です。レポートのみですが、プラットフォーム全体よりも高価で、品質は劣ります。
8. 印刷可能なフォーム。 さて、.NET を使用して、従業員に PDF の給与明細を電子メールで送信するという問題を解決します。 そして今度は請求書を印刷する作業です。 コピーを同じ PDF に保存する場合はどうすればよいでしょうか? 1C ニックネームの場合、レイアウトを PDF に出力するには +1 行のコードが必要です。 これは、別の言語では数日または数週間ではなく、+ 40 秒の作業時間がかかることを意味します。 1C の印刷フォーム レイアウトは開発が非常に簡単で、有料のフォーム レイアウトと競合できるほど強力です。 はい、おそらく、1C スプレッドシート ドキュメントにはインタラクティブな機会があまりなく、OpenGL を使用してスケーリングを備えた 3D 図をすぐに取得することはできません。 しかし、それは本当に必要なのでしょうか？

これらは、機能の制限や妥協の実装が将来的にアーキテクチャ上の重要な利点になることが判明するほんの一例にすぎません。 たとえ妥協であっても、最も効果的な選択肢でなくても、それはすでに箱に入っており、当然のことと考えられています。 その独立した実装は不可能であるか (そのような決定はプロジェクトの開始時に行う必要があり、そのための時間がなく、アーキテクトがまったく存在しないため)、費用のかかる反復を数回繰り返す必要があります。 リストされた各点 (これはアーキテクチャー ソリューションの完全なリストではありません) で、失敗してスケーリングを妨げる制限を導入する可能性があります。 いずれにせよ、ビジネスマンとして、「システムをゼロから」作るとき、プログラマーがきちんとした腕を持ち、システムの微妙な問題をすぐにうまく処理してくれるかどうかを確認する必要があります。

はい、他の複雑なシステムと同様に、1C 自体にも特定の側面でスケーリングをブロックするソリューションがあります。 しかし、繰り返しになりますが、さまざまな要因、所有コスト、および事前に解決済みの問題の数を考慮すると、市場に価値のある競合他社は見当たりません。 同じ価格で、金融アプリケーション フレームワーク、UI と Web インターフェイス、モバイル アプリケーション、レポート機能、統合機能、その他多数の機能を備えたクラスター化されたバランスの取れたサーバーを入手できます。 Java の世界では、フロントエンドとバックエンドのチームを雇い、低レベルの自作サーバー コードをデバッグし、2 つのモバイル OS 用の 2 つのモバイル アプリケーションに対して別々に支払います。

1C がすべてのケースを解決するとは言いませんが、企業内アプリケーションの場合、UI をブランド化する必要がない場合、他に何が必要でしょうか?

軟膏の中を飛ぶ

おそらく、1C が世界を救い、企業システムを記述する他の方法はすべて間違っているという印象を持っているでしょう。 全然そんなことないですよ。 ビジネスマンの観点から、1C を選択した場合、市場投入までの時間が短いことに加えて、次の欠点を考慮する必要があります。

• サーバーの信頼性。 中断のない稼働を保証できる、本当に質の高い専門家が必要です。 ベンダーがそのような専門家向けに用意したトレーニング プログラムを私は知りません。 エキスパート試験の準備をするためのコースもありますが、私の意見では、これだけでは十分ではありません。
• サポート。 前の段落を参照してください。 ベンダーからのサポートを受けるには、ベンダーを購入する必要があります。 何らかの理由で、これは 1C 業界では受け入れられません。 SAP では、これはほぼ必須の購入であり、誰にも迷惑をかけません。 企業のサポートやスタッフの専門家がいない場合、1C の不具合が放置される可能性があります。
• それでも、1C ですべてを完全に実行できるわけではありません。 これはツールであり、他のツールと同様に適用範囲には制限があります。 1C 環境では、「非 1C」システム アーキテクトが存在することが非常に望ましいです。
• 優れた 1C ニックネームは、他の言語の優れたプログラマーよりも安くありません。 ただし、劣悪なプログラマーは、使用する言語に関係なく、雇用に高い費用がかかります。

点を打ってみよう

• 1C はビジネス向けの高速アプリケーション開発 (RAD) フレームワークであり、これに合わせて調整されています。
• 主要な DBMS、クライアント UI、非常に優れた ORM、レポートをサポートする XNUMX 層リンク
• 1C ではできないことを実行できるシステムとの統合の幅広い可能性。 機械学習が必要な場合は、Python を使用し、結果を http または RabbitMQ 経由で 1C に送信します。
• 1C を使用してすべてを実現しようとする必要はありません。XNUMXC の長所を理解し、それを自分の目的に合わせて使用​​する必要があります。
• 技術的なフレームワーク ガジェットを掘り下げ、N 年ごとに新しいエンジンに再設計することに惹かれる開発者は、1C にはうんざりしています。 そこではすべてが非常に保守的です。
• メーカーからの関心がほとんどないため、開発者も退屈しています。 退屈な言語、弱い IDE。 近代化が必要です。
• 一方、自分が楽しんでいる別のテクノロジを使用したり学習したりすることで楽しみを見つけられない開発者は、悪い開発者です。 彼らは泣き言を言って別の生態系に移動します。
• 1C のニックネームに Python で何かを書くことを許可しない雇用主は悪い雇用主です。 探究心を持った従業員を失い、代わりに猿のプログラマーがやって来て、すべてに同意しながら企業ソフトウェアを沼地に引きずり込むことになるでしょう。 まだ書き直す必要があるので、もう少し早めに Python に少し投資したほうがよいでしょうか。
• 1C は営利企業であり、自社の利益と便宜のみに基づいて機能を実装しています。 このことで彼女を責めることはできません、ビジネスは利益について考えなければなりません、それが人生です
• 1C は、Vasya の開発者の問題ではなく、ビジネス上の問題に対するソリューションを販売することで収益を上げています。 これら 1 つの概念は相互に関連していますが、優先順位はまさに私が述べたとおりです。 開発者 Vasya が XNUMXC: Resharper の個人ライセンスを支払う準備ができたら、すぐに表示されます。A. Orefkova による「Resharper」がこれを証明しています。 ベンダーがそれをサポートし、それに対抗しなければ、開発者向けのソフトウェア市場が現れるでしょう。 現在、この市場には疑わしい結果をもたらしているプレーヤーが XNUMX 人半いますが、その理由はすべて、IDE との統合が否定的で、すべてが松葉杖で行われているためです。
• 複数の機械を操縦するという慣行は忘れ去られるでしょう。 最近のアプリケーションは大きすぎて、コードの面でもビジネスでの使用の面でも覚えておくことができません。 1C サーバーもますます複雑になり、1 人の従業員があらゆる種類の専門知識を保持することは不可能になります。 これには専門家の需要が伴い、これは XNUMXC の専門職の魅力と給与の増加を意味します。 以前、Vasya が XNUMX つの給与で XNUMX つを同時に働いていた場合、現在は XNUMX 人の Vasya を雇用する必要があり、Vasya 間の競争によりレベルの全体的な成長が促進される可能性があります。

まとめ

1Cは非常に価値のある製品です。 私の価格帯では類似品をまったく知りません。もしあればコメントに書いてください。 しかし、エコシステムからの開発者の流出はますます顕著になっており、これはどう見ても「頭脳流出」です。 業界は近代化に飢えています。
あなたが開発者であれば、1C にこだわったり、他の言語ではすべてが魔法のようになると考えたりしないでください。 ジュニアのうちはそうかもしれない。 より大きな問題を解決する必要がある場合は、すぐに既製のソリューションを長期間探して、より集中的に完了する必要があります。 ソリューションを構築するための「ブロック」の品質という点では、1C は非常に優れています。

そしてもう 1 つ、1C というニックネームが採用の依頼に来た場合、1C というニックネームは安全に主任アナリストの役職に任命されます。 彼らのタスク、主題分野、分解スキルに対する理解は優れています。 これはまさに XNUMXC 開発で DDD を強制的に使用したためだと確信しています。 その人は、まず第一にタスクの意味、つまり対象領域のオブジェクト間の接続について考えるように訓練されており、同時に統合テクノロジとデータ交換形式の技術的背景を持っています。

理想的なフレームワークは存在しないことを認識し、自分自身を大切にしてください。
すべての人に良い！

PS: ありがとうございました スペシュリック 記事の作成にご協力ください。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

あなたの企業に 1C はありますか?

• 視聴者の３８%がまったくありません。71

• 視聴者の３８%がありますが、経理部門のどこかにしかありません。 他のプラットフォーム上のコア システム162

• 視聴者の３８%がはい、主要なビジネスプロセスがそれに取り組んでいます221

• 視聴者の３８%が1C は死ななければなりません、未来は %technology_name%80 のものです

534 人のユーザーが投票しました。 99名のユーザーが棄権した。

出所： habr.com