私は、1日あたり数百万件のトランザクションがある大規模な.netベースの情報システムをサポートする深刻なソフトウェア会社に助言しています。 原則として、彼らとの私の契約は1年から2年です。 この間、私は何とか深く掘り下げることができ、同時に多くの異なる企業と仕事をすることができました。 これにより、ソフトウェア開発プロセスについて興味深い観察と結論を出すことができます。 私は一種のニコライ・ドロズドフです。彼は、自然環境における主要なソフトウェア企業の自然な行動を観察しています。
多くの場合、「ユニバーサルフレームワーク」と呼ばれる興味深いプラクティスがあります。 「プラットフォーム」、「フレームワーク」と呼ぶ企業もあれば、単に「コア」と呼ぶ企業もあります。 しかし、あなたがそれを何と呼んでも、そのような普遍的なプラットフォームの実践は、原則として（常にではありませんが）、あなたの会社の究極の生産性に悪影響を及ぼす悪です。
現象の本質
明確にしたいのは、この記事は、あらゆる企業がさまざまなプロジェクトを実装するために使用するソフトウェア開発のためのユニバーサルプラットフォームに関するものです。 これは、アプリケーションコアとは異なります。
通常、アプリケーションコアは、単一プロジェクト内のアプリケーションレイヤー上のさまざまなモジュールで使用されるビジネスロジックのレイヤーです。 たとえば、SquareHireのコアアプリケーションは、Webサイト、Webアプリケーション、Web管理者、ハンドラー、およびAPIで使用されます。 これらのさまざまなモジュールはすべて、いくつかの一般的なデータとバックエンド機能で動作します。 一緒に、単一のSquareHireプロジェクトを構成するため、共通のアプリケーションコアを割り当てることをお勧めします。
ユニバーサルプラットフォームはまったく異なるものです。 ある企業が、共通のデータとバックエンド機能によって接続されていないプロジェクトをいくつか持っていると想像してください。 おそらく彼らには共通点は何もない。 それでも、同社はソフトウェアアーキテクチャをできるだけ標準化することを望んでいるため、共通の「ユニバーサルプラットフォーム」に基づいて各プロジェクトを実装する決定が下されます。 多くの場合、このようなプラットフォームはAcmeInc.coreなどの会社にちなんで命名されます。 これは、完全に無関係なプロジェクトが共通のアーキテクチャとコードベースを共有するという事実につながります。 私が伝えたいのは、この実践についてです。
これはどうですか？
会社がプロジェクトを正常に完了したと想像してください。 プロジェクトは継続し、会社は成長し、より多くの開発者を採用します。 新しい機会が現れますが、それらは元の設計に完全に不慣れな開発者によって作られています。 特定の問題を解決するコードを簡単に記述します。 そして、このコードは、プロジェクトの元の設計で開発されたパターンに従わず、問題を解決するだけです。 そして、新しいアプローチが古いデザインよりも優れていることもあります。
時間が経ちます。 同社はさらに成功し、プロジェクトのユーザーが増え、プロジェクトを最初に作成した人について何も知らない完全に新しい開発者チームによってサポートされています。 開発者の新しい波はそれぞれ、それらをより良くする方法についてのアイデアに従って新しい機能を実装します。 新機能は設計の矛盾を引き起こし、腫瘍のような元の設計をカバーします。
これはしばらく続きます。 同社は非常に成功しているため、すでにいくつかのプロジェクトを開発しているか、またはそれらのプロジェクトの多くを抱える別のソフトウェア会社に買収されています。 どのように発生しても、会社には多くのプロジェクトがあり、各プロジェクトには独自のチームがあります。 すべてのプロジェクトのアーキテクチャは異なり、新しいプロジェクトチームはそれぞれ独自の方法ですべてを実行するため、それぞれのメンテナンスはますます難しくなっています。
現時点では、誰かが素晴らしいアイデアを思いつきます。「プロジェクトを1桁効率的にする方法を知っています。すべてのプログラムがより良く機能します。 1つの理想的な標準アーキテクチャを開発するだけで十分であり、社内の全員がその基盤に移行できます。 基本的なライブラリのセットを作成し、それらに対して新しいプロジェクトを実行します。
ユニバーサルプラットフォームのアイデア
一見、ユニバーサルプラットフォームのアイデアは理にかなっています。 このような標準的な共通プラットフォームの開発を支持するいくつかの強力な議論があります。 それらのいくつかを次に示します。
1.ゼロからの開発がより速く簡単になります。
新しいプロジェクトは、作業環境にもたらすのがはるかに簡単になります。 彼らにとっては、多くの標準コードを書く必要はなく、必要なものはすべてプラットフォームから取得できます。
2.チームビルディングが簡素化されます
共通のプラットフォームを使用すると、チーム間で開発者を移動しやすくなります。 結局のところ、彼らはすでにアーキテクチャに精通しているでしょう。
3.私たちは、最も強力で経験豊富な専門家によって指導されます
プラットフォームは経験豊富なアーキテクト（または複数のアーキテクト）によって設計されるため、可能な限り最高のアーキテクチャを具現化するとともに、すべての開発者の最高の開発テクニックを実装する義務があります。
おそらく最後の段落で私は皮肉に行き過ぎましたが、そのようなプラットフォームを作成することは本当に紙の上では素晴らしいアイデアのようです。
実際のユニバーサルプラットフォーム
理論的にはすべてがクールに聞こえますが、実際にはすべてがバラ色ではありません。 ユニバーサルプラットフォームの実装のさまざまな段階にあった実際の企業で行った実際の観察結果を共有します。 これらの会社のアーキテクトと開発者は、私がこれまでに働いた中で最もクールな専門家でした。 したがって、問題は明らかに経験やプロ意識の欠如ではなかった。
1.ゼロからの開発がより速く簡単になります。
プラットフォームは、実際に新しいプロジェクトの初期段階の実装を加速できますが、これは長くはかかりません。 開発者は、非常に迅速に、メリットとともに、独自の制限を課していることに気付きます。 まもなく、新しいプロジェクトの開発者は、プロジェクトのニーズに合わせて変更する方法を理解するために、アーキテクトとプラットフォームチームとのミーティングの計画を開始します。 何が起こっているのか理解していますか？ プラットフォームは、新しいプロジェクトに適していないだけでなく、新しいプロジェクトがプラットフォームに影響を与え始めています。 そして、これはそれを使用するすべてのプロジェクトで起こります。 その結果、すべてのプロジェクト間で強い依存関係が得られます。 プロジェクトのある日、プラットフォームバージョンを最新に更新し、プロジェクト全体が壊れていることに気づいたとします。他のチームがトランザクションを管理するより良い方法があると判断したか、DIコンテナまたは他の何かを変更したからです。 提示？
2.チームビルディングが簡素化されます
ある程度までは実際に機能します。 さまざまな企業プロジェクトの構造は似ているため、開発者はプロジェクトを簡単に切り替えることができます。 残念ながら、コインにはマイナス面があります。
最悪の結果は、開発がどこでも等しく遅く複雑になることです。 結局のところ、あるプロジェクトチームによるプラットフォームの変更が他のすべてのチームに影響する場合、プラットフォームはプロジェクト間依存関係を生成します。 また、変更が必要な場合、すぐに変更されないことも意味します。 建築家や他のチームリーダーと合意するまで待つ必要があります。
また、プラットフォームの存在は、会社の新しい開発者を採用するプロセスを複雑にしていることに気付きました。 原則として、プラットフォームの開発に伴い、その複雑さは急激に増大します。 マネージャーから開発者を見つけるのがどれほど難しいかとよく言われますが、それを見つけた後でも、実際の収益が得られるまでに5〜6か月かかります。これは、プロジェクトのアーキテクチャが非常に複雑だからです。 プラットフォームは非常に複雑なはずですか？ いいえ、しかし何らかの理由でこれは常に起こります...
3.私たちは、最も強力で経験豊富な専門家によって指導されます
プラットフォームは、常に会社の最高の開発者によって作成されます。 それはとても良いことですよね ああ、いや。 2つの大きな問題があります。
最初の問題は、異なる動機です。 開発チームがソフトウェア製品のリリースに一緒に取り組むとき、彼らの行動のすべての動機は、この製品をリリースするという1つの目標につながります。 また、製品のリリースが遅れると、誰にとっても共通の問題になります。 しかし、チームから最高の開発者を引き取り、彼らの目標はすべてのプロジェクトを実装するユニバーサルプラットフォームを作成することであると伝えると、彼らの動機は完全に異なります。 特定の製品のリリースはもはや問題ではありません。 現在、彼らはクールなアーキテクチャの作成、ビジネスロジックのモデリングのための新しいテクニックの開発、新しいテクノロジーの研究、他の開発者へのプラットフォームの使用方法の指導などに夢中になっています。 一番下の行は、異なる動機があるということです。
2番目の問題は興味深い現象で、 「スマートガイ病」と呼んでいます。 私はさまざまな企業で何度も彼に会いました。 何らかの理由で、会社に最も大きな損害をもたらす最も致命的なミスは、常に最高の開発者によって行われ、平凡ではないという事実にあります。 興味のある方は、 ここで記事全体を書きました。
おわりに
独自のユニバーサルプラットフォームを作成することは、管理者やアーキテクトにとって「特効薬」のように思えるかもしれません。 しかし、私はあなたに警告しました。 これがモンスターの姿です。 すでに解決されているものよりも多くの問題を解決できるようなプラットフォームを一度も見たことがありません。 しかし、2つのケースでプラットフォームがどのようにして会社を非常に困難な状況に導いたかを見ました。 したがって、その方向に進む前によく考えてください。
そのような代替手段を提供することができます：ユニバーサルソースコードベースを作成します。 ただし、すべての新しいプロジェクトで継承して使用する（プロジェクト間の依存関係につながる）のではなく、毎回フォークするだけです。 この場合、信頼できる出発点になりますが、同時に、会社の他のプロジェクトへの影響を心配することなく、自由に変更を加えることができます。