最近、私が一緒に仕事をしている上級開発者が、開発者に最新バージョンを入手し、プロジェクトの一部として主要な内部ライブラリをコンパイルするよう要求することを主張しました。これは、プロジェクトチームが内部のMavenリポジトリから取得する安定したバージョンを使用して作業する必要があるという反論とは対照的です。開発者は、ソースコードを開発者のマシンで利用できるようにすると、ライブラリのソースを読み取ることができるので時間を節約できると主張しました。必要な機能が利用可能かどうかを判断するコード。
上級開発者には有効な議論がありますか？それとも、開発者に、ライブラリのソースコードを読み取って、カプセル化の基本的な哲学に対抗し、そもそもライブラリを用意するように要求するのでしょうか。
回答:
この上級開発者の議論は私には意味がありません。
開発者が時々ソースコードを読むことができるように、内部ライブラリを常に取得してコンパイルするオーバーヘッドを追加したいですか？これは、開発者が機能が利用可能かどうかを確認する必要がある場合にのみソースコードを確認するよりも多くの時間を浪費します。
ライブラリとクライアントが異なる開発グループによって開発されており、ライブラリが積極的に開発されている場合、これは特に悪い考えです。クライアントの開発者は、ライブラリの不安定さから絶縁されません。
開発者が通常のビルドの一部になるように強制せずにソースコードを利用できないようにする理由がわかりません。
提案は
クライアント側の開発者がライブラリのソースコードを読んで、必要な機能が利用可能かどうかを判断することで、時間を節約できます。
別の提案をすることができます
ライブラリをドキュメント化して、使用可能な機能を示すことで、時間を節約できます。
ソースをローカルで熟読できることは利点だという主張は買えませんが、ライブラリが活発に開発されている場合（おそらくプロジェクトのニーズに対応するため）、開発者に次のことを要求するのは無理はないと思います更新を頻繁にダウンロードする（おそらく1日に数回）。ただし、開発者にソースからのコンパイルを要求する代わりに、コンパイル済み（および単体テスト済み）のバイナリを使用可能にするほうが、ビジネス上意味があると思います。
プロジェクト内で、最新のコンパイル済みバージョンが利用できるような共有リポジトリをセットアップする機能はありますか？理想的には、フェッチとビルドをスケジュールどおりに実行したCIサーバーが必要ですが、チームの1人がリードするネットワークリソースだけが定期的に更新を担当している場合でも、役立つ場合があります。もちろん、これは図書館チームの側にあるべきですが、明らかに彼らは興味がないので、あなたは彼らのたるみを拾う必要があります。
ソースコードを利用できるようにすることはメリットですが、CIビルドエージェントがリポジトリを監視している場合、開発者にこのライブラリをコンパイルして依存関係のあるプロジェクトに外部にコピーさせる方が、開発者に要求するよりも意味があります。コピーをビルドするときに、2つの異なるコンパイル手順を実行します。
現在、ビルドエージェントに接続されていないプロジェクトに取り組んでいます。そのため、メインアプリケーションをビルドする前にサブアプリケーションをビルドする必要があります。それは私の後部の深刻な痛みです。サブアプリに変更を加えるには、まずプロジェクト全体をビルドしてから、サブビルドフォルダーに移動し、コンパイルされた製品をそこから取得して別のサブフォルダーにコピーしてから、プロジェクト全体をビルドします。サブアプリの最新バージョンがメインアプリのビルドに含まれていることを確認します。これはどのように行われるべきかではありません。少なくとも、このプロセスを自動化するMSBuildスクリプトが必要です。新しいコードがトランクにコミットされるたびに、ビルドエージェントが外部を更新することをお勧めします。
多くの人々が、誰もが内部ライブラリを構築するのは意味がないと答えたので、私は理由を正当化できる反対の視点を提示します。
ライブラリを頻繁に使用し、ドキュメントはありません。だから誰もが参照のためのソースを持っている必要があります。これが非常に頻繁に使用されるライブラリである場合、参照が手元にあると便利です
人々がライブラリに依存する独自のコードを書き始め、ライブラリ内の何かが機能しない場合、腕を宙に投げるのではなく、ライブラリがローカルで構築されている場合、ライブラリコード内に直接入ることが非常に簡単になります
彼の決定が正当であると言っているのではなく、a）質問が物語の一方の側に提示され、b）もっともらしい動機があり得ることを指摘しているだけです。
この種のテストは実際に行われる方がよいでしょう。ただし、開発者ではなくテスターが行う必要があります。その意味で、それはあなたやライブラリの開発者の仕事ではありません。
あなたの説明から、プロジェクトにはテスターがいないようです-これが事実である場合、それは管理上の問題であり、非常に深刻な問題です。
...ライブラリのソースコードを読み取って、必要な機能が利用可能かどうかを判断できるため、時間を節約できます
かなり不十分な推論。最新バージョンのライブラリが最新バージョンのプロジェクトでコンパイルできない場合、さまざまな理由が考えられます。libソースコードをドリルダウンするだけでは、時間の無駄になります。
開発ミスとQAアクティビティを切り替えることでフローを断ち切らなければならない場合に続く、生産性の損失は避けられない（そして私の経験ではかなり痛い）です。
チームにテスターがいる場合、そのようなことは非常に簡単で、はるかに簡単に処理できます。「上級」開発者があなたに投げかけるのは、基本的にはドラフトテスト要件です。
プロジェクトまたはライブラリに変更を加えるたびに、ビルドが成功することを確認してください。
そこから先に進む手順には、一般的なQAアクティビティがあります。要件の詳細を明確にし、正式なテストシナリオを設計し、テストの失敗を処理する方法について交渉します。
Sr Devが提案していることは、私にはほとんど意味がありません。ソースを閲覧できるのは良いことですが、もっと良い方法があります。
どのアーティファクトリポジトリを使用していますか？各バージョンのソースjarをデプロイして、コンパイル済みライブラリの隣に置くことができるはずです。ほとんどのIDEでは、ソースの参照用にこれをコンパイル済みライブラリに添付できます。Mavenプラグインを備えたEclipseは、これを自動的に行います。
最新のコードが必要な場合は、バージョンのスナップショットをデプロイするだけです。
これは単にビルドスクリプトで発生するはずです。
これがなぜ、どのように問題であるのかわかりません。また、参照に不足しているものがある場合は、それをソースに追加して変更をプッシュできます。もちろん、ライブラリがあなたの足元で変わることが少し怖いように見えるかもしれませんが、ライブラリのメンテナが適切に仕事をしていれば、これは良いことです。