タグ付けされた質問 「evidence-based」

7
冗長ファイルをVCSからすぐに削除せず、代わりにコメントで「削除対象」としてマークするのは悪い習慣ですか?
バージョン管理から削除する必要があるソースファイルの処理方法が悪い習慣と見なされるかどうかを知りたかったのです。 その例に基づいて説明します。 基本的にデッドコードであるプログラムのJavaクラスを退屈に整理しなければならなかったので、最近非常に怒った。もちろん、それらは削除する必要がありましたが、私はそのような冗長なものを削除する前に-奇妙なことを言うかもしれません-習慣があります: 私はSVN-> Deleteを介してそのような冗長ファイルをすぐに削除しません(選択したバージョン管理システムの削除コマンドに置き換えます)代わりにそれらのファイルにコメントを入れます(私は頭とフッターの両方を参照します)削除されます+私の名前+日付-さらに重要なこと- それらが削除された理由 次に、保存してバージョン管理にコミットします。次回プロジェクト内の何かをバージョン管理にコミット/チェックインする必要があるとき、SVN-> Deleteを押すと、最終的にバージョン管理で削除されます-もちろん、修正によって復元できます。そのため、この習慣を採用しました。 すぐに削除するのではなく、なぜこれを行うのですか? 私の理由は、少なくともそれらの冗長ファイルが存在した最後のリビジョンに明示的なマーカーを持ちたい、なぜ削除するに値するのかということです。それらをすぐに削除すると、それらは削除されますが、削除された理由はどこにも文書化されていません。私はこのような典型的なシナリオを避けたい: 「うーん...なぜそれらのファイルが削除されたのですか?私は以前はうまく動いていました。」(「元に戻す」を押す->元に戻す人は永遠になくなるか、次の週に利用できなくなり、次の担当者は私のような退屈なファイルの内容を知る必要があります) しかし、コミットメッセージでそれらのファイルが削除された理由に注意しませんか? もちろんやりますが、コミットメッセージが同僚によって読まれない場合があります。(私の場合は死んでいる)コードを理解しようとするときに、最初にバージョン管理ログと関連するすべてのコミットメッセージを確認するのは、典型的な状況ではありません。同僚はログをクロールする代わりに、このファイルが役に立たないことをすぐに確認できます。時間を節約でき、このファイルはおそらく復元された可能性が高いことを知っています(または、少なくとも問題が発生します)。

2
依存性注入を使用すると、ソフトウェアエンジニアリングの成果が向上するという証拠はありますか?
その人気にもかかわらず、依存性注入(および/またはDIコンテナーの使用)が、バグ数の削減、保守性の向上、または実際のソフトウェアプロジェクトの開発速度の向上に役立つことを示す経験的証拠はありますか?

7
問題に対処するためのプログラミングパラダイムの選択に関する経験的証拠
C2 wikiには、オブジェクト指向プログラミングの経験的証拠に関する議論があり、基本的には、権威への訴求以上のものはないと結論付けています。これは、ここでは、2008年の議論で最後に編集されたこのアウトを負担するようです:上の質問OOが古いされているかどうか、関数型プログラミングは悪い選択であるときとAOPの利点と欠点がすべての証拠に頼ることなく、貢献者の意見に答えています。 もちろん、定評のある有名な開業医の意見は歓迎すべきものであり、貴重なものですが、実験データと矛盾しない場合はより妥当です。この証拠は存在しますか?証拠に基づいたソフトウェアエンジニアリングが重要であることは知っていますが、この文脈で実践できますか?具体的には、Pソフトウェアを書くことで解決したい特定の問題がある場合、Pプログラミングパラダイムの選択に依存するような問題解決の結果がどのように決まるかを知ることができる知識、研究、研究がありますか? 「正しい答え」としてどのパラダイムが出てくるかは、特定の研究が注意を払うメトリックス、研究が一定または変動する条件、そして疑いなく他の要因に依存することを知っています。これは、この情報を見つけて批判的に評価したいという私の願望には影響しません。 私は「クランクを回す」ソリューションを探していると考える人がいることが明らかになります-私の問題に関する情報を入れ、その中から「機能的」または「構造化」のような言葉が出てくるソーセージマシンです。これは私の意図ではありません。私が探しているのは、方法についての研究です-ここには入りませんが、問題に関する良い文献がありますが、多くの警告と仮定があります-ソフトウェアの特定の特性は、問題とパラダイムの選択によって異なります。 言い換えれば、「OOの方が柔軟性が高い」または「機能プログラムのバグが少ない」と言う人もいます-(一部)私が求めているのはこの証拠です。残りは、これに対する証拠、またはこれらの記述が真であるという仮定、またはこれらの考慮事項が重要ではないことを示す証拠を求めています。あるパラダイムが他のパラダイムよりも優れている理由については、多くの意見があります。これらの背後にある目的はありますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.