0

私はソフトウェアプロジェクトを管理する正しい方法について学ぶ方法を探していました、そして私は次のブログ投稿に出くわしました。私は難しい方法で言及されたもののいくつかを学びました、他のものは理にかなっています、そしてそれでも他のものは私にはまだはっきりしていません。

要約すると、著者は、プロジェクトの一連の機能と、それらの機能が、より適切な用語がないためにプロジェクトの「不機嫌」にどの程度貢献しているかをリストします。あなたはここで完全な記事を見つけることができます：http ：//spot.livejournal.com/308370.html

特に、依存関係をプロジェクトにバンドルするという作者のスタンスがわかりません。これらは：

==バンドル==

  • ソースには、[+20ポイントのFAIL]に依存する他のコードプロジェクトのみが付属しています。

    プロジェクトのニーズに合わせてプロジェクトの依存関係を変更したことが、特にポイント3で問題になるのはなぜですか。したがって、コードを依存関係とともに配布する必要があることは、さらに理にかなっていますか？

  • バンドルされたコードビットを最初にビルドせずにソースコードをビルドできない場合[+10ポイントのFAIL]

    これは、サードパーティのライブラリに対して構築されたソフトウェアの場合、必ずしもそうである必要はありませんか？あなたのコードは、リンカーが機能する前に、他のコードをライブラリにコンパイルする必要がありますか？

  • これらの他のバンドルされたコードビットを変更した場合[+40ポイントのFAIL]

    これがプロジェクトに必要な場合は、当然、上記のコードを自分のコードにバンドルしたことになります。WxWidgetsなどのライブラリのビルドをカスタマイズする場合は、そのプロジェクトのビルドスクリプトを編集して、必要なライブラリを構築する必要があります。その後、コードをビルドしたい人にそれらの変更を公開する必要があるので、すでに記述されているパラメーターを使用して高レベルのmakeスクリプトを使用し、それを配布してみませんか？さらに、（特にWindows環境では）コードベースが特定のバージョンのライブラリに依存している場合（プロジェクト用にカスタムコンパイルする必要もあります）、ユーザーに自分でコードを提供する方が簡単ではありません（この場合、ユーザーがすでに正しいバージョンをインストールしている可能性は低いです）？

では、これらのコメントにどのように対応しますか。また、どのような点を考慮に入れていない可能性がありますか。著者の見解（または私の見解）に賛成ですか、反対ですか。その理由は何ですか。

明確にするために編集。

4

1 に答える 1

0

ソースには、依存する他のコードプロジェクトのみが付属しています。

私のプロジェクトにはプロジェクトXが必要です。

ただし、私のプロジェクトはXの秘密の内部ミステリー、またはXの以前のリリースに依存しているため、私のプロジェクトにはXのコピーが含まれています。具体的にはXのnmをリリースします。他にはありません。

最新で最高のXをインストールして、プロジェクトで何が壊れているかを確認してください。Xをアップグレードするとプロジェクトが壊れたので、プロジェクトを忘れてください。更新後に自然に壊れてしまうものに苦労することはありません。彼らはより良いオープンソースコンポーネントを見つけるでしょう。

したがって、FAILスコア。

バンドルされたコードビットを最初にビルドせずにソースコードをビルドできない場合。

私のプロジェクトは、XへのAPIに依存していません。それは、APIをバイパスして、Xの特定の部分への深い内部リンクに依存しています。

私のプロジェクトがXへのAPIに依存している場合、CやC ++などの一部の言語では、プロジェクトはバイナリではなくCまたはC++ヘッダーのみでコンパイルできます。

Javaの場合、独立した非バイナリヘッダーがないため、これはあまり当てはまりません。また、動的言語（Pythonなど）の場合、これは技術的に意味がありません。

ただし、JavaとPythonでさえ、インターフェースを実装から分離する方法があります。（インターフェースではなく）実装に依存している場合でも、同じ本質的な問題が発生しています。

私のプロジェクトがCまたはC++バイナリに依存していて、それらが順不同で物事を構築したり、私のものを再構築せずに別のコンポーネントをアップグレードしたりすると、物事がうまくいかない可能性があります。彼らは奇妙さ、破損、「不安定さ」を見るかもしれません。製品が壊れているようです。彼らはそれをデバッグしません（そしてデバッグできません）。完了しました。彼らはもっと安定したものを見つけるでしょう。

したがって、FAILスコア。

これらの他のバンドルされたコードビットを変更した場合。

Xを変更する場合、2つの選択肢があります。

  1. Xの一部として受け入れられます。

  2. 変更されていないXで動作するようにプログラムを修正します。

私のプロジェクトが変更されたXに依存している場合、誰もXを簡単に、正しく、独立してインストールすることはできません。Xをアップグレードしたり、Xを維持したりすることはできません。おそらく、バグ修正やセキュリティパッチをXに適用することはできません。

Xを変更することで、基本的に彼らの仕事を不可能にしました。

したがって、FAILスコア。

その後、コードをビルドしたい人にそれらの変更を公開する必要があります。

実際、彼らは私を嫌うでしょう。彼らはXへの不思議な変更について知りたくありません。彼らはルールに従ってXを構築し、次にルールに従って私のものを構築したいと思っています。彼らは、ミステリーアップデートパッチキットが正しく適用されていることを読んだり、考えたり、確認したりすることを望んでいません。

それを冗談で言うのではなく、競合するパッケージをダウンロードします。不合格。

コードベースがライブラリの特定のバージョンに依存している場合（プロジェクト用にカスタムコンパイルする必要もあります）

それは本当にぼろぼろです。カスタムコンパイルのあるバージョンに依存している場合は、パッケージの確認が完了しています。彼らは苦労する前に、バージョン固有の内部の謎やカスタムコンパイルのないものを見つけるでしょう。不合格。

于 2010-04-15T21:50:06.490 に答える