1Cが良い理由

この出版物は、 「なぜ1Cが悪いのか、なぜ1Cプログラマーがそのように好まないのか」という非常に表面的で一方的な出版物に応えて作成されました。 コメントから判断すると、多くの人が実際に1Cでプログラミングしていることを理解するには程遠い。

1.プラットフォームと構成

ほとんどのプログラマーの理解では、1Cは会計です。 これは6.0まで含まれていました。 バージョン7.5以降、アプリケーションは2つの部分で構成されます。C++で記述されたプラットフォームと、Visual Basicと非常によく似た1Cのテーブル、ビジュアルオブジェクト、およびコードの構造の説明を含む構成です。



このことから、プラットフォームは、簿記に関係のない問題を含め、非常に広範な問題を解決できることになります。 1Cなしのすべては、多数のクライアントアプリケーション+データベースによって解決されます。 少し前に、同社は標準構成の基礎となるライブラリをリリースし始めましたが、サードパーティのプロジェクトで使用することもできます-標準サブシステムのライブラリと接続機器のライブラリ。 これらには、たとえば、ユーザーのリストの維持、組み込みの電子メールクライアント、交換ルールによる交換などのインフラストラクチャ機能が含まれます。 利点は、それらが十分に説明されており、部分的に実装できることです。

2.著者

パラグラフ1で説明したように、プラットフォームと構成は異なるソフトウェア製品であり、開発者の異なるグループによって作成されており、私の情報によれば、互いにほとんど接触していません。 プラットフォームは非常に経験豊富な開発者によって作られており、多くの開発者が7.5以降から開発に関与しています。 1996年から。 構成では、すべてがさらに悪化します。 たくさんの設定があります、と言うかもしれません-非常に多くです。 非常に多くの著者がいますが、いくつかの経験から大きな疑問が生じます。 人事ポリシーから判断すると、構成の作成者との式典には立ちません。 たとえば、新しいフラッグシップソリューション「ERP。 エンタープライズ管理2.0は、まったく新しい若いチームを作成します。 以前の主力ソリューションである「Production Enterprise Management」（SCP）を開発したチームは、仕事をしていませんでした。

したがって、プラットフォームの品質は常に1Cの標準構成の品質よりも優れています。

3.製造性

例1Cは、国内のIT企業が非常に成功しており、世界クラスのソフトウェア製品を作成できることを示しています。 1Cプラットフォームには、会計システムのグローバル市場向けのユニークなソリューションがあります。 例：



3.1。 レイアウトにスプレッドシートドキュメントを使用すると、行ごとに異なる列形式（つまり、異なる行の列の数が異なる）を使用できます。 この形式からXLSにエクスポートすると、すべての形式を反映するために必要な数の列が作成されます。

3.2。 データ構成スキーム（ACS）。現在のデータベースのテーブル、外部SQLまたはOLAPデータソースのテーブル、メモリの任意のテーブルのデータに基づいて、複雑なレポートを作成できます。 SQL言語のサブセットである言語でコンパイルされたクエリテキストでは、選択、選択、並べ替えフィールドの挿入位置を指定できます。 レポートを設定した後、ACSは要求テンプレートをデータベースサーバーに送信される最終フォームに変換します。 この場合、ACSは結果に必要のないクエリのフィールドと一時テーブルを計算し、クエリから除外します。

3.3。 WindowsおよびLinux、ロシア語および英語での開発の可能性。 Windows、Linux、Webブラウザー、iOS、Androidでアプリケーションを実行できます。 同時に、ブラウザーで1C機能を実行するために、1C言語からJavaScriptへの自動翻訳が実行されます。

3.4。 独自のクエリ言語を使用すると、アプリケーションは次のMicrosoft SQL Server、Oracleデータベース、IBM DB2、Postgre SQL、ファイルデータベース1Cのいずれかと連携できます。 バージョン管理されたデータベースを正しく動作させるために、OracleとPostgreは独自のロックメカニズムを使用します。

3.5。 UUIDをデータベースの行識別子として使用すると、1C上のさまざまなシステムを相互に統合するタスクを簡素化できます。

3.6。 プラットフォームでサポートされているすべての異なるオペレーティングシステムとブラウザのC ++でコンポーネントを作成できる外部コンポーネントのメカニズム。

3.7。 クエリテンプレートを使用してレコードレベルでアクセス権を制限します。これにより、権限を微調整する無限の可能性が得られます。

3.8。 データベース構造をアプリケーション構造から完全に分離します。 データベースのテーブルとフィールドの名前は自動的に生成されます。これにより、プラットフォーム統合メカニズムを使用できるようになり、次に、ロシア語でアプリケーション構造要素（メタデータ）の通常の名前を作成できるようになります。

3.9。 分散情報ベースのメカニズム。現在の情報ソースのノードを無制限に作成でき、データの変更がダウンロードされ、そこから構成変更がダウンロードされます。



そして何よりも、その開発者は前進することを恐れず、非常に野心的なタスクを解決します。 私の意見では、1Cプラットフォームは非常に成功した瞬間に生まれました。コンピューターのパフォーマンスとメモリ容量は、常に最適ではないにしても、非常に大胆な設計決定を実装するのに十分になりました。

