クリーンなコードが開発を改善したことを説得力をもって実証する事例研究はありますか？[閉まっている]

私はプログラマーとしての最初の本当の仕事をしています。私が見るのは単なる「泥の大玉」コードです（有用なコメントもありません）が、きれいなコードをやりたいです。仕方。

私は、クリーンコード（クリーンコードとは何かについてのさまざまな定義がここにあります）の使用により開発と保守性が改善された研究事例を探しています。

Google Scholarをすばやく（しかし決して網羅的ではない）検索すると、Bob MartinのClean Codeを参照する多くの記事が見つかりますが、「clean code」と開発の改善との相関関係をカバーする論文を見たことはありません。

ただし、質問について少し考えてみてください。あなたは開発の改善について尋ねていますが、それはそれ自体がより良いコードを書くだけでなく、コミュニケーション、期待の管理、方法論とプロセスの合理化、テスト、継続的統合、そして本当にソフトウェア開発プロジェクトを成功させるためにどれだけ多くのことが必要なのか、そしてそれを改善することはできないと考えると、箱全体とサイコロです。

ですから、おそらくあなたは質問をすべきです：きれいなコードを書くことは、ソフトウェア開発の改善に貢献するのでしょうか？それに答えるために、私が提供できる唯一の「証拠」は完全に逸話だろう、と私は思うのためのクリーンなコード、それはボブ・マーティン自分ではなく、多くの章が寄与していないだけで書かれているよう本は、優れたリファレンスだろう最も優秀なソフトウェア開発者の数人によって。それが役に立たない場合、おそらく少し冷たいハードロジックが適用される可能性があります。

あなたの家で混乱を作り、それを掃除することを決して得ないならば、あなたの家での生活は雑用になります。物事を見つけるのが難しくなり、動き回るのが難しくなり、あなたが不潔な環境に住んでいるなら、彼らの正しい心の誰もあなたを訪問したくないでしょう。コードでも同じです。コードが混乱している場合、問題を特定することはもちろん、修正することは困難です。仕事をしないかもしれない回避策を正当化するのは簡単になりますが、ねえ、それはすべての古いレガシーのマックを歩いて渡らなければならないことに勝ちますね？結局、家を片付けないように、コードを片付けることは時間と労力を費やし、長い目で見れば困難をもたらします。ただし、コードをきれいに保つと、作業に適したプラットフォームが提供され、リファクタリングとデバッグが面倒にならず、

いいえ、私はあなたに与える直接的な証拠を持っていません、そして、これらは非常に長い間このようなことをしていて、できれば途中で少しソフトウェア開発の知恵を獲得した誰かの考えに過ぎません。:-)

あなたが理解する必要があるのは、平凡なコードを書くことに着手する会社はないということです。問題は、コードの50％が、あなたの会社の平均的なプログラマーによって書かれているかどうかに関係ありません。きれいなコードの利点を説明するとき、あなたは聖歌隊に説教しています。秘trickは、その方法です。ピアレビューツール、静的分析、自動テスト、継続的統合、TDD、スクラム、極端なプログラミングなどに関する調査を行い、問題がなぜ悪いのかを単に説明するのではなく、潜在的なソリューションを提示します。

私はこれがここで穀物に反することを知っていますが、市場投入までの時間、要件を正しくし、適切な資金調達、良いマーケティング、適切な価格ポイント、そして幸運は、コード品質よりもソフトウェア製品の成功にはるかに大きな影響を与えます。

これは、コード品質を無視する必要があると言うことではありませんが、多くの要因の1つにすぎないことを認識する必要があります。

大成功を収めた製品には単純に恐ろしいコードの例が数多くあります（たとえば、スレッド管理をアプリケーションに任せていた元のApple OS）。

悪い構想や高価な製品を克服する美しいコードの例は考えられません。

そのため、市場投入までの時間とかなりのコードの場合、市場投入までの時間を優先する必要があります。

クリーンコードを実際の目標から分離する必要があります。展開後の欠陥修正のコストを削減し、不要な手直しを削減します。「クリーンなコードを作成してバグを少なくする」という話をすると、宗教の話になります。「欠陥率を10％削減して、プロジェクトの2か月分の労力を節約する」という話をするとき、あなたは管理について話しています。クリーンコードは、コードベースの初期品質を改善し、それによって総コストを削減するツールですが、多くのツールの1つです。

次のペーパーでは、コストの観点から最初に正しく機能させることが重要である理由について説明しています。http：//www.cs.umd.edu/~mvz/pub/eworkshop02.pdf

特定の研究については知りませんが、Steve McConnellの研究をチェックしてください。

誰かがそれを持っているなら、彼はそうするでしょう。たとえば、2分間のスキャンでこれが見つかりました（16歳ですが、今日でも関連があります）。

mattnzの答えに追加するために、もしまだ行っていないなら、具体的にCode Complete：A Practical Handbook of Software Construction by Steve McConnellをチェックしてください。あなたのコーディングを改善する可能性が高いという事実に加えて、彼はさまざまなコーディング慣行がプログラムの品質にどのように影響するかについての本全体の数多くの研究を引用しています。

例として（本から）：

別の450のルーチンの別の研究（これは単なる異常な偶然です）により、最高のカップリング/凝集比を持つルーチンは、最低のカップリング/凝集比を持つものの7倍のエラーがあり、20倍のコストがかかることがわかりました修正する（Selby and Basili 1991）。

また、すべてのプログラマーが読むべき最も影響力のある本は何ですか？（この質問に対する答えは最近、不完全に再編成されたと思いますが）