コストの目安とコードの再利用の節約
いつかどこかでそれを再利用する目的でコードを常に書くことは良い経験則ですか？または、作成しているコンポーネントのサイズに応じて、費やした時間に関して意味がある場合は、再利用できるように設計することをお勧めします。この部分を必要とする可能性がある、または必要とする可能性のある他のもののために後で必要になる可能性がある「ある程度の確率」を持つプロジェクトコンポーネントの分析と設計に余分な時間を費やすための良い経験則は何ですか。
たとえば、プロジェクトXでA、およびBを実行する必要がある場合などです。 Aは、再利用するために作成する必要があります。 Bは現時点ではプロジェクト固有のものであり、数日でまとめてハックしてプロジェクトを予定どおりに完了し、全員が素晴らしいチームであることを称賛することもできます。どのプロジェクトY/Zがこのことを必要とするかもしれないかを把握する週は、いつかプロジェクトY/Z（節約が実現されるところ）でそれを使用する必要があるかもしれないので、Bに多くの時間を費やします。
完璧な世界の状況は、プロジェクト固有の設計されたコンポーネントと再利用されたプロジェクトに基づいて設計されたコンポーネントの巧妙に組み合わせられたものになると思います。ただし、一部のコードショップでは、将来のある時点でそれを使用するためにすべてを記述することをお勧めします。
必須 XKCD＃974 ：
私の経験では、常にすべてを再利用可能にしようとすると、過剰なエンジニアリングにつながる可能性があります。
ただし、再利用可能なコンポーネントは汎用的なコンポーネントであるため、そのインターフェイスが抽象化されているため、物事を再利用可能にするためにある程度の努力を払わなくてはなりません（再利用が可能である場合）。つまり、それだけで理解し、それがどのように機能するのか、なぜ機能するのか、何をしてどのように機能するのか、単独で見たとき、または見たときの方がわかりやすい6数か月後、あなたはそれを書いたことさえ覚えていません。もちろん、これらの利点は、再利用可能であるという事実に加えてです。
したがって、長い話を簡単に言うと、経験則は次のとおりであると思います。
インターフェースや実装がわかりやすくなる場合は、再利用可能にします。
この部分を必要とする可能性がある、または必要とする可能性のある他のもののために後で必要になる可能性がある「ある程度の確率」を持つプロジェクトコンポーネントの分析と設計に余分な時間を費やすための良い経験則は何ですか。
上記のような場合、私の好みは私の過去のプロジェクトの1つで得られた見積もりに基づいています：再利用可能なコードは、3〜4倍の労力で書き込みます （YMMV）。
- もう1つ気づいたのは、使用例が1つしかない場合、再利用できるようにコードを適切に設計するのが非常に難しいことです。つまり、「念のため」を設計するときに、その例がなくても、実際の再利用が必要になったときに後で再設計しなければならないことがよくありますが発生します。
上記のように、私はそれについての実際のケースがあるまで再利用のための設計を避ける傾向があります。その意味で、私はかなり強く [〜＃〜] yagni [〜＃〜] に従います。一方、再利用のケースが少なくとも1つある場合は、コードを複製するのではなく、そのために再設計することを試みます。ただし、努力の単純な計算がまだ行われている場合でも複製を支持する（2倍の労力vs 3-4倍）-この設定は、今後のメンテナンスの考慮事項と関係があると思います。
たとえば、プロジェクト
XでA、およびBを実行する必要がある場合などです。Aは、再利用するために作成する必要があります。Bは現時点ではプロジェクト固有のものであり、数日でまとめてハックしてプロジェクトを予定どおりに完了し、全員が素晴らしいチームであることを称賛することもできます。どのプロジェクトY/Zがこのことを必要とするかもしれないかを把握する週は、いつかプロジェクトY/Z（節約が実現されるところ）でそれを使用する必要があるかもしれないので、Bに多くの時間を費やします。
上記のような場合、私は個人的にBをすばやくハッキングします。
私が不快に感じる唯一のことは、この決定の痕跡が残っていないことです（問題の内容、検討されたオプション、決定の内容と理由など）。しかし、これは本当に扱いやすいです-私はそのような決定で定期的にそれを行います：ちょうどあなたの issue tracker にそれを登録し、物事を説明し、時間がそれを世話することができるまでそこに置いてください。または、他のプロジェクトを準備する時間までY/Z-見積もりにfriggin '2週間を含めることができるとき。
- Issue 1234- throwaway code inthing
B-fix延期-努力の見積もりは2週間
ベストプラクティスは、再利用の目的に関係なく、きちんと理解できるコードを記述することです。優れた記述コードは、常に将来の場所を見つけることができます。再利用に適した方法でコードを具体的に記述する必要はありません。必要なことは、優れた設計原則と自己文書化されたコードを少し実行することだけです。これにより、コードが再利用可能になります。
あなたがすでに指摘したように、それはバランスをとるために降りてくるのです。科学/経済学の用語では、再利用可能なコードとアプリ固有のハックの両方の決定を評価し、それぞれのコストと利点を合計し、確率値（たとえば、コードが実際に実行される可能性）も考慮します。他の場所で必要になる）。実際には、これらの計算はほぼ無意識に（常識、経験、直感などを使用して）行われます。
技術的には、私たちのデザインは常にモジュール式であり、可能な限り再利用可能である必要がありますが、「ハッキング」を行うと、一般的なコンポーネントと一般的なコンポーネントを1週間で書くのに半日かかる場合がたくさんあります。その場合、私は YAGNI原則 のスタンスをとります。
一方、a）コードが再度必要になる可能性が80〜90％であることがわかっていて、それが理にかなっている場合、およびb）再利用可能にするのにそれほど時間がかからない場合は、先に進んで設計すると言います再利用可能性のために...そして他のすべてのために中央の灰色の領域があります:)
また、過去に、私はあなたの2つのアプローチの中間点を取ることに成功しました。 1日目から特定の機能を再利用可能にできるプロジェクトがありましたが、そうすると追加のコストが発生します。代わりに、すべてのコードをローカルに保持しました。同様の機能の必要性が生じた将来の作業で、私はこの作業が最初に行われたプロジェクトに戻り、そのときに、それらのクラスを再利用可能なモジュールにラップする追加のコストを支払いました。これを実行すると、いくつかの利点が得られます。1）必要になるまで追加費用を支払う必要がなく、2）後で再利用可能なコンポーネントを作成するときに、アプリ固有のケースで元のコードがどれだけうまく機能したかに関する知識を活用できます。 「世界」に導入する前に、必要に応じてその設計を変更します。
場合によっては、元のプロジェクトが変更されて新しいv2.0再利用可能モジュールを使用することはありませんでした。元のコードはすでに機能していて、アクティブな開発がないため、そのコードを変更しても意味がありません。他の場合では、再利用可能なコンポーネントが調整および改善された後、カスタム実装を元に戻して置き換えましたが、カスタム実装が実際に作業を行う必要があった後でのみです。したがって、これらすべてからの1つの教訓：カスタムコードを「ハッキング」または作成した場合でも、1〜2時間でクリーンなインターフェイスが完成します。将来、このコードを変更する必要がある場合、そのインターフェイスにより、カスタムコードを削除してライブラリ呼び出しで置き換えるのがはるかに簡単になります。
[〜＃〜] yagni [〜＃〜] 。単体テストで、シンプルで明確、そして十分にカバーされた状態にしてください。
再利用する必要がある場合は、必要に応じてリファクタリングしてください。適切な単体テストを実施している場合、リファクタリングはかなり低リスクです。その上、私の経験では、テスト可能なコードはとにかく再利用可能にかなり近いです。 1つまたは2つの拡張ポイントを追加する必要があるかもしれませんが、コードがそもそもクリーンなものであれば、それほど大きな問題ではありません。
一般的な依存関係を反転したスタイルで意識的にコーディングした後、それは本当に簡単になります。自動的に再利用可能なコードのボーナス付き。
時間/労力/コストの経験則はありませんが、使用したい行は「再利用可能なコードはプロジェクトのpartではないisプロジェクト。」これは、真に再利用可能なコードには、それを使用するすべてのことを考慮に入れて独自に明確に定義された一連の要件があり、将来mayを使用する必要があるためです。
もちろん、プロジェクトの一部として作成されている任意のコンポーネントを取得して、再利用可能にすることができます。ただし、「再利用可能」なもの（引用符で囲まれているもの）と本当に再利用される可能性があるものの違いは、柔軟性、展開に関する考慮事項、パフォーマンス、動作など、あらゆる面で複数の実際のコンシューマのニーズを満たすことができるかどうかです。構成可能性など。本質的に、再利用可能なコードの一部をプロジェクトに組み込むために必要な設計のレベル。