調査するとき、どのソフトウェア方法論に従うべきですか？

私は通常、実験のデータを分析し、実行する必要のある手順の一般的なスキーマがありますが、実験の詳細や背後にある質問に合わせて微調整する必要があるかもしれません。私は通常、唯一のコーディングです。

私はウィキペディアを見ましたが、どの方法論を使用できるのかわかりません。これまでフォローしたことがないため、データを調査してデータを調べたり、答えを求めたりするためです。（そして、私は自分のコードでテストしたり、特定の品質を期待したりすることがあまりないので）

r関数tableがベクトルの順序に依存しており、それらを比較する要素の名前に依存していないことを発見した1〜2時間後に、この質問をするように促されました。それから私はいくつかのモックデータで使用した動作と機能をテストする必要がありましたが。しかし、他の分析の結果、情報が不足したためにテーブルを使用したため、テスト駆動型の開発方法論を理解できませんでした（正しく理解していれば）。ただし、プロジェクトに直面する方法が少し改善されたので、エラーをより早く検出することを除いて、より効率的になる可能性があると感じていますが、結果が疑わしい場合にどのようにして何を探すべきかを考えています。この例の間違い。

研究に最も適したソフトウェア方法論はどれですか。

私は基本的に、研究の特異性を維持するだけでなく、品質と時宜を得た進歩を確実にする方法を尋ねています。

私の仕事の例：

生物学者は質問を念頭に置き、実験を行うことで目的のデータ（つまり、2つの条件での遺伝子発現レベル）が得られることを知ってから、実験を設定し、10人/マウス/ラットからサンプルを収集します。 。次に、既存のライブラリとテストを使用して（または新しいテストを実装して）、これらの10サンプルのデータを分析する必要がありますが、生物学者が考えていた質問（つまり、ある遺伝子が他の条件よりも多く発現する）を考慮に入れます。構造は以前の実験（6つの条件と別の動物を含む）と同じですが、統計的検定、正規化、データ構造が変更される場合があります。そのため、私は通常、以前のバージョンをコピーして、現在のニーズに適合させます。

必要なのは、おそらくソフトウェアの方法論ではなく、科学におけるソフトウェア開発が果たす役割の認識の欠如という問題を修正する学界の政治的変化です。

ソフトウェアサステナビリティ研究所（UK）は、科学研究におけるコンピュータプログラミングのより多くの良心的な使用を主張する方法：あなたが探しているものに最も近い組織です。

また、ソフトウェア開発方法論に関心のある人のための情報ポインターも提供します。

ただし、方法論は通常、ソフトウェアプログラマーのチームを管理し、プロジェクト目標の反復と段階的な改良を行い、長期間続く安定したコードベースで機能することを指摘する必要があります。それらは、あなたがやっていることよりも桁違いに複雑なプロジェクトのためのものです。

この非常に明らかに正しいこと（科学的研究におけるコンピュータープログラミングのより良心的な使用）が達成されず、常に支持されていない理由について、ここに不都合な真実があります。プログラミング。貢献の性質が科学の分野に適合している場合でも、ソフトウェアに関係する人々からの貢献の認識を否定するために、彼らが団結しているように見える場合があります。

• http://www.scientific-computing.com/news/news_story.php?news_id=2737
• https://news.ycombinator.com/item?id=10553837

あなたの職場には、足りないものがあり、できることもあります。

欠けていたもの：

• ガイドラインの欠如
• 監督または質問をする人の欠如
• 使用するツール（Rなど）に精通しているメンターまたはコンピュータープログラマーの不足
• 再現性と学習を目的とした、以前に開発されたソフトウェアのソフトウェアの再利用、アーカイブ、バージョン管理、またはドキュメントの欠如

要するに、全体的な文化は、関係する人々は本当に興味を持っていないということです...あなたはそれを推測した...科学的研究におけるコンピュータプログラミングのより良心的な使用。

できること：

• ツールの学習により多くの時間を割いてください。
  • プログラミング言語のドキュメントとコードサンプルを読む時間を増やす
  • 使用するツールを愛することを学ぶ必要があります。
• 同じ人のグループに今後数年間奴隷になる次のコンピュータープログラマーのために、何かを書き留めてください。
  • wikiはすばらしいでしょう。
• ソースバージョン管理を設定してみてください
  • 一般的に再利用されるコードスニペットを取得できる
  • 特定の実験で使用されたコードのスナップショットを保存できる

キャリアソフトウェア開発者にとって、このようなガイドラインは次の場所にあります。

• ジョエル・テスト：ジョエル・スポルスキーによるコード改善のための12のステップ

これらは、ソフトウェア開発ビジネスを実行するための基本的な要件と見なされます。ただし、無関心の戦争を戦っているときは、一人で優先する必要があります。ツールの改善、情報の書き留めと保守、ソースコードのバージョンの保持は、単一の環境で最低限必要なことです。

