使い捨てコードを開発するための良い戦略はありますか?

https://stackoverflow.com/questions/1373980

21-09-2019
|

質問

私は頻繁に使い捨てのコードを書きます ( 研究環境) - たとえば、科学的特性やプロセスのアルゴリズムやモデルを探索する場合。これらの「実験」の多くは 1 回限りですが、後でいくつか使用する必要があることが判明することがあります。たとえば、7 年前に書いた文字列マッチングのコードを発掘しました (他の優先事項のため中止しました)。これは今では同僚のプロジェクトにとって価値があります。それを見てみると (私は本当にこのような難解なコードを書いたのだろうか?)、「プロジェクト」 (「実験」という言葉のほうがまだ適切です) を再開するときに役立つように、当時できたことがいくつかあることに気づきました。以前の実験は「うまくいきました」が、当時は優先順位が他のところにあったため、リファクタリングする時間がなかっただろうことはわかっています。

このような作業を掘り起こして再利用できるようにするには、どのようなアプローチが費用対効果が高いでしょうか?

編集:実際のソース自体以外にも問題があるため、私は自分の質問（以下）に答えました。

解決

「コメントを書く」という回答にはすべて同意しません。これは、コード自体が理解できないためのキャッチオールとして提供されています。

のコピーを入手してください コードの完成 （スティーブ・マコーネル、第2版）。そもそも保守しやすいコードを書くテクニックを学べば、それ以上時間はかからず、後で問題なく作業に戻ることができます。

どちらを好みますか:

コメント付きの不可解なコードですか?
コードなしでもほとんどOK?

私は後者を強く好みます。不可解なコードがコメントされていない状況では OK コードの方が理解しやすく、コメントは元の開発者が間違いを犯しやすい場所でもあるからです。コードは次のとおりである可能性があります バギー, 、しかし決してそうではありません 間違っている.

慣れてきたら コードの完成, 、お勧めします 実用的なプログラマー, 、少し高度なソフトウェア開発のアドバイスを提供するためです。

他のヒント

自分の質問に答える]問題には、提起されておらず、それを再検討するときに有用だと思われた他のいくつかの側面があります。これらの一部は「自明」かもしれませんが、このコードは SVN や IDE よりも前のものであることを思い出してください。

