ソフトウェアのベストプラクティスに関する引用可能なリファレンス


14

現在、博士論文を書いています。私は博士号のかなりの部分を既存の科学コードのクリーンアップと拡張に費やし、以前は使用されていなかったソフトウェアエンジニアリングのベストプラクティスを適用しました。これについては論文で書きたいと思います。単純に「ユニットテストを追加しました」と言うのではなく、次のように書きたいと思います。

J. Doeは1975年にユニットテストを発明しました[ 23 ]。Bloggsによる最近の研究ら[ 24 ]のユニットテストは、73%によってソフトエラーの発生率を低下させることが... 234の別々のユニットテストは、Timpkinsによって作成されたのxUnitフレームワークによって管理される、コードベースに追加された示されたら[ 25 ][23][24][25]

広く受け入れられているソフトウェアエンジニアリングのベストプラクティスへの引用可能な学術文献(できれば、DOI、BibTeXなどを入手できる査読付きジャーナルの記事)を探しています。

  • 単体テスト
  • バージョン管理
  • モジュール化/懸念の分離
  • プロファイリング情報に基づいたパフォーマンスプロファイリング/最適化
  • バグ/問題追跡

最初の発明と、その後の有効性の評価に関する情報を探しています。このようなものすべてを1か所にまとめたレビュー記事があれば、さらに良いことです。


1
これは役立ちますか:plosbiology.org/article/…– akid 14
1

参照を追加する目的が、優れた実践が優れていることを読者に納得させることである場合、なぜ優れているのかを直接説明する方が理にかなっているかもしれません。単に参照を与えることは、あまり説得力がないかもしれません。これらのことの多くは、学部のソフトウェアエンジニアリングコースでは一般的であり、標準的な教科書で見つけることができ、必ずしも最先端の研究ではないことに留意してください。
キリル14年

私の経験では、モチベーションと参照の両方が必要です。昨日、同僚と会話をしました(どちらも科学者を練習しています)。彼らは、アドホックなテスト方法論がより効果的であると考えていました(短い答え:そうではありません)。計算科学者が関心を持っていると思われる測定基準の観点から動機を表現することが重要です。よりインパクトのある論文がより速く、より正確な結果が得られます(再現性のある研究に関するリンクを参照)。人々がこれらの点であなたと戦うので、重要な利益がないと主張するので、参照を指してください。
ジェフオックスベリー14年

おそらく、私の論文を検討するのは、計算科学の専門家ではなく、化学または材料科学の教授です。彼らはおそらくコードを書いた経験があるでしょうが、彼らは学生または初期のポスドク自身だったので、ほとんど確実に本格的なコーディングを行ったことはないでしょう。私に必要なのは、「私はこれに費やした私の博士号のその年、私は実際に何か有用なものをやって、ちょうど怠けていなかった」と言うものです
user1915639

回答:


13

Steve McConnellの著書 『Code Complete、2nd edition』には、計算科学者よりもソフトウェア開発者の観点からこれらの問題を論じた広範な参考文献があります。この本は、もう少し古くなり始めており、10年に近づいているので、行動駆動開発のような最近のテスト方法論をカバーしていません。それでも、それは私が知っているソフトウェア構築に関する包括的なレビュー記事に最も近いものです。IEEE Softwareで記事を探すこともできます。

計算科学の面では、おそらく最高の記事は、「科学技術計算のベストプラクティス」で引用されたarXivプレプリントDavidKetchesonのPLoSバージョンでしょう。これは、arXiv参照を引用したり、arXivプレプリントを投稿したりする人が少なく、そのため、「実際のジャーナル記事」を引用している(もちろん、現在議論されている科学出版に関するすべての問題は別として) )がより好意的に見られています(そして、それらの著者がそれをジャーナルに掲載することを選んだのはそのためです)。