4.開発者

当初、このプラットフォームは、プログラミングから遠く離れた人々（技術教育を受けていない人でも）がシステム改善を行えるように開発されました。 プラットフォーム7の場合*これは公平で、非常にコンパクトで理解しやすいものでしたが、少々混乱を招きました。 8.0のリリースにより、開発者の水準は非常に高くなりました。8.3プラットフォームのすべてを考慮すると、1Cの優れた開発者という概念自体は非常に曖昧ですが、技術教育のない専門家にとってはほぼ不可能であると確信できます。



典型的なSCP構成のボリュームは、データベース構造、レポートレイアウト、ロールなどを含まない約300万行のコードです。 厳密なタイピングの欠如とロシア語は、プログラミングから遠く離れた多くの人々を単に惹きつけ、何かを変えてしまい、その結果、何かが機能しなくなる。



したがって、開発者の間の下位カーストとして「1Cプログラマー」という用語が出現しました。 プラットフォーム開発者は何らかの形でこの状況に貢献します。そうしないと、以前はコンフィギュレーターからクエリデザイナーを除外していました。 それを使用して記述された多かれ少なかれ複雑なクエリは、 govnokod.ruの直接の候補です。



1Cは違います。 非IT企業で働くことも、IT企業で働くこともできますし、1C自体で働くこともできます。 1Cはこれらすべての場所で異なります。 大規模なフランチャイジー会社で働いている場合、プログラマーの仕事は他のIT会社での仕事と大差ありません。



誤解の1つは、優れた1Cプログラマーが会計を知っている必要があるということです。 カテゴリー的にはそうではありませんが、簿記は経理アナリスト、生産および原価計算-管理会計アナリスト、給与-給与アナリストに知られるべきです。 1Cの開発者にとって上記の分野の知識は、アナリストが彼に何を望んでいるかを正確に理解するために必要です。 システムプログラマがOSの基本を、Webプログラマがレイアウトの基本を知っている必要があるのと同じです。 しかし、優れた1C開発者が知っておくべきことは次のとおりです。



4.1。 DBMS、クエリプランナー、ロックの原則。

4.2。 クライアント、アプリケーションサーバー、およびデータベース間のデータ交換の最小化。

4.3。 COM、ADO、XML、SOAPを操作するREST APIが最近登場しました。



もちろん、高品質のコードを書くには、ソフトウェア開発技術に関する文献を読む必要があり、さらに他のプログラミング言語での開発経験が必要です。 残念ながら、1Cプログラマーの大多数はこれに気づいていません。

5.プラットフォームの問題

すべての利点にもかかわらず、プラットフォームには問題があります。 さらに、それらの多くは何十年も解決されていません。

5.1。 コンフィギュレーターにプラグインがありません。 プラットフォーム7.7にはopenConfプロジェクトがあります。 8.では、プロジェクト「Snowman」があります。 しかし、これらはすべて実際にはハッキングであり、それらの使用の可能性とサポートの質には非常に残念です。

5.2。 p-codeを実行する仮想マシンのパフォーマンスが悪い バイナリ変換は使用されません。 現在、この状況は、1Cの典型的な構成の開発者のアプローチに影響を与え始めています-クエリが広く使用されるようになりました。

5.3。 データベースの構造と特定のデータベースのクエリを微調整する機能の欠如。 たとえば、データベースツールを使用して追加のインデックスを追加する必要がありますが、これはライセンス契約に違反しています。

5.4。 治療間の継承の欠如は、OOPの欠如を何らかの形で補いました。 7.7のopenconfプロジェクトでは、この機能は非常に快適でした。

5.5。 独自の構成リポジトリを使用します。 この場合、構成全体をxml形式でアップロード/ダウンロードできますが、各アップロード/ダウンロードはファイルの変更を分析しないため、ディレクトリ内のすべてのファイルは愚かに上書きされ、最初にプロセスが長くなります（ソフトスターターの構成の場合、約15分）、そして第二に、バージョン管理システムの使用を不可能にします。 7.7のopenconfでは、この問題は解決されました。

5.6。 この関数はメインデータベース（SQL Serverの場合はROW_NUMBER）にありますが、クエリのサンプル行番号を取得する方法はありませんが、他のデータベースについては、プラットフォームは他のクエリ言語の構成と同様に、ドキュメントのパフォーマンスに関する必要な左接続を行うことができます;

5.7。 コンフィギュレーターにプロジェクトの概念がないため、テスト環境から作業環境への変更の転送に役立ちます。

5.8。 構成を更新するための標準メカニズムでは、テキストとオブジェクトの単純な比較を使用しますが、マージではなく、標準機能の古いバージョンが構成内に存在します。



1Cはこれらの問題の多くを知っており、Eclipseプラットフォームで書かれた新しいコンフィギュレーターを長い間準備してきましたが、最終的にリリースされたとき、誰も知りません。



次の出版物では、特に新しいフラッグシップ「ERP Enterprise Management 2.0」のリリースを考慮して、古いフラッグシップ構成「Production Enterprise Management」の例を使用して、1Cの標準ソリューションの欠点を説明します。