研究におけるソフトウェアメンテナンス

研究におけるソフトウェアメンテナンス（Konrad Hinsen 著、2014 年 2 月 26 日投稿） ソフトウェアメンテナンスは、科学ソフトウェアの開発者が日常的に直面する課題の一つです。これは重要な活動ですが、非常に時間を要し、現在の評価制度ではほとんど報われません。大規模なソフトウェアプロジェクトを管理している場合、メンテナンスのための資金調達も通常は困難です。ソフトウェアメンテナンスが困難であり、本質的に科学的関心の対象ではないのであれば、なぜそれが必要なのか、そしてメンテナンスの必要性を減らすために何かできることはないか、自問してみるべきでしょう。 まず、ソフトウェアメンテナンスとは何でしょうか。Merriam-Webster は動詞「maintain（維持する）」を、「修理を行ったり問題を修正したりすることで、（何かを）良好な状態に保つこと」と定義しています。この定義は、機械的な摩耗などにより経年劣化する技術機器にとっては妥当です。しかし、ソフトウェアは劣化しません。したがって、ソフトウェアに適用される場合の「メンテナンス」は、異なる意味を持たなければなりません。合意された定義は見当たらないため、ここでは私自身の定義を示します。 ソフトウェアメンテナンスとは、以下のいずれかの理由でソフトウェアを変更することを指します： * バグの修正。 * 進化する計算環境においてソフトウェアを利用可能に保つこと。 このリストに機能強化を加える人もいますが、それはどの意味においても真のメンテナンスではなく、改善です。特に科学ソフトウェアの場合、新機能の追加はしばしば新しい科学的発見を意味します。 まず、バグについてです。あらゆるソフトウェアと同様、科学ソフトウェアにおいても、将来より良い結果を得るためにバグを修正したいと考えます。しかし同時に、公表された科学研究で使用されたバグ含みのバージョンも保存しておく必要があります。これは単に誠実さの問題であり、科学的記録を保全するためです。もし研究の結果がソフトウェアのバグに影響されている可能性があるなら、その研究を検討する人はそれを把握できるべきです。彼らは、今日改良された後継版だけでなく、当初使用されたものと全く同じソフトウェアにアクセスできるべきなのです。 この理由から、バグを修正することよりも、研究で使用されたコードを保存することの方が実際には重要です。ActivePapers はまさにこの目的を念頭に設計されました。ActivePaper 内のすべての計算データ項目は、それを生成したソフトウェアとリンクされています。さらに、このリンクは公開後は一切変更不可能です。なぜなら、ActivePapers は論文の電子コピーと同様に公開され、DOI を通じて参照されるからです。公開前に不正を行うことは可能です。つまり、詐欺を犯す特定の意図を持って ActivePaper を改変することはできます。ActivePapers はそのような行為をサポートしませんが、かといって詐欺を防ぐための特別な仕組みも備えていません。こうした機能は、来歴情報をハッシュで保護することで追加可能ですが、そうする必要はないことを願っています。 二つ目の問題、すなわち計算環境の進化は、より微妙な問題です。コンピュータの世界（コンピュータ自体、オペレーティングシステム、コンパイラ、言語仕様、ライブラリなど）におけるすべてが急速に変化するのは紛れもない事実であり、その結果、あるソースコードが数年後にそのまま動作しなくなる可能性が高くなります。これには二つの理由があります。(1) 技術的進歩により、人々が求めるより高性能なコンピュータやソフトウェアが可能になること、(2) 計算プラットフォームの安定性に既得権益を持ち、それを実現する力を持つ者が誰もいないことです。ハードウェアベンダーや商用ソフトウェアの供給者にとって、急速な変化こそが顧客に新しいマシンを購入させ、ライセンスを定期的に更新させる最良の方法なのです。 もちろん、計算プラットフォームの安定性に既得権益を持つコミュニティが少なくとも一つ存在します。それは計算科学コミュニティです。もし私たちのソフトウェアを 20 年後にも修正なしに実行でき、同じ結果が得られるなら、私たちは満足するでしょう。私たちはソフトウェアメンテナンスをしたくなく、また大多数の研究開発者は、自身の直接的な個人的ニーズを超えて、自ら開発したソフトウェアを維持することは現実的にできません。ましてや、例えば現在は産業界で働いている元大学院生が残したソフトウェアなど、他人のソフトウェアを誰かが維持してくれると期待するのはさらに非現実的です。 実際には、広く利用されているコミュニティ向けソフトウェアのみが、十分に長い期間にわたってメンテナンスされます。しかし、広く利用されメンテナンスされているパッケージを使用する研究プロジェクトでさえ、通常は何らかのプロジェクト固有のソフトウェアを必要とします。少なくともいくつかのシェルスクリプトは必要でしょう。これが、計算科学研究の再現性が極めて低い理由の一つなのです。 科学コミュニティはこの状況に対して何かできるでしょうか。私は可能だと考えますが、近い将来に行動を起こすとは思えず、楽観視していません。科学者は科学計算のために汎用ハードウェアを使い続ける可能性が高く、这意味着彼らは自身では制御できないハードウェアおよび関連システムソフトウェアの進化を受け入れざるを得ないでしょう。しかし、これらの絶え間なく進化する基盤の上に、少なくとも純粋に計算的な作業部分については、安定したプラットフォームを構築することは可能です。 根本的なレベルでは、チューリング完全なあらゆるソフトウェア記法は等価であり、相互に変換可能です。実際には、パフォーマンス上の制約によりコード変換に限界がありますが、それでもなお、あらゆる種類の underlying ハードウェアやシステムソフトウェアへ効率的に翻訳可能であり、したがって安定性を保つことができるコード表現を定義することは可能です。その実例として、JVM バイトコードと LLVM の中間形式が挙げられます。JVM バイトコードは 20 年にわたり存在し、極めて安定していることが証明されています。LLVM の中間形式は安定性を目的としていませんが、これは LLVM の開発者が将来の選択肢を狭めないよう、安定した表現にコミットすることを望まないためです。Google の PNaCl プロジェクトはこの警告を無視し、LLVM コードを、それが安定していなければ意味をなさないような方法で使用しようとしています。これがどうなるかは時が示すでしょう。 科学コミュニティは、既存のアプローチからの経験に基づき、科学アプリケーション向けに最適化された独自の中間コード表現を定義することも可能です。しかし、前述の通り、これが実現するとは楽観視していません。これには、複数の大規模な研究機関および資金提供組織による、数十年にわたるこのプラットフォーム維持への長期的コミットメントという二つの要件が必要です。一つのプラットフォームを維持する方が、多数の科学ソフトウェアパッケージを維持したり、メンテナンスされないパッケージを絶えず書き直したりするよりも経済的に合理的であると確信しています。しかし、それには科学界では稀なレベルの合意とコミットメントが必要であり、これまで CERN のようなごく少数の大規模施設でのみ実現してきました。 安定したプラットフォームがもたらす重要な利点こそが、最初の ActivePapers エディションが JVM を中心に設計された理由です。残念ながら、JVM は科学計算の分野ではあまり普及していません。これはしばしばパフォーマンスの不足が原因と説明されますが、その議論はかつてほど有効ではなくなっています。また、特に浮動小数点演算に関連するいくつかの設計上の問題也存在しますが、それは人気のある言語である C や C++ についても同様に言えることであり、それが科学者たちの使用を妨げてきたわけではありません。 実用的により有用な ActivePapers の Python 版は、Scientific Python エコシステム（特に Python、NumPy、および h5py）によって定義されたプラットフォーム上に構築されています。このプラットフォームは過去において中程度の安定性を示してきましたが、Python 3 への移行が不安定性をもたらす主要な出来事となりました。科学的な時間スケールにおいて

さらに読む

• SciPy — Wikipedia