20

私はコンピューターサイエンス出身です。背景ですが、私は今ゲノミクスをやっています。

私のプロジェクトには、さまざまなクラスの生物学的サンプル、経時変化データ、マイクロアレイ、ハイスループットシーケンシング ( "next-世代」の順序付け、実際には現在の世代ですが) データ、このようなもの。

この種の分析のワークフローは、私がコンピューター サイエンスを勉強していたときに経験したものとはまったく異なります。UML がなく、思慮深く設計されたオブジェクトが崇高なエレガンスを放ち、バージョン管理がなく、適切なドキュメントがなく (多くの場合、ドキュメントがまったくない)、ソフトウェア エンジニアリングがありません。全て。

代わりに、この分野で誰もが行っていることは、通常は 1 回限りの使用のために、1 つの Perl スクリプトまたはAWKのワンライナーを次々とハッキングすることです。

その理由は、入力データとフォーマットが急速に変化し、質問にすぐに回答する必要があり (締め切り!)、プロジェクトを編成する時間がないように思われるからだと思います。

これを説明する 1 つの例: レイトレーサーを書きたいとしましょう。最初にソフトウェア エンジニアリングに多くの労力を注ぐことになるでしょう。次に、高度に最適化された形式で最終的にプログラムします。さまざまな入力データでレイトレーサーを数え切れないほど使用し、今後何年にもわたってソース コードに変更を加えるからです。そのため、本格的なレイトレーサーをゼロからコーディングする場合、優れたソフトウェア エンジニアリングが最も重要です。しかし、1 つの画像をレイトレーシングするために使用することが既にわかっている場合に、レイトレーサーを書きたいとします。その写真は、市松模様の床の上に反射する球体です。この場合、どうにかして一緒にハックするだけです。バイオインフォマティクスは後者の場合にのみ似ています。

次のステップに必要な 1 つの特定の形式に到達するまで、さまざまな形式の同じ情報を含むディレクトリ ツリー全体が作成されます。後日、このファイルを作成した理由とその正確な内容について説明します。

しばらくの間、MySQLを使用していましたが、これは役に立ちましたが、現在、新しいデータが生成され、フォーマットが変更される速度が速すぎて、適切なデータベース設計を行うことができません。

これらの問題を扱った 1 つの出版物を私は知っています (Noble, WS (2009 年 7 月)。計算生物学プロジェクトを編成するためのクイック ガイド。PLoS Comput Biol 5 (7)、e1000424+)。著者は、目標を非常にうまくまとめています。

核となる指針は単純です。あなたのプロジェクトに不慣れな人でも、あなたのコンピューター ファイルを見て、あなたが何を、なぜ行ったかを詳細に理解できるべきです。

うーん、それは私も欲しい!しかし、私はすでにその著者と同じ慣行に従っており、それでは絶対に不十分だと感じています。

Bashで発行するすべてのコマンドを文書化し、正確になぜそれを行ったのかなどをコメントすることは、退屈でエラーが発生しやすいものです。ワークフロー中のステップが細かすぎます。実行したとしても、各ファイルの目的、特定のワークフローがどの時点で中断されたのか、どのような理由で中断されたのか、どこで続行したのかを把握するのは非常に面倒な作業です。

(「ワークフロー」という言葉を Taverna の意味で使用しているわけではありません。ワークフローとは、特定の目標を達成するために実行することを選択したステップ、コマンド、およびプログラムを意味します)。

バイオインフォマティクス プロジェクトをどのよう編成していますか?

4

3 に答える 3

12

私は研究科学者のチームに組み込まれたソフトウェア スペシャリストですが、生命科学ではなく地球科学に属しています。あなたが書いていることの多くは、私にはよく知られています。

心に留めておくべきことの 1 つは、研究で学んだことの多くは、継続的に使用するためのエンジニアリング ソフトウェアに関するものであるということです。あなたが観察したように、研究科学者が行っていることの多くは1回限りの使用であり、工学的アプローチは適切ではありません. 優れたソフトウェア エンジニアリングのいくつかの側面を実装したい場合は、慎重に戦いを選ぶ必要があります。

戦いを始める前に、自分のアイデアを批判的に調べて、汎用ソフトウェア エンジニアリングについて学校で学んだことが現在の状況に有効であることを確認する必要があります。そうだと思い込まないでください。

私の場合、最初に選んだ戦いは、ソース コード管理の実装でした。バージョン管理が適切に行われていない場合に問題が発生するすべての例を見つけるのは難しくありません。

  • 一部のユーザーは、それぞれが「同じ」コードの異なるバージョンを持つ何十ものディレクトリを持っていましたが、それらのほとんどが独自に行ったこと、またはそれらがそこにあった理由についての最もあいまいな考えだけでした。
  • 一部のユーザーは、有用な変更を上書きしてしまい、何をしたかを思い出せなくなってしまいました。
  • 人々が同じプログラムに取り組んでいるはずなのに、実際には異なる方向に互換性を持たずに開発している状況を簡単に見つけることができました。
  • などなど

情報を収集し、誰が何を言い、どのような代償を払ったかをしっかりとメモしておくと、ソース コード管理でより良い世界を描くのは比較的簡単になりました。

次、まあ、次は自分の次の戦いを選択する必要があります。しかし、科学者や同僚の心に蒔かなければならない疑いの種の 1 つは、「再現性」です。再現性がなければ、科学実験は有効ではありません。彼らの実験にソフトウェアが関係している場合 (常にそうです)、再現性を確保するには注意深いソフトウェア エンジニアリングが不可欠です。これの多くはデータの来歴に関するものですが、それは別の日のトピックです。

于 2010-09-21T12:15:59.357 に答える
1

ここでの問題の一部は、ソフトウェア用のドキュメントと公開用のドキュメントの違いです。

ソフトウェア開発 (および研究計画) の設計にとって、重要なドキュメントは構造的かつ意図的なものです。したがって、データのモデル化、何かを行う理由などです。研究計画を文書化するために、CS で学んだスキルを使用することを強くお勧めします。やりたいことの計画を立てておくと、長い分析を実行している間、マルチタスクを自由に実行できます。

一方、バイオインフォマティクスの仕事の多くは分析です。ここでは、ドキュメントをラボ ノートのように扱う必要があり、必ずしもプロジェクト計画ではありません。何を行ったか、おそらく簡単なコメント (たとえば、データのトラブルシューティングを行っているとき)、および出力と結果は何かを文書化する必要があります。私がしていることはかなり単純です。まず、ディレクトリから始めて、git リポジトリを作成します。次に、ファイルを変更するたびに、それをリポジトリにコミットします。可能な限り、データ出力に名前を付けて、git ignore ファイルにドロップできるようにしています。次に、可能な限り、一度に 1 つのプロジェクトの 1 つの端末セッションで作業し、一時停止ポイントに達したら (一連のジョブがグリッドに送信されたときなど)、「履歴 | 履歴」を実行します。 「-c 8-」を切り取り、それをラボ ノート ファイルに貼り付けます。次に、ファイルを編集して、行ったことに対するコメントを追加します。git add/commit 行を git checkout に変更することを忘れないでください (コミット メッセージに基づいてこれを行うスクリプトがあります)。正しいディレクトリで開始し、外部データが消えない限り、これはプロセス全体を後で再作成できることを意味します。

少し複雑な処理タスクでも、それを実行するためのスクリプトを作成して、ノートブックができるだけきれいに見えるようにします。大まかに言うと、ヘルパー スクリプトは、より大きなプロジェクトではサブルーチンと見なすことができ、少なくともそのレベルまで内部的に文書化する必要があります。

于 2010-10-19T17:05:24.250 に答える
0

あなたの質問はプロジェクト管理についてです。悪いプロジェクト管理は、バイオインフォマティクスに限ったことではありません。バイオインフォマティクスの業界全体が悪いソフトウェア設計に取り組んでいるとは信じがたいです。

プレッシャーについて... 繰り返しになりますが、この世界には、締め切りが非常に難しい企業が他にもありますが、彼らはまだ優れたソフトウェア設計を使用しています。

多くの場合、優れたソフトウェア設計に従うことでプロジェクトが抑制されることはなく、(少なくとも長期的には) 設計と保守の速度が上がる可能性さえあります。

さて、あなたの本当の質問です... 概念実証 (POC) として、コードの残りの部分に影響を与えないコードの小さな部分を再設計するようマネージャーに提案できますが、トラックが動き続けるのを止めるのは本当に難しいです「私たちは何年もこのように働いてきました。私たちは自分たちが何をしているかを知っており、子供に仕事のやり方を教えてもらう必要はありません」と彼が感じても、動揺しないでください。他の人と同じように働くことを学び、彼らの信頼を得たら、たまには自分の仕事をすることができます (正しいことをするための時間と献身があることを願っています)。

幸運を。

于 2010-09-21T11:57:31.000 に答える