DavidKetchesonと私が引用したPLoS論文の著者は、(通常2日間)「ブートキャンプ」を実施して、ソフトウェア開発のベストプラクティスと科学者にとって有用な計算スキルを科学者に教えるSoftware Carpentryと呼ばれる組織の一部です。計算科学者)。Software CarpentryのWebサイトには科学のソフトウェア開発に関連する広範な参考文献あります。これらの問題に興味がある場合は、それらに連絡することをお勧めします。さまざまな能力でボランティア活動を行うために、ソフトウェア開発のベストプラクティスの支持者を常に探しています。(免責事項:私はSoftware Carpentryでボランティアをしています。)

ソフトウェア開発のベストプラクティスに従事するもう1つの一般的な正当性は、再現性です。ヴィクトリア・ストッデンは、あなたが言いたいことにもよりますが、興味深いかもしれない再現可能な研究参考文献の長いリストをキュレーションしました。


「ソフトウェア大工」の読書リストは役立つようです。
user1915639 14年

6

これらのアイデア/実践のそれぞれの起源についての言及はありません。しかし、ここに非常に最近の関連する参考文献があります:


私は間違いなくこれらの参考文献の最初の2番目です:-)完全な情報はWolfgang Bangerth、Timo Heisterです 計算科学と発見、vol。6、記事015010(18ページ)、2013年
ヴォルフガングバンガース14年

-2

私見私は科学的に証明されたアプローチの文脈で「ベストプラクティス」を引用することに細心の注意を払うでしょう。ほとんどのプラクティスは、さまざまなアプローチの厳密なテストから派生するのではなく、「それらのプロジェクトに関わる第一人者として認識される一連のプロジェクトで機能すると思われるもの」に由来します。ソフトウェアエンジニアリングには、「ベストプラクティス」の参照可能なリストがあると述べるにはあまりにも多くの変数とヒューマンファクターがあります(たとえば、あるプロジェクトで機能するプラクティスは別のプロジェクトでは完全に失敗します)。

私はあなたのプロジェクトに必要なもの、それがなぜ必要なのか、そして使用されたメソッドへの参照を追加し、なぜあなたがそれらを使用したのかを述べてアプローチします。

また、あなたの主張を述べるための参照よりも、定量化可能な結果を​​報告することに傾注します。たとえば、ユニットテストで100個のバグが発見された場合、そのうち10個は以前に公開された結果に疑問を投げかけるほど深刻です。これは、ユニットテストの起源を知っているという文よりも、博士号に記載する方がはるかに強力な文です。

編集:(修正されたタイプミス)-次の質問に答える-私はしばしばソフトウェアプロジェクトの例えとして子供を育てる。平均またはテスト済みのサブサンプルで機能するため、1つの方法で子供を育てようとすると、子供がテストされたものと同じである限り機能します。多くのメソッドを理解し、インスタンスで機能するメソッドを適用する方が適切です。はい、単体テストは証明されている場合がありますが、単体テストに基づいて単体テストを適用すると、プロジェクトが遅れて市場に出てしまい、その目標に失敗する可能性があります(目標である場合)。私の意見では、メソッドを適用して結果を取得し、その結果の結果を与えることは、他のプロジェクトに基づいて試したことをリストするよりも論文で優れていると言っています-もちろん、論文のトピックが方法論を測定している場合を除きます:)


1
実際、研究では、単体テスト、ペアプログラミング、デバッガーを使用したプログラムのステップ実行、正式なコードレビューなどの欠陥検出戦略を比較し、その有効性を評価しています。あなたは正しい、それぞれの戦略にはその場所がある。ソフトウェア開発コミュニティは、文献でこの点を認識しており、さまざまなタイプのプロジェクトに最適なものを提案しています。「あまりにも多くの変数と人的要因」が実際にベストプラクティスを策定する際の障害である場合、それらは医学や、同様の複雑な問題を抱える他の分野にはありません。私はあなたの議論を買いません。
ジェフオックスベリー14年

ドロドロ素敵なタイプミスであるあなたの博士課程で、より強力な声明は、」
デニス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.