関数が正しく動作するように 1 日を費やしているのに、アーキテクチャの変更によってその関数が使用されなくなった場合はどうしますか? しかし、コードが十分に有用であり、アーキテクチャが元に戻ったとしても、その関数が再び有用になることを知っていますか?
チェックインする前に関数を削除するのは間違っているようですが、チェックインすると未使用の関数としてスペースを占有します。
関数が正しく動作するように 1 日を費やしているのに、アーキテクチャの変更によってその関数が使用されなくなった場合はどうしますか? しかし、コードが十分に有用であり、アーキテクチャが元に戻ったとしても、その関数が再び有用になることを知っていますか?
チェックインする前に関数を削除するのは間違っているようですが、チェックインすると未使用の関数としてスペースを占有します。
答えとして、次の短い話を考えてみてください。
デッド コード コレクター: デッド コードを取り出してください。
死んだコードを持つ男 : これが 1 つです。
デッド コード コレクター: それは 9 ペンスになります。
デッド コード: 私はデッド コードではありません。
デッド コード コレクター: なに?
デッド コードを持つ男: 何もありません。あなたの9ペンスがあります。
デッド コード: 私はデッド コードではありません。
デッド コード コレクター: ほら、彼は自分はデッド コードではないと言っています。
デッド コードの男 : はい、そうです。
死んだコード: 私はそうではありません。
デッド コード コレクター: 彼はそうではありません。
死んだコードを持つ男: ええと、彼はすぐに治ります。彼は非常に病気です。
死んだコード: 私は良くなっています。
Man with dead code : いいえ、そうではありません。すぐに石のデッド コードになります。
デッド コード コレクター: うーん、私は彼をそのように受け止めることはできません。規約違反です。
死んだコード: カートに乗りたくない。
死んだコードを持つ男: ああ、そんな子供にならないで。
死んだコード コレクター: 私は彼を取ることができません。
死んだコード: 元気です。
死んだコードを持つ男:ああ、お願いします。
デッド コード コレクター: できません。
Man with Dead code : では、数分間ぶらぶらしてもらえますか? 彼は長くはありません。
デッド コード コレクター: ロビンソンの家に行くと約束したのに。彼らは今日9人負けました。
Man with dead code : では、次のラウンドはいつですか?
デッド コード コレクター: 木曜日。
デッド コード: 散歩に行こうと思います。
Man with dead code : あなたは誰も騙していませんよね。何かできることはありませんか?
死んだコード: 私は幸せを感じます。私は幸せを感じます。
[デッド コード コレクターはこっそり通りをちらりと見回し、Ctrl-X を連打してデッド コードを黙らせます]
デッド コードの男: ああ、どうもありがとう。
役立つコードはすべて、オフライン コード スニペット データベースに記録しています。
チェックインしないでください。中央リポジトリは、アプリケーションで使用される作業コード専用の場所です。
定義上、未使用のコードは役に立ちません。常にYAGNIを覚えておいてください。99% のケースで、削除する必要があります。なぜなら、次に役立つかもしれないからです (たった 1 日しか費やしていません)。
「クール」なまれなケースでは、スニペットデータベースに保存できます。
私は間違いなくそれを削除します。プロジェクトのメンバーが見ることができる特別な場所に置くことができますが、プロジェクトの外に出すことができます。呼び出されていない特定の関数が存在する理由を開発者が理解できない場合、メンテナンスが困難になります。
その場合、私は常に、ソフトウェアの一部が記述されているWIKIを使用します。適切にラベル付けされたサブアイテムとその機能の適切な説明がそれを行います。
私の意見では、この関数全体を再利用することは常に役立つとは限りませんが、かつては意味を成していた、機能的で優れたコードを調べることは有益です。
コードを削除します。削除した内容とその理由を説明する適切なチェックイン コメントを書きます。これは、後でそのファイルに対して履歴コマンドを実行する人がそれを理解し、バージョン管理リポジトリから関数を取得できるように十分に明確である必要があります。
削除しようとしていることを示すコメント (コード内およびチェックイン) を付けて、チェックインします。
次に、それを削除し、すぐに変更をチェックインし、その理由を説明するチェックイン コメントを付けます。
そうすれば、コードベースに粗雑さがなくなりますが、コードの永続的な記録が得られます。
チェックインしてコメントアウトします。私見、スペースのコストは、それを正しくするために費やした時間に見合うだけの価値があります(風が変わった場合は、もう一度費やす必要があるかもしれません). アクティブなコードが乱雑にならないように、「ビットとピース」ファイルの一部としてチェックインすることができます。
喜んで削除します。
コードは、動的な世界で変化する要件に対して行われる静的な約束です。
今日の私のポイントは、コードの行数を数えたいのであれば、それを「生成された行」ではなく「消費された行」と見なすべきだということです。元帳。
—<a href="http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF" rel="nofollow noreferrer">ダイクストラ 1036-11
自分で考案した、またはシステムで利用可能なスニペットコレクターに保管してください。問題は、それをどこに置くかということではなく (ほとんどの場合、テキストだけについて話しているのではないでしょうか?)、それを再び見つける方法です。問題はそれを再び見つける方法であるため、何らかのタグ付け/検索方法を使用する必要があります。
コード スニペットはCode Collector Pro (Mac 用) に保存しています。
この方法では、どのプロジェクトにもありませんが、必要なときにいつでも再利用できます。
免責事項: 私は満足している顧客です。
コードを投稿してください: http://snipplr.com/ http://refactormycode.com/
他の人に評価してもらい、おそらくそれも使用してください:)
デッド コードはメンテナンスされなくなりました。再び必要になったときは、再び機能させるために時間を費やす必要があります。それが本当に便利で、それについてまだ覚えている場合は、バージョン管理からいつでも取得できます。
職場では、ソース ファイルの 70% を占める 4 年前にコメント アウトされたコードを使用している人がいます。 放っておいて
コードの少ないシステムの方が、コメントしたコードは、後でコメントを外したときに、とにかく役に立たないでしょう。コードが正常に機能していたすべての環境が変更されるか、より危険な状態になる可能性があります。新しいビジネスロジックに付属する小さな目に見えない部分が変更される可能性があります。
古いコードは、新しいバグを導入する絶好の機会です。古いコードのコメントを外すことは、定義上悪であると推測してプログラミングすることと同じです(まあ、それは機能します!)。
それをオープンソース!あなたにとって役に立たなくても、他の誰かにとっては役に立つかもしれません。
これに対する通常の議論は、会社は無料のコードを書くのにお金を払っていないというものですが、不安定なアーキテクチャに対して作業をさせているため、とにかくあなたのコードの利益を得ていません.
約 2 年前に現在の雇用主で働き始めて以来、ユーティリティ コードの非常に大きなリポジトリを作成してきました。いくつかのカテゴリに分けられ、いくつかのプロジェクトで使用されます。私が作成した必要のないコードはすぐにそこに入り、使用されるまで (または永久に、どちらか早い方) 休止状態になります。
プロジェクトのコピーにクラス ファイルがあり、そこに有用な未使用の関数を保存し続けています。
別の方法: プロジェクトを SVN リポジトリに保持しているため、便利な関数を置き換えると、ログ ファイルに常に dat 関数が含まれているため、将来いつでもアクセスできます。
「コードを削除する方法」に多くの提案がありますが、テスト済みで未使用の関数を時折ダンプするプレーン テキスト ファイルを保持しており、いつか役立つ可能性があります。それらを完全に捨てるのは耐えられませんが、繰り返しになりますが、それらのいずれにも戻る必要はありません。
このようなファイル/コード スニペットのコレクションに関するもう 1 つのルール: 1 つの場所に 1 つだけ配置します。