15

数年前、コードの再利用に関する研究について聞いたことがあります。どうやら、プログラマーが再利用するコードを探す時間は平均で 7 分であることがわかったようです。そのウィンドウ内でニーズに合ったコードが見つからない場合は、独自のコードを作成します。

これは、ウィンドウ内で必要なものを確実に見つけられるように、再利用のためにコードを慎重に管理する必要があるという文脈で提示されました。

あなた (個人および組織) は、ソースを再利用しやすくするためにどのように管理していますか? 特に再利用ライブラリを維持していますか? もしそうなら、ヒット率を最大化するためにどのようにインデックスを付けますか?

4

7 に答える 7

10

複雑な質問:

  • コードの一部は、ライブラリまたは API として一般化できます。一般的な問題の解決策を最新の状態に保つ共通のライブラリがあります。通常: 検証、キャッシング、データ アクセス クラス、ロギングなど...

  • 一部の部分はアプリケーション固有です。簡単に一般化することはできません。それらをハウツーに変換し、社内プレゼンテーションを行います。コードは、簡単にブラウズできる SCM (この場合は SVN) を使用して再利用されます。

  • また、一方ではリサイクルできないコードを生成するツールもありますが、他方では常に似ています (ストアド プロシージャの呼び出しを考えてみてください)。

  • ペア プログラミングは、既存のソリューションの知識を広める有効な方法でもあります。可能または適切な場合に使用します。

  • 最後のテクニックは授業料です。各コーダーには、参照する家庭教師がいます。チューターは少数であるため、彼らの間で多くの情報が共有され、この知識はトップダウン方式で拡散されます。

于 2008-09-28T11:58:43.963 に答える
4

容赦なくリファクタリングし、最善を尽くしてください。

更新(4年後、うまくいけば賢明)

  • S.Lott のコメントのように: ネーミングに注意してください。チーム内のすべての「コミッター」にこの言葉を広めてください。良い名前は物事を検索可能にし、重複を減らします。
  • 何かを行うための 1 つの方法を用意し、アクセス可能で検索可能にします。
  • 平均的な (LCD) プログラマー向けのコードを書きます。(これには、デザインパターンの靴べらの強迫行為および関連する障害が含まれます)
  • 規則、スタイル、ガイドライン、標準などの共通セットを早期に採用します。チーム内で賛同を得て、コンプライアンスを確保します。(これは、誰もがタブ (またはスペース) を使用することを意味します!)。何を選択してもかまいません - 目標は、コードが一貫して見えることです
  • ゲートキーパー (チームから尊敬されている) を配置し、すべてのチェックインで赤旗を監視します。
  • テストファースト/アウトサイドインでコードを書く。これにより、通常、コードが複数のクライアントで使用できるようになります。(コンテキスト独立性に関するGOOSの箇条書きを参照)
于 2008-09-28T12:00:51.557 に答える
2
  • 積極的にサポートされているフレームワークを用意してください。

  • 既存のコード ベースを知る / 他の開発者にコード ベースを知ってもらう。グループ/会社が十分に大きい場合は、コードベースを知っていて、ガイダンスを求めることができる誰かを用意してください.

  • ドキュメント、ドキュメント、ドキュメント。ドキュメント化されていないコードは、内部の仕組みを理解するのに時間がかかりすぎるため、再利用しても役に立ちません。

  • 良いインターフェースを持ってください。簡単な型、簡単な構造またはクラス。何かが複雑になればなるほど、別のプロジェクトで使用されることは少なくなります。

  • 再利用可能なコードを最適化してデバッグします。他の人のコードで n 回目のバグを経験した開発者は、既存のコードを新たにコーディングし始めます。

于 2008-09-28T12:02:59.197 に答える
1

組織が鍵です。名前空間とインテリセンスが利用できる場合、適切な機能を絞り込み、最終的に見つけることができます。欲しいものが正確に見つからない場合でも、近いものや関連するものを見つけることがあります。1 つの巨大なグループにまとめられたコードは簡単に見つけることができますが、必要なメソッドを十分に速く見つけることはできません。

命名と場所の両方で、一貫性も重要です。プロジェクトのある時点でスタイルを変更することにした場合は、戻ってそのスタイルに合うようにすべてを変更します。これは非常に長く退屈なプロセスになる可能性がありますが、一貫性のないライブラリを使用しなければならないよりはましです。

于 2008-09-28T12:11:39.220 に答える
1

まだ私の最初の応答ではない場合は、TDDを使用してみてください。

TDD の使用は、他の利点の中でも、コードの結合を低く抑える優れた方法だと思います。本質的に、同じ動作が 2 回実装されるのを防ぐことはできませんが、重複を削除できる領域を特定すると、非常に簡単になります。

もう 1 つの利点として、TDD にはサイクルの一部として重複を除去するためのステップ (リファクタリング) があります。

また、テストはコード ドキュメントの一部を形成するため、重複した動作を簡単に特定できます。

于 2008-09-28T12:02:43.003 に答える
1

アプリケーション全体をプロファイリングし、コードの重いセクションからリファクタリングを開始します。(最も使用されているコードの 20% に 80% の時間が費やされている)

メモリ リーク、繰り返しの呼び出し、長い呼び出し、解放されていないメモリ、未処理のリソースなどを特定する機能を備えたプロファイリング ツールを使用します。

原則として、新しいコードは常にベスト プラクティスを使用します。

于 2011-09-17T01:11:00.813 に答える