私のキャリアの過程で、私はさまざまなレガシープロジェクトに取り組んできましたが、それぞれのプロジェクトには特定の欠陥がありました。

もちろん、多くの場合、主な問題はソフトウェアの品質の低さ（ユニットテストの欠如、クリーンコードの原則の使用の拒否など）でしたが、その原因はプロジェクトの開始時または企業システムが生まれたときでさえ行われたアーキテクチャの決定でした。 私の意見では、この種の問題は多くのプロジェクトにとって最大の苦痛の原因です。

本質的に、特にソフトウェアの職人技の動きが優れたチームプラクティスを促進している今、コードの改善は非常に簡単です。 ただし、システムのコア部分、つまりライフサイクルの最初に課せられる制限を変更することは、非常に難しい作業です。

私が出会ったいくつかのタイプのアーキテクチャソリューションについて説明します。これは、このようなシステムのサポートに関わるチームにとって大きな負担になる可能性があります。

会社全体がデータベースを共有します

これはおそらく私が見た最も一般的な問題の1つです。 複数のアプリケーションが共有データを使用する必要がある場合、なぜ共有データベースへの共有アクセスを許可しないのですか？ 結局のところ、複製はソフトウェア開発において悪とみなされますよね？ まあ、これは常に真実とは限らず、特にデータベースに関してはそうではありません。 Venkat Subramaniamは次のように述べています。「データベースは歯ブラシのようなものです。誰にも使用させないでください。」 データベースを共有することの何がそんなに悪いのですか？ 実際、かなりたくさん...

最初に思い浮かぶのは、データモデルの結合です。 AとBの2つのアプリケーションが車のデータを処理するとします。 付録Aは、修理作業を担当するチームが使用するため、多くの技術情報を保存する必要があります：メカニック、故障、車の介入履歴について...付録Bは、技術チームのタスクを設定するために使用されます。その識別。 この場合、両方のプログラムに同じデータ構造を使用しても意味がありません。異なるデータを使用するため、それぞれ独自のデータ構造を使用する必要があります。 車の識別が容易であるため、これは簡単になり、共通の参照は必要ありません。

2番目の問題も、データモデルのこのメッシュ化によるものです。 アプリケーションBが車の識別子の名前を変更したいと想像してください-サブジェクト領域に関してより論理的な名前を付けてください。 この場合、アプリケーションAも更新する必要があります-列名が変更されているため...結果として、アプリケーションAチームを邪魔しないために、開発者Bは既存の列を変更できないため、別の列の情報を複製し始めます...もちろん、開発者Aは彼らは、2つの列に同じ情報を保存しないように、将来的に列の名前を変更する予定ですが、誰もが知っています。

アプリケーションが1つのソースからデータを読み取るだけでなく、データを変更すると、すべてがさらにうんざりします。 この場合のデータ所有者は誰ですか？ 誰を信頼しますか？ データの整合性はどのように保証されますか？ 同じアプリケーションの異なる部分によって同じデータが変更された場合でも、これはすでに困難ですが、いくつかの異なるアプリケーションがそれを行うと、問題はさらに深刻になります...

私が見た最後のケース：2つのビジネスオブジェクトに関する情報を格納するために同じデータ構造を共有する2つのアプリケーションは、比較的類似しているが、同時にまったく異なるため、データが参照するアプリケーションの理解を大幅に複雑にします。 両方のアプリケーションは、金融市場での実行をモデル化するために同じテーブルを使用しましたが、集計のレベルは異なります。 テーブルに2種類のデータが含まれていることは示されていないため、別のテーブル（2番目のアプリケーションに属する）を調べて、各プログラムによって生成された行を判断する必要がありました...すべての前任者と同じレーキで、不正な（脆弱な）データを使用しました。これにより、会社のすべてのリスクが発生します。

システムは、会社で使用されているソフトウェアに関連付けられています

すべての企業が、ビジネスのすべてのニーズを満たすソフトウェアを開発できるわけではありません。 実際、多くの企業のニーズは同じであり、すでに必要な機能を備えたソフトウェアを市場で簡単に見つけることができるため、多くの場合、これは自転車の発明になります。

一般に、製品を作成するよりも、製品を購入する方が安くなることがよくあります。 しかし、もちろん、購入したばかりの製品は、既に使用しているソフトウェアとすぐにシームレスに動作するわけではないため、2つの（ほとんどの場合、独自の）アプリケーション間にブリッジを作成する必要があります。 ビジネスの特定の部分用に独自のツールを確実に開発します。すでに購入したこの高価なソフトウェアに適切なモデルがあれば、データベースを使用して、このデータベースのテーブルにデータを追加するだけです...

