ほとんどのエンタープライズアプリケーションコードはダメです。 アプリケーションはバグが多く、速度が遅く、テストが難しく、展開と更新に常に問題があります。 誰も驚かないようです。
しかし、がらくたを書いた人々は驚いています。 かなりの経験を持つこれらの人々は、いくつかの言語を知っており、多くの本を読んで、OOP、SOLID、リファクタリング、パターン、その他のあいまいな単語を知っています。 つまり、この投稿を読んでいる多くの人とほぼ同じです。
壊れた窓の理論
1969年に、実験が行われました。 実験中、2台の同一の自動車が2つの場所に残されました-繁栄したキャンパスと大都市の機能不全のエリア。 機能不全の場所で車がたった数日間立っただけで全焼したのに対して、安全な場所では何週間も放置されたのは驚くことではありません。 しかし、生き残った車でガラスが壊れるとすぐに、この最も繁栄した町の住民は数時間でそれをバラバラにして詳細を覆し、逆さまにしました。
後に、科学者はこの現象を「壊れた窓の理論」と呼びました。 理論によると、障害や規範違反の兆候があると、人々も規則を忘れるようになります。 理論はいくつかの実験的確認を受けており、非常に信頼できると考えることができます。
逆の効果もあります。 秩序を維持することで、他者は秩序を維持するようになります。
これはコードにどのように影響しますか？
企業の開発では、切迫した期限と要件の不確実性が非常に高いため、「迅速で汚い」ことをしているように思われます。 即座に、「迅速で汚れた」アプローチが、クリップボードの継承（コピーと貼り付け）、および壊れたウィンドウの影響により、アプリケーション全体に広がり始めます。
コードの品質に影響を与えるもう1つの要因は、開発で使用されるプラットフォームとフレームワークの複雑さと不完全さです。 このため、コードにはハッキングやばかげた回避策がよく登場します。 時間が経つにつれて、これらのハッキングは良いコードであると思われ始めます。 フレームワークの問題が修正された場合でも、人々はハックを使い続けます。 ところで、これらのハッキングは最終的にフォーラム、ブログ、またはペーストビンを介してインターネットにアクセスし、1つのアプリケーションの制限をはるかに超えて広がる可能性があります。
コードの品質はアプリケーションの品質に影響しないと言えます。 悲しいかな、それがどのように影響するか。 プログラマは間違いを犯します。 コードが悪いほど、新しいエラーを作成しないようにこれらのエラーを見つけて修正することが難しくなります。 締め切りと複雑さを押すと、おそらく良いコードを書くことができなくなり、別のハックが現れます。
オープンソースおよび製品開発では、これはあまり一般的ではありません。 そこでは、品質をより監視し、差し迫った締め切りを減らしています。
コードは人々のために書かれています
多くの場合、プログラマは、プログラムコードが主に人のために書かれていることを忘れています。 単独でプログラムを記述し、1か月後にそれを見ても、なぜこのコードまたはそのコードを書いたのか、そしてそれが何を担当しているのかを思い出せません。
良いコードは、まず、意図を非常に明確に表現する必要があります。 残念ながら、「高速でダーティな」開発方法は、主にコードのわかりやすさに影響します。 リファクタリングを一時停止するより良い時期まで、意図的にコードを遅延させて改善します。 それらの最高の時は決して来ません、そして、コードはソース管理に入った直後に読んで、修正し始めます。
コードに完全に満足している場合でも（ほとんどの場合、プログラマーはあなたのコードに満足しています）、他の人があなたのコードを読む方法を考えてください（ほとんどの場合、プログラマーは他の人のコードに不満です）。
品質へのこだわり
高い生産性と効率を達成する唯一の方法は、すぐに良いコードを書くことです。 コードの品質を向上させる唯一のツールは、あなた自身です。 常に良いコードを作成しようとしない場合、テストも静的分析ツールも役に立たないでしょう。 他のプログラマのレビューでさえ助けにはなりません。 読み取り中にエラーを見つけることができないようにコードを常に混乱させることができますが、コードは非常に重要であり、誰もそれを書き換えることを引き受けません。
まず、構造と命名について考える必要があります。 暗号化された識別子と不明瞭な実行フローを含むコードには、エラーが含まれている可能性があります。 このようなコードは許可しないでください。エラーを修正するよりもはるかに安価です。
コードで意図を明確に表現し、明白でない暗黙的な側面を最小限に抑えます。 コードをできる限り簡潔にしようとせず、できるだけ明確にするようにしてください。
コードを編集する必要がある場合は、ハッキングを作成しないでください。 少し時間をかけて、普通に書いてください。 サポートを保存します。 コードが本当に悪い場合は、「すばやく汚い」ものにし、ハックで大きくなりすぎて、それを捨てて書き直します。 すべてを書き換えようとしないでください。 生産性を考慮してください。プログラマは、通常のペースで1日あたり40〜60行のデバッグされたコードを記述し、加速された速度で120〜200行を記述します（高濃度、明確な目標、何をすべきかは明確です）。
たとえば、要件を明確にするためのプロトタイプなど、「早くて汚い」を自分で書いた場合、コードを実行してすぐにコードを破棄し、通常どおりに書き直してください。
コードの一部を別の場所からコピーした場合、またはインターネットから禁止されている場合は、ソース管理に変更をアップロードする前に、それがどのように機能するかを理解してください。 まったく理解できないコードスニペットを使用しないでください。
常にコードをきれいに整頓し、これを支援するツールを使用してください。 これは行いません-コードはすぐにゴミに変わります。 コード内の問題の密度に関する統計を収集します。これにより、適切なコードの書き方をよりよく理解できます。
コードを読み直してください。 書き込み中は常にリファクタリングします。 「後の」リファクタリングは決して発生しないことに注意してください。
書く前にどのコードを書きたいか考えてください。 コーディング自体は吸収プロセスなので、品質について考える時間はありません。 フローの状態は、表現の自由の状態です。 コードが良好になるように、事前に自己表現を制限する必要があります。
コード品質経済学
誰もがエラーコスト曲線に精通しています。
コーディング段階で検出および除去されたエラーは、テスト中に検出されたエラーの10倍、実動で検出されたエラーの100倍安価です。 歴史上の誤りの実例があり、その修正には数万ドルかかりました。
したがって、開発段階で、および開発者自身の努力によってエラーを排除することが非常に重要です。
最後に
良い完璧なコードを混同しないでください。 完全なコードはありません。理想を追求するために無限の改善に取り組むことは意味がありません。 良いコードとは、読みやすく、理解しやすく、問題を解決し、適切に構造化され、エラーを含まないコードです。 良いコードを書くことはあなたの目標ではなく、あなたの責任です。