方法論をそれほど気にしないでください。しかし、ソフトウェア開発自体について、追跡する必要のあるもの、要件、に集中してください。

ここであなたのポジションに比較的近いポジションで短い滞在をしたことが、私が私の個人的な経験から引き出すことができるものです。

アルゴリズムの正確さ

おそらく最も重要な側面は、ソフトウェアが設計どおりに動作することを証明できることです。ここで自動テストはあなたの最高の味方です。適切なデータセットなしでは難しいことだと思いますが、実際には独自のデータセットを作成する習慣をつける必要があります。ただし、その目的は多少異なります。データから傾向を抽出するのではなく、ソフトウェアが既知のデータセットから予測可能で正しい結果を生成するようにします。したがって、たとえばパターン認識の場合、マルチギガの遺伝子構成は必要ありません。アルゴリズムがパターンを確実に検出するには、数行のテキストで十分です。

以前は、ありきたりのケース、不可能なケースを表すデータを作成していました。私は予想される基準よりも極端に焦点を合わせる傾向がありました。多くの場合、実際のデータセットでこの状況が発生するのを確認するだけでは不可能である何かをテストしたことを覚えています。テストを行わなかった場合、データセットの破損やエラーの可能性を特定するために必要なエラー検出とロギングを導入していなかったでしょう。TDDはこの部分に適していますが、実際のコードの前後に関係なく、適切なテストセットを作成することがより重要だと思います。

バージョン管理

多くの場合、この部分は省略されます。コードと生成されたパッケージ/実行可能ファイルの適切なバージョン管理スキーマは、順調に進捗を維持するのに非常に役立ちます。以前に取得した結果を作成するために使用されたコードを正確に回復できることは、バグまたは不一致を追跡するときに役立ちます。分岐は、さまざまなアプローチやアルゴリズムを試すときにも役立ちます。

実際の計算で使用するコードには必ずタグを付けてください。バージョンの名前付けについてヘルプが必要な場合は、セマンティックバージョニングを確認してください。

自動ビルド

上記のポイントの当然の結果。ソフトウェアのビルドとパッケージ化のプロセスをできるだけ自動化するようにしてください。ソースと依存関係から最終的なシステムを作成することを簡単にするのに十分なだけ、完全な額を払う必要はありません。ここでの目標は、時間を節約することですが、依存関係やその他の外部を含め、ソースからソフトウェアを再作成する再現可能な手段を用意することです。Groovy、Maven、ant、Scons、cmakeは、ビルド自動化ツールとスクリプトシステムのほんの一例にすぎません。

さらに進んで行きたい場合は、Jenkins、teamcity、その他の継続的インテグレーションシステムをインストールしてください。分散コンピューティングのために複数のサーバーまたはワーカーを維持する必要がある場合は、ボーナスが追加されました。これらのシステムのほとんどには、メンテナンスに役立つ手段があります。さらに、テストの実行を完全に自動化できるため、続行する前に結果を待つ必要がなく、後でコミットしてメールを受信するだけです。テストセットを通過するのに何時間もかかるシステムがありました。この自動化を実装することは、私の時間の最高の投資でした。特に、すべてをビルドするためのスクリプトが既にある場合はそうです。

環境の分離

研究者は、複雑なシステムからプロトコルを介して、目的の変数の単一または小さなセットを分離するのに膨大な時間を費やしています。これは、ソフトウェア開発プラクティスにも拡張する必要があります。DockerまたはVagrantを使用してコンテナー化を確認することもできます。これにより、ソフトウェアが実行される環境をより適切に制御できます。

これが報われる前に大きなチームを持つ必要はありません。私はほとんどの場合一人でしたが、これらを配置することで大きな利益を得ました。心の平安と時間の節約は、私がこれを行うのにかかったオーバーヘッドをはるかに上回っていた場合に限りました。

1. Rを使用できますか？それが目的です。

2. コードはシンプルにしてください。可読性を追求し、問題でない限りパフォーマンスについて心配しないでください。チームが1人の場合でも、プログラマーのチームがお互いのコードにバグを入れないようにする方法が存在します。

3. とはいえ、コーディングの規律は非常に重要です。高度に訓練された高度な科学者や数学者からのコードを見てきましたが、それはひどいです。彼らは完全にフォーマットを無視します。彼らは真空パックされているようにコードを一緒につぶします。それらの変数名は完全に不可解です。彼らはコメントを書いていないか、不可解なコメントを書いているか、コードが別のことを言っている間にコメントがあることを言っている。それらのことをしないでください。あなたや他の人がしなければならない可能性のある将来の変更を常に前に考えてください。