数年が経ち、十数人の開発者またはチームがこれらのアクションを何度も繰り返しますが、行き止まりになります。購入したソフトウェアの開発者がそれを閉じたり、製品のサポートを停止したり、新しいソフトウェアが使用されたりすると、他のソフトウェアを使用できなくなりますニーズにより適しています。 場合によっては、外部ソフトウェアに技術的に依存することさえあります。 使用するソフトウェアソリューションの作成者が、必要な言語/フレームワーク/その他のバージョンを使用することを望んでいる場合、これはシステムアーキテクチャがあなたのものではないことを意味します。 絶対に必要な機能を提供するために新しいバージョンを販売したいが、このバージョンが技術要件の変更の対象となる場合、他の人の推奨を満たすためにテクノロジースタックをアップグレードする必要があります。 私はそれがどのように感じているかを知っています、そしてあなたはそのような強制された移行が頻繁に起こることを望まないでしょう...

私は、使用した製品の開発者がすべての顧客に新しい機能を追加したくないプロジェクトに取り組みました。なぜなら、彼らが競争力のある変更といくつかの現在のバージョンを維持するのが難しすぎるためです（各クライアントは彼だけに必要な機能を持つ独自のバージョンを持っていました） そこで彼らは、独自の機能を実装できるようにSDKを販売することにしました。 当然、彼らはこれを行う方法に関する十分なドキュメントを提供しませんでした。さらに、ビジネスエンティティを使用することを余儀なくされました。ソースコードもドキュメントもなかったため、構造を理解するために逆コンパイルする必要がありました。最も単純な機能には数日かかりましたが、テストがほとんど不可能でした。すべてが複雑すぎ、すでに複雑な技術スタックを持つチームの誰も知らないスクリプト言語の知識さえ必要だったためです...

複数のアプリケーション間の強力なメッシュ

2000年代初期を思い出してください。エンタープライズJava Bean（EJB）を使用して、情報システム内のアプリケーション間のリモート呼び出しを処理するのはどれほど素晴らしいことでしたか。 当時、これは良いアイデアのように思えたかもしれません。 重複を避けるために他のチームとコードを共有することも良さそうです。 はい、すべてのチームは、バイナリの依存関係が壊れないように同時にアプリケーションを展開することを余儀なくされましたが、楽しい夜でした-アプリケーションが2時間配信されるのを待っている間に同僚とピザを食べましたか？

実は、それほど面白くありませんでした。 そして、あなたのコードで別のクラスをリファクタリングすることは不可能です-単に会社の他の誰かがあなたのコードを気に入っており、テストされていないアプリケーションでそれを使用することに決めたからです-まだ喜びです。

これらの初期の決定がどれほど混乱しているのかを理解すると、アプリケーションを他の世界から分離するために必要な労力は膨大です。 文字通り、プロジェクトをさまざまなコンポーネントにスライスして、他のアプリケーションがサブジェクトエリア、クライアント、またはキャッシュメカニズムのコアを使用できないようにするには数年かかります。 他のプロジェクトとの強力な連携につながる外部クラスへのすべての呼び出しを削除します。 すべてのEJB呼び出しをREST APIに置き換える...しかし、これらのすべての努力に対して、プロジェクトに関連付けられた各従業員は報われる以上のものです。開発とテストが簡素化され、配信プロセスが加速されます。 ; 独自のコード内の概念がより適切に分離されます。 依存関係の管理が簡素化され、クラスパスに他のアプリケーションの依存関係の束をインポートすると、推移的な依存関係の問題がなくなります...これらの費用のかかる変更はすべてチームの命を救うだけであり、プロジェクトの夜明けに実装すれば実装がはるかに簡単になります！

他の人のプロジェクトに基づいてプロジェクトを構築します

ほとんどの場合、この問題は発生しませんが、それでも発生する可能性があります。発生した場合、これは最悪のシナリオです。これは、前述の問題のいくつかを組み合わせているためです。 実は、私はプロとしての最初のプロジェクトの1つで、似たようなものに出会いました。

私がプロジェクトに参加したとき、私は企業システムが完全に書き直されており、プロジェクトは2ヶ月前に始まったばかりだと言われました。 複雑なビジネス機能と他のモジュールを記述するための開発されたフレームワークが既に実装された本格的な管理モジュールを備えた複雑なWebアプリケーションを見たとき、驚きを想像してください。 すぐに、このすべてが私のチームによって作成されたものではないことがわかりました。ゼロから始めないために、グループ内の別の会社が開発したフレームワークを再利用することにしました。 問題は、このフレームワークが開発対象のプロジェクトから分離されていないことでした。 そのため、私たちのチームは、自社のビジネスとは関係のないビジネスロジックを含む、別の会社のプロジェクトのすべてのソースコードを含むアーカイブを受け取りました。 さらに悪いことに、データベーススキーマとデータ自体も継承しました...

チームの新参者が、どのコードがフレームワークに関連しており、それが私たちのプロジェクトを参照しており、どのコードが別の会社のビジネスを参照しているかを理解することは容易ではありませんでした。 チームはこの混乱を解消したかったのですが、これを行うためのいくつかの試みは、コードの部分間の依存関係のために深刻なリグレッションエラーで終わりました（モジュールは1つしかないため、言語はモジュールを呼び出すようになりません！）、そしてもちろん、自動化されたテストはありませんだった。 さらに、システム全体で別の会社が使用する特定のコードがあるため、別のアプリケーションサーバーを使用するという考えを放棄する必要がありました。

ある時点で、フレームワークにいくつかの素晴らしい機能を追加したかったのですが、これはすでに別の会社で行われていると言われました。 そのため、現在のバージョンを別の会社のコードの現在のバージョンとマージするように求められました...チームは、新しい関数に関連するコミットの一部を単純にリダイレクト（チェリーピック）することでこの悪夢を回避しましたが、それと比べてまだ複雑で洗練されていました必要なもの...

私たちはこのプロジェクトを何とか完了しましたが、その品質は本当に苦痛でした。 コードとデータベースの内容の少なくとも40％は未使用のバラストであり、そのデッドコードを削除することは優先事項ではありませんでした。 チームが最終的に独自のコードを分離する機会を得たことを願っています-私は知りません、これが起こる前にチームを去りました！

すべてのビジネスロジックはルール管理システム内に保存されます

ビジネスロジックの一部をルール管理システムに組み込むことは一般的な方法です。 これは、たとえば、ビジネスルールの一部を頻繁に更新する必要があり、モノリシックアプリケーションの配信プロセスにリリース候補を確認する前に長いテストフェーズが必要な場合に便利です。これにより、一部の「揮発性」 「ルール。 私は、サブジェクト領域のすべてのルールがソースコードにあるアプローチを好みますが、状況によってはルール管理システムが役立つことを理解できます。

しかし、ほとんどすべてのビジネスロジックがルール管理システムにあり、ルールがExcelファイルに基づいて生成されるアプリケーションに遭遇しました！ さらに、プロジェクトは概して単純なETLパッケージであるため、ルールは頻繁に変更されることは想定されていませんでした。 これらすべての基盤となったJavaプロジェクトは、サブジェクト領域とは関係なく、バッチ処理フレームワークに関する技術的な詳細と、ソースおよびターゲットシステムからの純粋な読み取りと書き込みのみで構成されていました。

その結果、すべてのルールは、チームの誰も実際にはよく知らない特別な言語で記述されました。これは記述が難しく（IDEがサポートしていなかった）、デバッグとテストが事実上不可能でした。 新しいルールまたは既存のルールへの変更が要求された場合、チームのほとんどの開発者は、特定の1つの変更を除いて、既存のルールをコピーしただけで、完全に同一のファイルになりました（多くの場合、そのような変更はルールが適用されるフィールドのみでした）。

これがすでに問題のように思える場合、ここに何か他のものがあります。どのルールでもその目的について全く手がかりがありませんでした。 ルールは、Rule1、Rule2などのように命名され、合計で100を超えています！ そして基本的に、各ルールは、ドメイン用語のないハードコードされた値のチェックと割り当てで構成されていました。 プロジェクトの名前でさえ、ETL全体の目的を明確にしませんでした。

おわりに

ボブおじさんが著書「Clean Architecture」で説明したように、彼のプロジェクトのアーキテクチャについて考えるとき、選択を本当に必要とするまでいくつかの決定を延期する必要があります。たとえば）。 他の決定は本当に早く行わなければなりません。物事が悪くなるまで待たないでください。 幸いなことに、この種の重要な決定は、「魂のあるアーキテクチャ」と呼ばれるものであるため、簡単に特定できます。そのようなアイデアについて考えると、良いものは見られません。遅かれ早かれ戻ってくる問題だけです。あなたに出没します。 残念ながら、レガシープロジェクトで作業する場合、この種の負担はコードの奥深くに埋もれていることが多く、それを排除するには非常にコストがかかります。

しかし、恐れることはありません。 はい、長年、さらに数十年にわたって蓄積された混乱をクリーンアップすることは簡単な作業ではありませんが、プロのソフトウェア開発者として、このような問題が開発者のモチベーション、顧客の信頼、そして製品に組み込まれた私たちの利益を損なうことを許しません。

もちろん、私が説明したあらゆる種類のアーキテクチャの負担はさまざまな方法で排除できます。これらの問題を解決する特効薬はありません。 ただし、この負担を最終的に取り除くために、どのチームでも何かを思いつくことができると確信しています。 それでは、私たちの問題に一緒に向き合い、物事を整理しましょう！