組織は一般的なコンポーネントをどのように処理しますか？

Question

共通コンポーネントは、1つのグループによって作成および保守され、多くのグループで使用されるライブラリまたはその他のコードです。

いくつかの問題があります：

• ユーザーはコンポーネントの問題を報告しません。
• ユーザーは、ニーズに合わせてコンポーネントの回避策を作成します。
• これらは、期限を守るためだけにトランクバージョンとの互換性を壊しています。
• ユーザーは、より良いと思うため、独自の（堅牢性の低い）ソリューションをコーディングすることになります。

組織は一般的なコンポーネントをどのように処理しますか？

私が持っているアイデア：

• コンポーネントをオープンソースプロジェクトのように扱い、パッチを提出するようチームに要求します。
• コードへのカスタム変更を完全に禁止します。
• ...

Answer 1

ここにあるのは、技術的な問題ではなく、人的要因の問題かもしれません。実際、これは主に学習の問題である可能性があります（ここで発明されていない典型的なシンドロームと相まって）。

大企業で働いていたので、新しい人が利用できるすべてのリソース（共有コードライブラリなど）を理解するのは難しいことを理解しています。

新規採用時に、共通のコンポーネントライブラリで正式なトレーニングを受けますか？

それから、人々が何に報われるのかという問題があります。レビュー時に、マネージャーは、共通コンポーネントを使用し、それらを改善し、改善をライブラリに送信することで人々に報酬を与えますか？または、マネージャーは単に自分のプロジェクトを気にしますか。

共通ライブラリを管理しているグループについては、時間をかけて改善を提案したり提出したりする人々にどのような形や和解を与えますか？会社のニュースレターに記載されていますか？現金ボーナスを取得しますか？ bullitenボードで写真を入手しますか？

覚えておいてください、人々は認識も報酬も受けない会社のために何かをすることはほとんどありません。

Answer 2

1つのプロジェクトに特定の機能を作成した場合、そのサービスを別のプロジェクトからWebサービスを介して使用できるように、よりサービスベースのシステムに移行しようとしています。この方法では、コードのインスタンスは1つだけです。

当然、これは一部のタイプのコンポーネント（例：最近PDF作成サービスを作成しました）が他のコンポーネントよりも適切に機能します（おそらく、文字列操作ユーティリティが多すぎる）。

Answer 3

ここで見た成功した唯一のコンポーネントは、コンパイル済みバージョン（* .dll）で再配布されています。ユーザーは所有チームにバグを報告し、機能を直接要求し、自分で実装します。変更する可能性が最も高いもののために独自のプラグインを作成するためのAPIがあるため、多くの場合、人々は機能を拡張できます。

常にトレードオフがあります

• コンポーネントを使用するように人々を説得する
• 同時に適切なレベルの品質を維持

あなたのケースで何が最善かわからないが、一般的には自分でコアロジックを実装し、コンポーネントを常に構成可能/拡張可能にして、人々が常にコアを変更してサポートを提供する必要がないようにする。何らかの理由で、一部の開発者は常にホイールを再発明する傾向があります。そのため、あまり心配する必要はありません。

Answer 4

良い方法は、定期的なコードレビューを実施することです。これらの間に、車輪が再発明された場合、その機会を利用して開発者を教育し、共通のコンポーネントを使用するか、なぜ再発明する必要性を感じたのか、元のコードの論理を結び付けることができます。このようにして、すべての人の要件が満たされ、コンポーネントがすべての人のために改善されます。

Answer 5

サードパーティのライブラリと同じ方法でそれらを扱います。私は他のチームにソースを見せることさえしません-そうすることは多くの時間を浪費する批判とバックバイトにつながる可能性があります。

Answer 6

組織の大きさは？このようなものは、1人または2人の個人が各コンポーネントの所有権を持ち、機能要求に応答することが知られている小さな組織（合計数十人のプログラマー）で非常にうまく処理されているのを見てきました。

誰かのオフィスに行け（または郵送して）、必要なものを説明し、次のいずれかを取得する方が簡単です。

• あなたが望むことをするための期待される方法
• 必要な機能を追加する（または追加するようにミニオンに指示する）同意
• 共通コンポーネントに必要な機能を実装する許可、

回避策の記述、フォークの開始、または同等の新しいコンポーネントの記述に着手するだけではありません。あなたのプログラマーが賢いなら、彼らは彼らが最も簡単だと思うことをするでしょう。秘Theは、これが正しいことを確認することです。

リンクされたリストのような本当にシンプルなものは別として、進行中の車輪の再発明はそれほど多くありませんでした。ごくまれに、特定の製品用のプライベートフォークがありました。最も一般的には、物を切り刻んでコードサイズを削減するためです。しかし、それを行う通常の方法は、元のコンポーネントを変更して、ビルドオプションを増やすことでした。