3

リーンな小さなソフトウェア会社で働いていると想像してみてください。会社の将来の競争力は、再利用可能な優れたコード ベースを利用できるかどうかにかかっています。会社の再利用ポリシーを管理して、将来のバックボーンを提供すると同時に、今日提供できるようにすることが非常に重要になります。

私の考えでは、ビジネスで再利用可能なコードを書く理由は 2 つあります。1) 社内で共有し、将来的にスピードと効率を向上させるため 2) Web や他の人に公開することで、コードの改善に役立ちます (ある意味でのクラウドソーシング)。

もちろん、開発者は常に常識を働かせて再利用する必要があります。しかし、管理の観点からこれを処理するには、現在および将来の競争力を確保するための全体的なコード再利用のガイドラインが必要です。これらのガイドラインは、開発者が「私のコードは再利用の候補ですか?」と尋ねることを奨励するものです。これらのガイドラインには何を記載する必要がありますか?

私の最初の考え: 最下位レベルで再利用可能なコードを書く価値はありません (たとえば、文字列の末尾に「's」を追加するインライン コードがあります)。ふるいにかけて、誰かがすでにそれを行っていることを見つけることさえあります。また、最上位レベル、つまりアプリケーションで再利用可能なコードを書く価値もありません。顧客レポート アプリケーションが最終的に SQL クライアントに汎用化されてしまい、ほとんどのユーザーにとって役に立たないからです。

再利用可能なコードの主な障害: コードの存在を知らなければ再利用できません。信頼 – 完了しましたが、信頼できますか?; コードを一般化/再利用可能にする (および文書化する) のにかかった初期時間。

4

7 に答える 7

8

誰も再利用せずに、何かを再利用可能にしようと長い時間を費やすことができます。そのため、私は通常、再利用する場合にのみ再利用可能にするという格言に従います (際立った例外がいくつかあります)。

多くの場合、クライアントが「同じことをしたいのですが...」などと言うのは、何かを再利用するようになったときだけです。再利用可能なコードのどの部分が再利用可能で、何をパラメーター化する必要があるかを理解するのは、その時点だけです (たとえば、戦略パターンなどを介して)

したがって、実際に再利用されない限り、コードを再利用可能と見なす傾向はありません :-)

于 2009-07-14T11:15:33.630 に答える
4

コードを再利用可能にしないほうがよいと思います。

代わりに、非常によく似た 2 つのコードを見つけたら、それらをリファクタリングします。共通のコードを抜き出し、違いはそのままにしておきます。単体テストを再実行し、成功したら完了です。

単体テストありましたよね?

于 2009-07-14T11:02:49.193 に答える
1

一般的なコードのみを再利用可能にします。文字列に s last を追加するだけの関数は、それが既に使用されている場合を除いて価値がありませんが、文字列の末尾に任意の 1 つまたは複数の文字を追加できる関数は、他の用途にも役立ちます。

基本機能; リスト、ツリー、ソケット、および/またはファイル処理用の独自の関数と型がある場合、これらはすべて共有ライブラリで役立ちます。

また、すべての関数と型についてコメントし、Doxygen (または Javadoc) のようなシステムを使用して、ドキュメントを自動的に生成できます。これにより、IDE の外部でも検索可能になり、やや良い方法で表示されます。

于 2009-07-14T10:59:40.010 に答える
1

適切に作成されたコードはすべて、再利用の候補です。

時間をかけてコードを汎用化し、文書化すると、そのコードを別のプロジェクトで再利用できるだけでなく、他の人が実際にあなたのコードを見るようになります。これにより、ユーザーがバグや癖を見つける前に誰かが発見する可能性が大幅に向上します。

重要なことは、コードがあるべき場所を明確に区別することです。「文字列に "s" を追加する」の例を挙げると、これは「文字列に "h" を追加する」および「文字列に "b" を追加する」とともに、strings-util ライブラリのどこかに配置されるコードである可能性があります。文字列関数。これら 3 つの関数を一緒に見ると、より一般的な「任意の文字を文字列に追加する」関数を作成して、コードをさらに再利用可能にするというアイデアが得られるでしょう。文字 'r' を文字列に追加することもできます。今!

常に文字列に文字を追加しているという事実を見つける唯一の方法は、これらの関数が互いに隣り合っていることを確認することです。そうしないと、誰もが同じ関数をコードのどこかに隠してしまいます。

これらの種類の util コレクション/クラス/低レベルのコードを含むものは何でも - それらは一般的であり、特定のプロジェクトとの関連性を保持していないようです。

スケールの上限も再利用可能なコードとして扱う必要があります。たとえば、ウェブサイトに画像を追加するなど、素晴らしい新しいアイデアを持った顧客がいるとします。他の誰もこれを必要としないので、先に進み、このクライアント専用のタグを追加します。2 週間後、別のクライアントからまったく同じことを尋ねられました。

このような状況で通常起こることは、最初のクライアントの余分なコードが 2 番目のクライアントのプロジェクトにコピーされることです。実際に起こっていることは、コードの保守性が低下していることです。同じコードが 2 つの場所にあり、同じバグがあります。これが将来の問題につながることは誰もが知っていると思います。

例が再利用のために書かれている場合は、2 番目のプロジェクトで再度使用できるため、時間と労力を節約できます。また、次のクライアントが要求する追加機能は、おそらく最初のクライアントにアップグレードとして提供できるものです (ほら、高さと幅を設定できるようになりました!)

コードが存在することを知ることに関しては、それは常にそこに残る問題です。この知識を広める一番早い方法は、開発者が独力で開発しないようにすることだと思います。ペア プログラミングはその良い例です。このようにして、何かが書かれるたびに、少なくとも 2 人がそれについて知るようになります。ペアを定期的に混同すると、余分な努力をしなくても知識が社内に広まります。

于 2009-07-14T11:14:58.810 に答える
0

私は再利用可能なライブラリを構築する傾向があるのは、その機能が少なくともあと 1 回は必要であり、コードをスタンドアロン ライブラリにするのにかかる時間が、再構築またはコピーするのにかかる時間よりも短いと確信している場合だけです。さらに、作成するライブラリは 1 つの問題を解決する必要があります。

この最近の例は、アプリと Protx 支払いシステムの間のインターフェースを提供するように設計されたプラグインです。I は 1 つの問題を解決するもので、これまでにいくつかの異なるプロジェクトで使用されてきました。

于 2009-07-14T13:19:56.063 に答える
0

私は再利用し、継続的にサポート/リファクタリングします:

  • 特定のタスクを適切に実行するすべてのライブラリ
  • サービスが劇的に変化しない限り、特定のサービスへのクライアント
  • ビジネスケースが破棄されない限り、ビジネスレイヤー/モデル
  • Web/デスクトップ インターフェースは、機能を十分に提供できる限り

私は捨てて(scmから削除)、最初から書き直します:

  • よく書かれていないライブラリ。いくつかのタスクを実行しようとし、それらすべてをうまく実行しない
  • サービスが完全に書き直され、別のテクノロジで変更された場合 (Web サービスでデータベースが変更された場合)、サービスへのクライアント
  • 何も提供されなくなったときのビジネス層/モデル
  • クライアントが大きな変更を希望するとき、または別のフレームワークに切り替えるときのインターフェース
于 2009-07-14T11:01:14.797 に答える