あなたの問題は非常に一般的なものです。良い解決策がないため、実際の問題もあります。
私たちはここでも同じ状況にあります。さらに悪いことに、1,300 万行のコード、売上高、800 人を超える開発者がコードに取り組んでいます。私たちは、あなたが説明したのとまったく同じ問題についてよく話し合います。
最初のアイデア (開発者が既に使用している) は、いくつかのユーティリティ クラスで共通コードをリファクタリングすることです。ペアプログラミング、メンタリング、ディスカッションを行ったとしても、そのソリューションの問題は、これが効果的であるには人数が多すぎるということです. 実際、私たちはサブチームで成長し、人々はサブチームで知識を共有していますが、知識はサブチーム間を移動しません。間違っているかもしれませんが、この場合はペアプログラミングやトークでも役に立たないと思います。
建築チームもあります。このチームは、設計とアーキテクチャの問題に対処し、必要になる可能性のある共通ユーティリティを作成する責任があります。このチームは実際、企業のフレームワークと呼べるものを生み出しています。はい、これはフレームワークであり、うまく機能する場合もあります。このチームは、ベスト プラクティスを推進し、何をすべきか、何をすべきか、何が利用可能で何が不可能かについての認識を高める責任もあります。
優れたコア Java API 設計は、Java の成功の理由の 1 つです。優れたサードパーティのオープン ソース ライブラリも重要です。巧妙に作成された小さな API でさえ、非常に有用な抽象化を提供し、コード サイズを大幅に削減することができます。しかし、フレームワークとパブリック API を作成することは、ユーティリティ クラスを 2 時間でコーディングすることとはまったく同じではありません。それは本当に高いコストを持っています。ユーティリティ クラスの費用は、最初のコーディングに 2 時間、デバッグと単体テストに 2 日ほどかかります。大規模なプロジェクトやチームで共通のコードを共有し始めると、実際に API が作成されます。その場合、完全なドキュメント、つまり本当に読みやすく保守可能なコードを確保する必要があります。このコードの新しいバージョンをリリースするときは、下位互換性を維持する必要があります。会社全体（または少なくともチーム全体）で宣伝する必要があります。小規模なユーティリティ クラスの場合は 2 日から 10 日になり、
そして、あなたの API 設計はそれほど素晴らしいものではないかもしれません。エンジニアが賢くないというわけではありません。しかし、UI の一貫した方法で数値を解析するだけの小さなユーティリティ クラスで 50 日間作業させてもよろしいですか? まったく異なるニーズを持つモバイル UI を使い始めるとき、彼らに全体を再設計してもらいますか? また、世界で最も優秀なエンジニアが、決して普及しないか、ゆっくりと衰退する API をどのように作成しているのかに気付きましたか? ご覧のとおり、私たちが作成した最初の Web プロジェクトでは、内部フレームワークのみを使用するか、フレームワークをまったく使用しませんでした。次に、PHP/JSP/ASP を追加しました。次に、Java に Struts を追加しました。現在は JSF が標準です。そして、Spring Web Flow、Vaadin、Lift を使用することを考えています...
私が言いたいのは、良い解決策がないということだけです。オーバーヘッドは、コードのサイズとチームのサイズに応じて指数関数的に増加します。大きなコードベースを共有すると、俊敏性と応答性が制限されます。あらゆる変更は慎重に行う必要があり、潜在的な統合の問題をすべて考慮し、全員が新しい特異性と機能についてトレーニングを受ける必要があります。
しかし、ソフトウェア会社の主な生産性ポイントは、XML を解析するときに 10 行または 50 行のコードを取得しないことです。これを行うための一般的なコードは、何千行ものコードになり、ユーティリティ クラスによって階層化される複雑な API を再作成します。男が XML を解析するためのユーティリティ クラスを作成する場合、それは優れた抽象化です。彼は、10 行または 100 行の特殊なコードに名前を付けます。このコードは特殊化されているため便利です。共通 API を使用すると、ストリーム、URL、文字列などを処理できます。ファクトリがあるため、パーサーの実装を選択できます。ユーティリティ クラスは、このパーサーと文字列でのみ機能するため、優れています。そして、それを呼び出すには 1 行のコードが必要だからです。しかしもちろん、このユーティリティ コードの用途は限られています。これは、このモバイル アプリケーションや XML 構成の読み込みに適しています。そしてそれは'
結論として、コードベース全体のコードを統合しようとする代わりに、チームの成長に合わせてコードの責任を分割することを検討します。
- 1 つの大きなプロジェクトに取り組む大きなチームを、複数のサブプロジェクトに取り組む小さなチームに変えます。
- 統合の問題を最小限に抑えるためにインターフェイスが適切であることを確認しますが、チームには独自のコードを持たせます。
- これらのチームと対応するコードベース内で、ベスト プラクティスがあることを確認してください。重複コードなし、優れた抽象化。コミュニティからの既存の実績のある API を使用します。ペア プログラミング、強力な API ドキュメント、Wiki を使用してください。ただし、チーム間でコードが重複したり、設計上の決定が異なる場合でも、実際にはさまざまなチームに選択を任せ、独自のコードを作成する必要があります。設計上の決定が異なる場合は、ニーズが異なることが原因である可能性があります。
あなたが本当に管理しているのは複雑さです。最終的に、非常に一般的で高度なモノリシックなコードベースを作成すると、新規参入者が立ち上がる時間が長くなり、開発者が共通のコードをまったく使用しないリスクが高まり、すべての変更が原因で全員の速度が低下します。既存の機能を壊す可能性がはるかに高くなります。