私は頻繁に使い捨てコードを（研究環境で）作成します。たとえば、科学的特性やプロセスのアルゴリズムやモデルを探索するためです。これらの「実験」の多くは1回限りですが、後でいくつか使用する必要がある場合があります。たとえば、7年前に書いた文字列照合のコードを発掘したばかりですが（他の優先順位のために停止しました）、これは現在、同僚のプロジェクトにとって価値があります。それを見て（私は本当にそのような侵入不可能なコードを書いたのですか？）、「プロジェクト」を再開したときに私を助けるために私ができることがいくつかあることに気付きました（「実験」はまだより良い言葉です）。以前の実験は「機能しました」が、私の優先順位が他の場所にあるため、当時はリファクタリングする時間がなかったでしょう。
そのような作業を掘り起こして再利用できるようにするために、どのようなアプローチが費用効果が高いでしょうか？
編集：実際のソース自体を超えた問題があるため、私は自分の質問（以下）に回答しました。
私は「コメントを書く」というすべての答えに同意しません。これは、コード自体が理解できないためのキャッチオールとして提供されています。
Code Complete（Steve McConnell、第2版）のコピーを入手してください。そもそも保守可能なコードを書くテクニックを学べば、それ以上の時間はかからず、後で問題なく仕事に戻ることができます。
どちらがいいですか：
不可解なコードがコメントされていない状況ではOKコードが理解しやすく、コメントは元の開発者が間違いを犯す可能性がある別の場所であるため、後者の方が強く好きです。コードはバグがあるかもしれませんが、それは決して間違っていません。
Code Completeに慣れたら、少し高いレベルのソフトウェア開発アドバイスを提供するThePragmaticProgrammerをお勧めします。
[自分の質問に答える]この問題には、まだ提起されておらず、再検討するときに役立つと思われるいくつかの側面があります。これらのいくつかは「自明」かもしれませんが、このコードはSVN以前とIDEであったことを覚えておいてください。
DynamicAligner）ですが、他は不透明です（MainBox、スイングボックスを拡張したために名前が付けられています）。4つのmain()プログラムがあり、実際にはディストリビューションには約3つのサブプロジェクトがあります。したがって、コンポーネントが実際に何であったかについて、外部マニフェストを用意することが重要です。main()と、コマンドラインの簡単な使用法（例DynamicAligner file1 file2）が表示されますが、ファイルの内容が実際にどのように見えるかはわかりません。もちろん、私は当時これを知っていましたが、今は知りませんでした。したがって、兄弟ディレクトリに関連するサンプルファイルがあるはずです。これらは、ファイル形式を文書化するよりも価値があります。では、私と同僚は将来どのようにして問題を回避できるでしょうか。最初のステップは、コードを作成するときに「プロジェクト」（ただし小さい）を作成する規律があり、これらのプロジェクトはバージョン管理下にある必要があることだと思います。これは一部の人には明白に聞こえるかもしれませんが、一部の環境（学界、国内）では、プロジェクト管理システムのセットアップにかなりのオーバーヘッドがあります。アカデミックコードの大部分はバージョン管理下にないのではないかと思います。
次に、プロジェクトをどのように編成するかについての質問があります。コードは（a）些細なものであり、（b）デフォルトでは開かないため、デフォルトでSourceforgeに含めることはできません。共同プロジェクトと私的プロジェクトの両方が存在できるサーバーが必要です。これを設定して実行するための労力は約0.1FTEであると計算します。これは、すべての関係者（インストール、トレーニング、メンテナンス）から年間20日です。これは大きいので、もっと簡単なオプションがある場合は知りたいです。場合によっては費用がかかります-サーバーのセットアップに時間を費やしますか、それとも論文を書きますか？
プロジェクトは、良い規律を奨励するよう努めるべきです。これは本当に私がこの質問から得たいと思っていたものです。これには次のものが含まれます。
私はGIT、Mercurial、GoogleCodeを知っていますが、使用していません。これらを設定するのにどれだけの努力が必要か、そして彼らが答える私の懸念の数はわかりません。より良いコードを作成するのに役立つIDEプラグインがあれば嬉しいです（たとえば、「メソッド名の選択が不十分」）。
そして、自然に優れたコード規律を持たず、努力する価値のある人々に自然に到達しなければならないアプローチが何であれ。
あなたの他の投稿の優れた回答が示すように、そして私自身の経験から、研究に使用されるソフトウェアと設計されたソフトウェアの間には、交差するのが難しいギャップがあります。私の意見では、Code Completeは少しは役立つかもしれませんが、あまり役に立たないかもしれません。経済的な問題として、後で何かの用途を見つけることに対する時折の報酬と比較して、再利用のためにすべてをリファクタリングすることは価値がありますか？バランスポイントは異なる場合があります。
スニペットを保存するための実用的なヒントを次に示します。本格的なコメントの代わりに、いくつかのキーワードを投入します。
次に、GMailアカウントなど、Googleで検索可能な場所にコードを配置します。
編集： 無料のGoogleサイトは、添付ファイルの形式または貼り付けのいずれかでコードを配置するのに適した、本当に検索可能なWikiであると付け加えるかもしれません。
また、私はCode Completeのファンであり、科学研究用のソフトウェアを作成している大学院生に数年間コピーを提供してきました。良いスタートですが、特効薬はありません。私は現在、オープンソースフレームワークを使用して科学データ管理の問題を解決することについて論文を書いています。結論の1つは、ソフトウェアエンジニアリングの専門知識が長期的なシステムに不可欠であるということです。多くの科学プロジェクトは、おそらく最初からこれに予算を組むべきです。
私はおそらくこの議論全体の要点を見逃しているでしょう、私は頻繁にそうします、しかしここに行きます、ブリックバットと反対投票への招待...
使い捨てコードの場合は、捨ててください。
捨てたくない場合は、上記の良いアドバイスに従ってください。私にとって、そして私はかなりの量の使い捨てコードを書いていますが、それが捨てられるのか、それとも再利用可能な状態にされて雨の日を防ぐのかという問題は、経済学に帰着します。
このコードが再び役立つ状況を予測できますか？ブルームーンに一度、年に二度、毎月？
このコードを再利用可能にするよりも短い時間で書き直すことができますか？この質問に対する答えが「いいえ」の場合、今それを強化しながら価値を高めるために何回再利用する必要がありますか？（前の質問に戻ります。）
このコードを再利用可能にした場合、次に必要になったときに再び見つけることができますか？（コードリポジトリのどこかに必要なフラグメントがあることを絶対確実に知っている人は誰でも経験したことがありますが、それが何と呼ばれているか、どこを探すか、何をgrepするかについての手がかりはありませんか？）
最後に、すばやく記述されたコードを再利用可能にするための3ステップのアプローチ。これらのステップのいずれかが好きな後に停止します。
1）コードをブラックボックスとして文書化します。入力、出力、操作。この文書は慎重に提出してください。
2）移植する必要がある場合に備えて、コードをビルド/解釈/インストールする方法についての説明を書いてください。これらの指示を慎重に提出してください。
3）努力する価値がある場合にのみ、ソースコードの品質を改善して、将来的にコードを保守できるようにします。ソースがソース管理システムにあり、見つけられることを確認してください。
よろしく
マーク
最も重要なこと（リファクタリングを行わないと、リファクタリングは発生しません）は、その時点での思考プロセスにコメントして文書化することだと思います。これにより、コードが侵入しにくくなり、必要なときに適切なビットを見つけることができます。
コメント-あなたが考えていたことと、あなたが考えた代替案を含め、特定の方法で何かを実装することを選んだ理由を説明してください。おそらくあらゆる種類の凝った解決策がありますが、書いているときにコードに適切にコメントするだけで、それが最もうまくいくようです。
コードが書かれた理由とその使用目的の「理由」についてコメントする限り、他の人が言ったことをエコーしますが、これも追加します。
ただいじり回しているときでも、これを本番環境に移行することを計画しているかのようにコーディングします。コード：
特に最初の点を強調しておきますが、それ以外も重要です。後で「テストコード」を使用する場合、リファクタリングするのではなく、機能する場合にのみ使用する傾向があることがわかりました。
いやいやいやいやいや！
研究環境でも使い捨てコードを書かないでください。お願いします！
現在、私はそのような「使い捨てコード」、つまりBLASTプロジェクトをいじっています。問題は、それが遊び場として始まったが、その後、いくらか成功したということです。今では、多くの概念が実装された優れたツールですが、コードは事実上保守できません。しかし、それは主要なポイントではありません。
重要な点は、後で調査結果から利益を得るためにエンジニアのために調査を行うことです。一般的な概念について優れた科学的研究を行い、これが成功したことを証明するツールを作成したことで、出版や博士号のみを目的としてそれを行っていることを簡単に忘れることができます。あなたは人類の利益のためにそれをします。コードには、デバッグが困難な一連の「特殊なケース」、会議の記事に適合しない一連の癖やハックが含まれている可能性があります。コード全体でそのようなことを文書化してコメントすることが特に重要です。
開発者があなたのコンセプトを商用製品に実装することを決定した場合、彼はあなたのコードからの癖やハックを研究することができ、実装はそれが持っていたかもしれないよりもバグが少ないでしょう。誰もが「うわー、Aに関する彼の研究は本当に役に立ちます！」と言います。しかし、「使い捨て」と書くと、「彼のコンセプトは紙の上では見栄えがするが、Xはそれを実装しようとし、たくさんのバグに溺れてしまった」と彼らは言う。
（編集：以下のコメントから抜粋）コードベースの将来の開発者を支援するために、多くは必要ありません。まず、各関数の機能についてコメントします。次に、トリッキーなバグのすべての非自明な修正が、リビジョン管理システムの個別のコミットに配置されていることを確認してください（もちろん、適切なコメントが付いています）。それで十分です。そして、もしあなたが物事をモジュール化することさえすれば（たとえそれらが完全に再利用する準備ができていなくても-それはブルックスによれば3倍の費用がかかります）あなたはあなたの研究を実行するエンジニアに崇拝されるでしょう。
研究者が傲慢さを捨てて、良いコードを書くという卑劣な仕事をしているこれらの汚いコーダーではないと高慢に考えるのをやめれば、世界はより良い場所になると思います。良いコードを書くことは、これらの愚かなプログラマーの仕事だけではありません。それは誰もが努力すべき本当に価値のあることです。これがなければ、あなたの実験的根拠、あなたのコード、あなたの頭脳はただ死ぬでしょう。
また、TDD（テスト駆動開発）の人々から単体テストのアイデアを借りることもできます。とにかく使い捨てコードが実際に正常に機能することを確認する必要があるので、小さな単体テストにチェックリンクを表現してみませんか？これには2つの利点があります。
テストコードを読むと、使い捨ての意図が非常に明確に伝わります。結局のところ、テストコードは同じ言語であるコードで期待を表しています。
また、自己返信の4番目の問題である「それでも機能しますか？」にも役立ちます。まあ、それは簡単です。単体テストを実行するだけで、何がどこで（そして少し運が良ければ）なぜ（それが）機能しないのかがわかります。
いくつかの戦略：