大規模開発において最も重要なインフラストラクチャコンポーネントは何ですか?

Question

エンタープライズ ビジネス アプリケーションの基礎となる構成要素にはどのようなものがありますか?複数のアプリケーションが共有する再利用可能なコンポーネントについて考えています。

1. スケールアップの高速化
2. 再構築を排除して開発をスピードアップ
3. 主要な障害点を最小限に抑えて安定したインフラストラクチャを提供する

一元化/標準化で成功した概念の例をいくつか示します。

• ロギング
• 順番待ち
• スケジュール設定

Answer 1

私はチームが同じ外観を維持し、アプリケーション（s）は全体で感じることができるようにGUIウィジェットを追加したい。

同様に、複数のチームが同様のサブシステムのためのいくつかの時点で一緒にデザインパターンのセットを接続しようとしているサブシステム上で動作しなければならない大規模なプロジェクトで貴重である。

また、必要とする一般的なユーティリティがうまく働いているときに行く場所である（採用ブーストC ++でいっそまたは）ライブラリの共通セットを作成します。

私も、早い段階でのサンプルとテストフレームワークを作成します。私はあなたがサブシステムをテストするためのテンプレートを持っているならば、人々はそれを使用することを発見しました。任意のテストフレームワークがなければ初期のあなたには、開発者テストのすべての両極端を得るためにバインドされています。

Answer 2

コンポーネントというときは、コード コンポーネントを意味しますか、それともインフラストラクチャ コンポーネントを意味しますか?私は、コードではなくインフラストラクチャ (サービスとプロセスをサポートする) が、開発の品質、速度、容易さにおいて最大のメリットをもたらすと主張します。あなたが挙げた例は、現在ほとんどの言語の標準ライブラリに含まれているか、アプリケーション/ユースケースに非常に固有のものです。

また、バージョン管理はすべての開発に不可欠であるため、バージョン管理は当然のことであると仮定します。

私が言うのは、 ほとんど 重要なインフラは 継続的なビルド/自動テスト. 。これにより、人々は好きなコードを書いてチェックインし、他の人のコードでも動作することを確認できるようになります。

2 番目に重要なのは、 共通ライブラリ. 。これらにより、開発が迅速化され、外観、感触、デザインの標準 (できれば良いもの) を確立できるようになります。共通ライブラリの使用が増えるにつれて、それらの小さな変更が回帰を引き起こす可能性があるため、継続的なビルドの重要性が増します。

ただし、一般的なライブラリの問題の 1 つは、適切に設計するために多大な労力がかかり、再利用する価値があり、その点に到達するまでに長い時間がかかることです。ほとんどはプロジェクトに固有のものとして開始され、その後誰かがそれを自分のプロジェクトにハッキングし、その後いくつかの分岐を経て、コピー＆ペーストします。おそらくしばらく、何年も経つと、誰かがコードを監査し、共通の場所にマージし始めるでしょう。共通ライブラリのアップグレードと、それらの 2 つのバージョンを同時に使用する方法 (または使用するかどうか) について計画を立てる必要があります。もう 1 つの隠れた欠点は、短期的にはより迅速な開発が可能になりますが、人々が古いバージョンに閉じ込められるため、長期的には開発が妨げられることです (これはサードパーティ ライブラリに当てはまります)。

3番目は ビルドツール. 。これは、ビルド、チェックアウト、検索など、何らかの方法でコードを操作する作業を簡素化するための共通ツールを意味します。パッチを送信するときにバグを解決済みとしてマークすることを自動化したり、依存関係が変更されたことを継続的ビルダーに通知したり、テストを送信する前にテストを自動的に実行して、テストを簡単 (かつ高速) に実行できるようにするもの。

4番目は 密閉構造, 、これはビルド ツールの単純な拡張機能です。これは、アプリが自己完結型であることを意味します。これには次の 2 つの利点があります。1) マシンの再利用が簡単で、さらに重要なことは、2) 開発者にとって非常に簡単に開始できることです。追加のライブラリをインストールしたり、/etc 内の何かを変更したり、環境に何かを設定したりする必要はありません。ただビルドするだけです。そして走ります。

私が考えることができる他のものは次のとおりです。

• 監視:すべてが同じ監視方法を使用している場合、共通ライブラリをブラックボックスで監視する必要はありません。また、すべてのデータが 1 か所にあるため、問題の特定が容易になります。
• ログストレージ:丸太をグレッグしたり調べたりするのは面倒です。すべてのログが構造化された形式で保存される一元的な場所があると、問題の検索と発見が容易になります。
• 支店管理:大規模なプロジェクトでは、これにより、開発者は開発、テスターはテストし、リリーサーはお互いに足踏みすることなくリリースすることができます。

Answer 3

完全にインフラストラクチャ領域に属しているわけではありません。

• 定義された論理データ モデル。
• 定義されたビジネス プロセス (エッジ ケースもカバー)。

これらがなければ、同じ顧客に対して一連のアプリケーション開発がアクティブになることになります。

• ロギング
• 順番待ち
• スケジュール設定

これらはすべて、それらを使用するアプリケーションのニーズに合わせて既製のものである必要があります。例えば。J2EE ビルド アプリケーションのロギング ソリューションは、.NET のものとは異なります。(重要な企業では、モノカルチャー自体が問題になる可能性があります。)