この記事の転載元URL: https://wraith13.github.io/writing/?programming%2Fdeleteme.md

DELETEME

コンセプト

• 不要になったハズだけど、まだ残しておきたいコードのクラスや関数の名前には DELETEME を含めます。
• DELETEME と明示される事で、間違えて利用してしまう事を防ぎ、また、いまは気にしなくて良いコードだと示せます。
• 明らかに完全に不要になった際は必ず容赦なく削除します。
• 再度、利用する事になった場合は必ず DELETEME の明示を削ります。

サンプル

// before
const renderItem = () =>
{
    ...
}

// after
const renderItem_DELETEME_at_Feb2020 = () =>
{
    ...
}

詳細

• ディレクティブが使えるプログラミング言語では #if DELETEME 〜 #endif のようなディレクティブで囲むのも良いでしょう。
• 対象となるコードがファイル単位やディレクトリ単位になる場合、ファイル名やディレクトリ名に DELETEME を付けるのも良いでしょう。
• 特にゼロから書き起こしている最中のコードは試行錯誤を繰り返し方針をコロコロ変える事も珍しくないでしょう。そのような場合に現行の方針上は不要になったコードを DELETEME で明示しておく事で、いまは気に掛けなくていいコードだと明示できますし、なにより方針変更でやっぱり必要になった！って場面でも面倒が少なく、もちろん最終的に確実に要らなくなった際も DELETEME で検索することでスムーズに削除でき、間違えてコミットしてしまう事も減らせれば、間違えてコミットした際にも間違えてコミットしたコードである事も分かり易くなります。
• 乱用すると使用されないコードによってコード全体が無駄に間延びしてしまいコードの見通しが悪くなるので程々に。
• DELETEME と明示するコードにはいつになったら削除してよいのか、できればその期限やその他の条件を明記します。

ARCHIVEME

• 使用はしないが長期保存したいコードに対しては DELETEME ではなく ARCHIVEME と明示し、保存期間以外に関しては DELETEME と同様の運用を行います。
• 一般的に最適化を行うとコードの可読性やメンテナンス性は著しく悪化する上に、前提の変化により、最適化の意味が無くなったりかえってパフォーマンスが悪くなる事もあるでしょうし、そうでなくとも最適化後のコードにやっかいなバグが存在しどうにも対処できないなんて事もあるでしょう。そういう事態に備えて最適化前のクリアでソリッドなコードを ARCHIVEME として残しておくと良いでしょう。
• 「バージョン管理ツールがあればこのような事は不要では？」という言説もあるでしょうが、特に削除してからかなりの期間が経過している場合、削除したコードをバージョン管理ツールを漁って拾ってくるのは存外手間も掛かる上に、なんらかの形でリポジトリを移行する際に移行前の履歴は分断される等して、削除したコードを拾ってくる手間や難易度が著しく上昇する事も珍しい話ではありません。また、最適化後のコードに問題がある場合などに、最適化前のコードを 気軽に 参照したり動作確認できる事は重宝される事でしょう。