発見可能性. 。実際、コードを見つけるのは困難でした。これは私の SourceForge プロジェクト内にあると思いますが、7 年間にわたって非常に多くのバージョンとブランチが存在するため、見つけることができません。したがって、コードを検索するシステムが必要になりますが、IDE が登場するまでは存在しなかったと思います。
それは何をするためのものか？. 。現在のチェックアウトには約 13 のクラスが含まれています (当時はリファクタリングが簡単ではなかったため、すべてが 1 つのパッケージにまとめられています)。いくつかは明らかです（DynamicAligner) ですが、その他は不透明です (MainBox, 、Swing Box を拡張したため名前が付けられました）。四つあります main() プログラムであり、実際にはディストリビューション内に約 3 つのサブプロジェクトがあります。したがって、コンポーネントが実際に何であったかを示す外部マニフェストを用意することが重要です。
実行方法の説明. 。プログラムを実行すると、 main() コマンドラインの簡単な使用法を紹介します (例: DynamicAligner file1 file2) しかし、ファイルの内容が実際にどのようなものであるかについては述べられていません。もちろん当時はそれを知っていましたが、今はわかりません。したがって、関連付けられている必要があります例兄弟ディレクトリ内のファイル。これらは、ファイル形式を文書化するよりも価値があります。
まだ機能しますか？. 。それぞれの例は何も考えずに実行できるはずです。最初の質問は、関連するライブラリ、ランタイムなどがあるかどうかです。はまだ関連性があり、利用可能です。ある元同僚は、特定のバージョンの Python でのみ実行されるシステムを作成しました。唯一の答えは書き直すことです。したがって、可能な限りロックインを回避する必要があることは確かであり、私はこれを行うように自分自身を訓練しました（必ずしも同僚ではありませんが）。

では、私や同僚は将来の問題を回避するにはどうすればよいでしょうか?最初のステップは、コードを作成するときに (たとえ小規模であっても) 「プロジェクト」を作成するという規律を設け、これらのプロジェクトをバージョン管理下に置くことだと思います。これは明白に聞こえるかもしれませんが、一部の環境 (学術界、国内) では、プロジェクト管理システムのセットアップに多大なオーバーヘッドがかかります。学術コードの大部分はバージョン管理されていないのではないかと思います。

次に、プロジェクトをどのように組織するかという問題があります。コードは (a) 簡単であり、(b) デフォルトでは開かれていないため、デフォルトでは Sourceforge に置くことはできません。共有プロジェクトとプライベートプロジェクトの両方を存在できるサーバーが必要です。これをセットアップして実行するための労力は約 0.1 FTE であると計算します。つまり、すべての関係者 (設置、トレーニング、メンテナンス) が年間 20 日かかることになります。これは大規模なため、より簡単なオプションがあるかどうか知りたいです。場合によっては費用がかかります - サーバーのセットアップに時間を費やしますか、それとも論文を書くのに時間を費やしますか?

プロジェクトでは、正しい規律を奨励するように努めるべきです。これは本当に私がこの質問から得たいと思っていたものです。これには次のものが含まれる可能性があります。

必要なコンポーネントのテンプレート (マニフェスト、README、コミットのログ、サンプル、必要なライブラリなど)。すべてのプロジェクトが Maven で実行できるわけではありません。フォートラン）。
多数 (少なくとも数百) の小規模プロジェクトからニーモニック文字列を検索する手段 (コードを Googledocs にダンプするというアイデアが気に入ったので、これは有益な手段かもしれませんが、余分なメンテナンスの手間がかかります)。
明確な命名規則。これらはコメントよりも価値があります。現在、定期的に iterateOverAllXAndDoY タイプの名前を使用しています。ルーチンが実際に情報を作成するときは、getX() ではなく createX() を使用するようにしています。私には、convertAllBToY() ではなく process() ルーチンを呼び出す悪い癖があります。

GIT、Mercurial、GoogleCode については知っていますが、使用したことはありません。これらを設定するのにどれほどの労力がかかり、私の懸念のどれだけが解決されるかわかりません。より良いコードの作成に役立つ IDE プラグインがあれば幸いです (例:「メソッド名の選択が不適切」）。

そして、彼らが持っているアプローチが何であれ、生まれつきコードの規律が正しくない人にとっては自然に身につくものであり、努力する価値があります。

あなたの素晴らしい答えとして、他の投稿私自身の経験から言えば、研究に使用されるソフトウェアと、設計されたソフトウェアの間には、越えるのが難しいギャップがあります。私の意見では、Code Complete は少しは役立つかもしれませんが、あまり役に立ちません。経済的な問題として、後で何かの用途を見つけて時折得られる報酬と比較して、再利用のためにすべてをリファクタリングすることに価値があるでしょうか?バランスポイントは異なる場合があります。

スニペットを保存するための実用的なヒントを次に示します。本格的なコメントの代わりに、いくつかのキーワードを追加します。

「グラフ同型ラッパー」
「ポリマーシミュレーテッドアニーリング」
「文字列一致ファインマン」
"平衡"

そして、そのコードを GMail アカウントなど、Google で検索できる場所に置きます。

編集： 無料の Google サイトは実際には検索可能な Wiki であり、添付ファイルまたは貼り付けの形でコードを配置するのに適した場所であることを付け加えておきます。

また、私は Code Complete のファンであり、数年間、科学研究用のソフトウェアを作成する大学院生にコピーを渡してきたことも言っておきます。良いスタートではあるが、特効薬はない。私は現在、科学データ管理の問題を解決するためのオープンソースフレームワークの使用に関する論文を書いています。その結論の 1 つは、長期間実行されるシステムにはソフトウェアエンジニアリングの専門知識が不可欠であるということです。多くの科学プロジェクトでは、おそらく最初からこれに予算を計上する必要があります。

コメント - あなたは思考となぜあなたはあなたが考えられて何の選択肢を含む特定の方法で何かを実装することにしました何であったかを説明します。そこ派手なソリューションのすべての種類は、おそらくですが、あなたは最適に動作するようです書いている時点で適切にあなたのコードをコメントます。

コードが書かれた理由とその使用目的についての「理由」についてコメントする限り、他の人が言ったことを繰り返しますが、これも追加します。

たとえただいじっているだけであっても、あたかもこれを本番環境に導入することを計画しているかのようにコーディングしてください。コード:

明瞭さと読みやすさ
当時のコーディング規約に従ってください。(命名規則など)。このような慣例は時間の経過とともに変化しますが、基準に忠実であれば、後でそれを理解できる可能性が高くなります。
セキュリティ (該当する場合)
パフォーマンス (該当する場合)

特に最初の点を強調しますが、他の点も同様に重要です。後で「テストコード」を使用する場合、リファクタリングするのではなく、機能する場合にのみ使用する傾向があることがわかりました。

私はおそらく、この全体の議論のポイントを逃し、私は頻繁に行うが、ここで行く、brickbatsのための招待状とdownvoting ...

しました

それは使い捨てのコードだ場合は、それを捨てる！

あなたはそれを捨てるしたくない場合は、

その後、上記の良いアドバイスに従ってください。私にとっては、私は使い捨てのコードのかなりの量、それは捨てられるか、再利用可能な状態にし、雨の日が経済に沸くに対して保たれますかどうかの質問を書きます。

することができます私はこのコードは再び有用であろうような状況を予見しましたか？ブルームーンに一度、年二回、毎月？

私は、それが再利用可能にするために要するよりも少ない時間でこのコードを書き換えることができるだろうか？この質問への答えがノーであれば、どのように多くの時間が、私は今、それを強化しながら、それだけの価値を作ってそれを再利用する必要がありますか？（前の質問に戻る。）

私はこのコードの再利用可能なを作る行うと、私は次のことをしたいとき

は、私は再びそれを見つけることができるのだろうか？

最後に、製造の3段階のアプローチを迅速に書かれたコードの再利用可能。停止の手順のいずれかの後にあなたのような：

1）ブラックボックスのようなコードを文書化。入力、出力、動作（複数可）。慎重にこの文書をファイルます。

2）あなたは今までそれのポートに持っている場合には、コードをインストール/解釈/構築する方法についての書き込み命令。慎重にこれらの手順をファイルます。

3）だけの価値があれば努力 - 将来的には、コードの保守性を作るために、ソースコードの品質を向上させます。ソースは、ソース管理システムおよび検索可能。

であることを確認してください

よろしく

マーク

（あなたは何も起こるだろうされていませんリファクタリングない場合）

私は、ほとんどの輸入の事を考えていない時にコメントし、あなたの思考プロセスを文書化することです。これは、コードが少ない不可解な、必要なときにあなたが良いビットを見つけるのに役立ちます。

いやいやいやいやいや！

研究環境であっても使い捨てのコードは書かないでください。お願いします！

現在、私はそんな「使い捨てコード」、つまりBLASTプロジェクトをいじっています。問題は、これは遊び場として始まったが、その後たまたまある程度の成功を収めたということです。今では、多くの概念が実装されたきちんとしたツールですが、コードは事実上保守不可能です。しかし、それが重要な点ではありません。

重要な点は、エンジニアのために調査を行って、後で調査結果を活用できるようにすることです。一般的な概念について優れた科学的研究を行い、その成功を証明するツールを作成した後は、出版や博士号取得のためだけにそれを行っているわけではないことを簡単に忘れてしまいがちです。あなたは人類の利益のためにそれを行っています。コードには、デバッグが困難な「特殊なケース」、カンファレンスの記事には当てはまらない一連の癖やハックが含まれている可能性があります。コード全体でそのようなことを文書化し、コメントすることが特に重要です。

開発者があなたのコンセプトを商用製品に実装することを決定した場合、コードから癖やハックを研究することができ、実装のバグは以前よりも少なくなるでしょう。誰もが「うわー、彼の研究は本当に便利です！」と言います。しかし、あなたが「スローウェイ」を書くと、彼らは「彼のコンセプトは紙の上で見栄えが良いが、Xはそれを実装しようとし、たくさんのバグにown死した」と言う。

(編集:以下のコメントから抜粋) コードベースの将来の開発者を助けるために、多くのものは必要ありません。初め、 各関数の動作をコメントする. 。2番、 扱いにくいバグのすべての明白でない修正が別のコミットに配置されていることを確認する リビジョン管理システムで (もちろん、適切なコメント付きで)。それで十分です。そして、たとえ完全に再利用する準備ができていなくても、モジュール化さえすれば、ブルックスによれば、それは 3 倍のコストがかかるということです) あなたの研究を実装するエンジニアから尊敬されるでしょう。

研究者たちが傲慢さを捨て、自分たちは良いコードを書くという単純な仕事をする汚いプログラマーではないという傲慢な考えをやめれば、世界はもっと良くなると思います。良いコードを書くことは、こうした愚かなプログラマーだけの仕事ではありません。それは誰もが努力すべき本当に価値のあることです。これがなければ、あなたの実験場、コード、発案者はただ死んでしまうでしょう。

いくつかの戦略:

良いコメント。後で見つけられない、または理解できないものを再利用するのは困難です。
すべてのクエリをバックアップされたフォルダー、またはソース管理下にあるフォルダーに保存します。
便利な関数の共通ライブラリを用意し、再利用後に何かを「昇格」させます。

TDD (テスト駆動開発) の人々から単体テストのアイデアを借用することもできます。いずれにしても、使い捨てコードが実際に正常に動作することを確認する必要があるため、チェックリンクを小さな単体テストで表現してみてはいかがでしょうか?これには次の 2 つの利点があります。

テストコードを読むと、スローアウェイの意図が非常に明確に伝わります。結局のところ、それは同じ言語で期待を表現しています。コード。
あなたの自己返信の 4 番目の問題にも役立ちます。「まだ使えるの？」。まあ、それは簡単です:単体テストを実行するだけで、何がどこで (そして少し運が良ければ) なぜ機能しないのかがわかります。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow