開発者は実際のプログラムの前に内部ライブラリをコンパイルすることを期待されるべきですか？
最近、私が一緒に仕事をしている上級開発者が、開発者に最新バージョンを入手して、プロジェクトの一部として主要な内部ライブラリとしてコンパイルすることを要求することを主張しました。これは、プロジェクトチームが内部のMavenリポジトリから取得した安定版を使用して作業する必要があるという反論とは対照的です。開発者は、開発者のマシンでソースコードを利用できるようにすると、ライブラリのソースを読み取ることができるので時間を節約できると主張しました。必要な機能が利用可能かどうかを判断するコード。
上級開発者には有効な議論がありますか？または、開発者にライブラリのソースコードを読むことを要求しているのは、カプセル化の基本的な哲学に反しており、そもそもライブラリを持っていることさえありますか？
この上級開発者の議論は私には意味がありません。
開発者がたまにソースコードを読み取れるように、内部ライブラリを常に取得してコンパイルするオーバーヘッドを追加したいと考えていますか？これは、開発者が機能が利用可能かどうかを確認する必要がある場合にのみソースコードを確認するよりも、はるかに多くの時間を浪費することになります。
ライブラリとクライアントが異なる開発グループによって開発されており、ライブラリが積極的に開発されている場合、これは特に悪い考えです。クライアント開発者は、ライブラリの不安定性から隔離されることはありません。
開発者が通常のビルドの一部にすることを強制せずにソースコードを利用できるようにすることができない理由がわかりません。
提案は
クライアント側の開発者がライブラリのソースコードを読んで、必要な機能が利用可能かどうかを判断することで、時間を節約できます。
あなたは別の提案をすることができます
ライブラリをドキュメント化して、使用可能な機能を示すことで時間を節約できます。
ソースをローカルで閲覧できることはメリットであるという議論は買いませんが、ライブラリが活発に開発されている場合（プロジェクトのニーズのサポートを追加する可能性がある場合）、開発者に次のことを要求するのは不合理ではないと思います。更新を頻繁にダウンロードする（おそらく1日に数回）。ただし、開発者がソースからコンパイルする必要があるのではなく、コンパイルされた（および単体テストされた）バイナリを利用できるようにする方がビジネス上理にかなっていると思います。
プロジェクト内で、最新のコンパイル済みバージョンが利用できるような共有リポジトリをセットアップする機能はありますか？理想的には、スケジュールに従ってフェッチとビルドを実行するCIサーバーが必要ですが、チームリーダーの1人が定期的に更新する責任があるのが単なるネットワークリソースであっても、役立つ場合があります。もちろん、これは図書館チームのプレートにあるはずですが、明らかに彼らは興味がないので、あなたは彼らのたるみを拾う必要があります。
私は以前、自社のソフトウェアを社内のビジネスシステムで常に「ドッグフーディング」していた大規模なソフトウェア会社で働いていました。
彼らはこれを別のレベルのテストと見なしました。
会社にとって私が同意することは良いことです。
最新バージョンをダウンロードしてコンパイルすることを強制するのは、一歩遠すぎると思います。ただしコンパイルのステップは、ライブラリの販売またはアウトソーシングを提供する企業の重要な部分です。
ソースコードを利用できるようにすることは利点ですが、リポジトリを監視するCIビルドエージェントがある場合は、開発者に要求するよりも、そのエージェントにこのライブラリをコンパイルして依存プロジェクトに外部としてコピーさせる方がはるかに理にかなっています。コピーを作成するときに、2つの異なるコンパイル手順を実行します。
私は現在、ビルドエージェントに接続されていないプロジェクトに取り組んでいます。そのため、メインアプリケーションをビルドする前にサブアプリケーションをビルドする必要があります。それは私の後部の深刻な痛みです。サブアプリに変更を加えるには、まずプロジェクト全体をビルドしてから、サブビルドフォルダーに移動し、コンパイルされた製品をそこから取得して別のサブフォルダーにコピーしてから、プロジェクト全体をビルドします。サブアプリの最新バージョンがメインアプリのビルドに含まれていることを確認します。これはそれが行われるべき方法ではありません。少なくとも、このプロセスを自動化するMSBuildスクリプトが必要です。新しいコードがトランクにコミットされるたびに、ビルドエージェントが外部を更新することをお勧めします。
この種のテストは確かに行われたほうがよいでしょう。ただし、開発者ではなく、テスターが実行する必要があります。その意味で、それはあなたの仕事でもライブラリ開発者の仕事でもありません。
あなたの説明からすると、プロジェクトにはテスターがいないように思えます。この場合、それは管理上の問題であり、非常に深刻な問題です。
...必要な機能が利用可能かどうかを判断するためにライブラリのソースコードを読み取ることができるため、時間を節約できます
かなり不十分な推論。最新バージョンのライブラリが最新バージョンのプロジェクトでコンパイルできない場合、さまざまな理由が考えられます。libソースコードをドリルダウンするだけでは、時間の無駄になります。
- ライブラリに問題がなく、プロジェクトコードのバグが原因でビルドが失敗した場合はどうなりますか？または、ビルドの失敗が、1日か2日後に修正されるはずの一時的な互換性のない変更によって引き起こされた場合はどうなりますか？ビルドの失敗が、対処するのに1週間または1か月かかる複雑な統合の問題を示している場合はどうなりますか？統合の問題について、以前のバージョンのライブラリを使用すると回避策が生じるかどうか。
理由が何であれ、障害の予備分析を行うことは、テスターによって行われることになっている作業に開発者の時間を浪費することを意味します。
推論ミスの上のもう1つのことは、開発とQAアクティビティを切り替えることでフローを break しなければならないときに発生する生産性の損失は避けられない（そして私の経験ではかなり痛い）です。
チームにテスターがいる場合、そのようなことは本当に簡単で、はるかに簡単に処理できます。あなたの「上級」開発者があなたに投げかけたのは、基本的にドラフトテストの要件です。
プロジェクトまたはライブラリに変更を加えるたびに、ビルドが成功することを確認してください。
そこから進むための手順は、典型的なQAアクティビティです。要件の詳細を明確にし、正式なテストシナリオを設計し、テストの失敗を処理する方法について交渉します。
- [〜＃〜] sqa [〜＃〜] の観点から、これは非常に単純な regression Testing の設計、設定、および保守のかなり日常的なタスクです高度に自動化できる手順-おそらく、手動アクティビティのみが issue tracker でチケットを作成および維持し、修正を検証するまでです。
多くの人々が、誰もが内部ライブラリを構築するのは意味がないと答えたので、私は理由を正当化できる反対の視点を提示します：
ライブラリを頻繁に使用し、ドキュメントはありません。したがって、誰もが参照用のソースを持っている必要があります。これが非常に頻繁に使用されるライブラリである場合は、リファレンスを手元に用意しておくと便利です。
- 確かに、彼らはドキュメントに取り組むべきだと言うでしょう、そしておそらくあなたの上級開発者はこの事実を知っています。しかし、現実に直面してみましょう。多くの場合、開発チームは文書化されていない大量のコードを作成することになるため、その機能を知る必要がある場合は、ソースにアクセスします。あなたはそれをする必要はありませんが、短期的には、これが最良の代替手段です。
- 通常、ドキュメントを配置するのに最適な人は、ライブラリを最もよく知っている人です。残念ながら、それらは通常最も忙しいのと同じ人々であるため、すべてを削除して文書化を開始するのはそれほど簡単ではないことがよくあります。
人々がライブラリに依存する独自のコードを書き始め、ライブラリ内の何かが機能しない場合、腕を宙に投げるのではなく、ライブラリがローカルで構築されている場合、ライブラリコード内に直接入ることが非常に簡単になります
- これは、多くのライブラリーが完全とはほど遠いために発生する可能性があり、「安定した」リリースで作業したいが、まだ問題がある可能性があります。
- APIの使い方を誤解しているために、結果が良くないのかもしれません。ドキュメントがあっても、人々はしばしば間違った仮定をします
- あなたの先輩はおそらく新しい人にうんざりしているでしょう（そして時にはプロジェクトの内外を知っている人よりもはるかに多くの新しい人がいます）クラッシュ/他のエラーがライブラリコードから来ているように見えるときはいつでも彼らの腕を空中に投げます。だから、あなたのマシンに来て、あなたの隣に座っている人に来る代わりに、彼らはこれらの質問に答えるオプションを望んでいます：1）クラッシュは正確にどこにありますか？どのモジュール/ファイル/行？ 2）デバッグしましたか？あなたは何を見つけましたか？
- あなたの先輩たちはこのコードベース（アプリケーションとあなたの主要なライブラリ）で十分長い間働いていました、そして潜在的に彼はコードがすでにマシン上にあり、デバッグとステップスルーの準備ができているとき、それは彼の人生を楽にしそして人々を得ることに気づいたかもしれませんコードベースをより速く学ぶため。そのため、彼はあなたのマシンでライブラリを構築するための先行費用をあなたに強いることを強制します。
私は彼の決定が正当化されると言っているのではなく、a）質問が物語の片側を提示し、b）もっともらしい動機がある可能性があることを指摘しているだけです。
Sr Devが示唆していることは、私にはほとんど意味がありません。ソースを閲覧できるのは素晴らしいことですが、そうするためのより良い方法があります。
どのアーティファクトリポジトリを使用していますか？各バージョンのソースjarをデプロイして、コンパイル済みライブラリの隣に置くことができるはずです。ほとんどのIDEでは、これをコンパイル済みライブラリに添付してソースを参照できます。 Mavenプラグインを備えたEclipseはこれを自動的に行います。
最新のコードが必要な場合は、バージョンスナップショットをデプロイするだけです。
これは、ビルドスクリプトで発生するだけです。
- 新しいバージョンが利用可能かどうかを確認します。それ以外の場合は2をスキップします。
- ダウンロードしてコンパイルし、ローカルでソースコードからAPIリファレンスを生成するために必要なツールを実行します。変更ログを表示します。
- アプリを作成する
これがなぜ、どのように問題であるのかわかりません。また、参照に何かが欠けている場合は、それをソースに追加して変更をプッシュできます。もちろん、図書館が足元で変わるのは少し怖いように思えるかもしれませんが、図書館のメンテナが適切に仕事をしていれば、これは良いことです。