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

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

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

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

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

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

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つの一般的な正当性は、再現性です。ヴィクトリア・ストッデンは、あなたが言いたいことにもよりますが、興味深いかもしれない再現可能な研究参考文献の長いリストをキュレーションしました。

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

• 計算オープンソースソフトウェアライブラリを成功させる理由は何ですか？
• 科学計算のベストプラクティス

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

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

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

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