ソフトウェア開発の実践に関する未確認の声明を誰かが提供した場合、「引用が必要」と答えますか？[閉まっている]

最近、グレッグウィルソン（ソフトウェア大工仕事の最高科学者）の講義に出席しました。要約から：

ソフトウェア開発の実践についての主張は証拠に基づいているべきであるという考えはまだソフトウェア開発者にとって異質ですが、これはついに変わり始めています：特定のツールまたは実践がソフトウェア開発をより速く、より安く、またはより信頼できると主張する学者は現在ある種の実証研究でその主張を裏付けると期待されていました。

全体として、講義は非常に有益であり、開発への私のアプローチについて非常に深く考えさせられました。特に、私は今、引用を探して多くのステートメントをバックアップしていることに気づきました。以前は、提供された真実を単純に繰り返す習慣に陥っていました。おそらく後で確認するための精神的なメモがありました。

率直に言って、私はだまされていました。

講義からの例を以下に示します。

「コードの25％を超えるリファクタリングが必要な場合、コードを書き直す方が迅速です」。

もっともらしいですが、本当ですか？これを裏付ける研究はどこにありますか？すべての言語に当てはまりますか？等々。

OK、これを極端なものにして、第一原理から自分で導き出さない限り、誰にも信じられないことは十分にあります。その方法は、狂気（または多分数学;-)）です。しかし、誰かが「ねえ、これを[瞬間の言語]で行うことで、生産性を[10の倍数]％で]増やす」という文言であなたに近づいたら、それを受け入れるか、実証済みの証拠を求めるつもりですか？

後者の場合（そしてそうであることを願っています）

1. この証拠をどこで見つけますか？
2. あなたはどのくらい厳しいですか？

要するに、誰かがあなたに未確認の声明を提供した場合、あなたは「要出典」で応答しますか？

この種の声明の問題は、主張を支持する経験的証拠があったとしても、証拠につながる研究があなたの現在の状況に当てはまるかどうかを判断することは非常に難しいことです。

専門職のほぼすべてに警告がありますが、1つの場所でのすべての改善には、どこか他の人に損害を与える可能性があります。

trenchにいる人々は経験を通して違いを知っており、一般に科学的研究を通してそれを証明しようとする資金/時間/資源を持っていません。

科学的研究を通してそれを証明しようとする人々は明らかにそのような研究に専念するリソースを持っているので、あなたに何かを売る可能性が非常に高いので、私はあなたが主張するものにあなた自身の個人的な経験をさらに厳格に適用すべきであると言うでしょう実証研究によってバックアップされます。

誰かが「コードの2％以上がリファクタリングを必要とする場合、それをリライトする方が速い」と言われたら、誰かがあなたに「コードの98％以上がリファクタリングを必要とする場合のみ、それは書き直しが速い」実際の数がどこにあるかは、あなたが何をしているか、そして現在のコードが理想からどれだけ離れているかに依存します。

ある時点の後、核リファクタリングを行う方が簡単であるという考えは多くの場合明らかに当てはまりますが、実際の割合は、（チームの）自分の経験と現在の状況を考慮して検討する必要がある例の多くです。

ソフトウェア開発の実践に関する未確認の声明を誰かが提供した場合、「引用が必要」と答えますか？

いいえ、ここに投稿し、賛成票が出るかどうかを確認します。社会的証拠は、証拠なしよりも優れています！

多くの開発者は、コードとそのコードがサービスを提供する顧客との共同作業の経験に基づいて、瞬間的な判断を下します。

クラスまたはメソッドがバグ修正や顧客の変更要求によって非常に断片化され、維持できなくなった場合、開発者は、長期にわたって時間と労力を節約するという理論の下で、リファクタリングではなく書き換えを決定することがあります、結果のコードはより高品質になるためです。

この種のエクスペリエンスインテリジェンスは、人事部門が「人的資本」と呼ぶものです。これは、経験豊富な開発者を価値あるものにするものの1つであり、優れた企業が人々の寿命を延ばすために努力する理由の1つです。

経験豊富な開発者に、彼らの技術が有効であることの証拠として研究と経験的データを考え出すように依頼することは、公平でも実用的でもありません。経験はそのようには機能しません。それどころか、経験は「フェルトセンス」のようなものです。リファクタリングの世界では、私たちはしばしばそれを「匂い」と呼びます。

最終的に、「コードの25％以上がリファクタリングを必要とする場合、それをリライトするのが速い」などのステートメントは、すべての状況下で機能することが証明できないため、ステートメント[要出典]は本当に独断的なプログラマーに通知する方法です常に「His Way or the Highway」ではないという他者への彼の見解を強要しようとしています。

私はあなたがそれを試してみるまで知らないことなら何でも考えます。ステートメントをバックアップする証拠があるとしても、あなたの主張の利益のために事実を曲げることは常に可能です。インターウェブにヒットするすべての新しいことを試すべきではないと言われています。最善の判断を下してください。覚えておいて、何かが本当であるには余りにも良い音である場合、それはおそらくそうです。なぜ何かを採用する必要があるのか​​、常に自問してみてください。何を得る必要がありますか？将来のビジネスからそれは理にかなっていますか？信仰上の何かを除いて決して盲目にしないでください。

講義の例は、経験則、経験則であり、それ以上のものではありません。それは暗黙のうちに明白なはずです。

ヒューリスティックは他の何かと同じです。特定のコンテキストに依存し、任意の数の無言の仮定に依存し、その有用性は非常に非決定的です。そもそもそれらを定式化するのと同様に、多くのuseful意的な判断がそれらの有用性を見つけることになります。

それは彼らが価値がないことを意味しますか？私はまったくそうは言いません。

ヒューリスティックはNP完全問題に対処するためのアプローチの1つであり、多くの点で、ソフトウェアエンジニアリング自体がNP完全問題です。

場合によります。:)誰かの声明が、繰り返され、反映され、個人的に検証された経験と矛盾する場合、はい、研究の何らかの参照を参照したいと思います。一方で、誰かがあなたが見たものや何度も生きてきたアイデアをエコーし​​た場合、それほど反応は生じません（ただし、そのアイデアが完全であるという意味ではありません）。

一例として、本「Code Complete」は、各章の研究のスコアを引用してそのポイントを示し、時には一見小さな問題（インデントとスペース、または変数名の長さなど）について述べています。そのレベルの詳細と証拠はばかげていると考えて本を紹介した（若い）開発者を思い出します。しかし、数か月後、プロダクションコーディングの経験が増え、いくつかのコードレビューを行った後、同じ開発者の中には、インデントのスペースの数が重要であることを認める誠実さを持ちました。良いコメントが重要です。カプセル化が重要です。などなど

一方、ベンダーが新しいIDEの生産性を50％向上すると主張したとき、私の最初の反応はbull $％^＆！です。

それは無形の変数（科学的に測定する方法のない変数）の多くに依存するものではありませんか？

私の意見では、彼らは感情を測定するための経験的な方法について話している。スポックでさえ達成できなかったこと。=）