かつて、研究者は、都市の一部の地域では、近くにある建物の中で、手入れの行き届いたものもあれば、廃darkや暗い廃ruになったものもある理由を見つけ始めました。 これらの研究の結果は、壊れた窓の効果の理論につながりました。
この理論によると、十分に長い時間（たとえば、1週間または2週間以上）交換されない少なくとも1つの壊れたウィンドウの出現により、次のウィンドウがすぐに壊れ、次に別のウィンドウが壊れる可能性が高くなります。 、最終的に建物全体の放棄につながります。
手入れの行き届いた建物の窓を壊したことのない人々でさえ、すでに多くの壊れた窓がある建物の窓に石を取り、投げることができます。
この建物の従業員または居住者は放棄の感覚を持っています。 彼らはその純度を監視するのをやめ、ごみを出し始めます。 建物が完全に放棄されると、そこに住んでいた人々はそこを去ります。 そのような建物は、ホームレスの人々が集まる場所になる可能性があります。
ある実験では、未使用の車は数ヶ月間放置されました。 しかし、1つの窓が壊れるとすぐに、車は数時間で部品ごとに分解され、逆さまになりました。
また、路上でのゴミの出現は、この理論に起因する可能性があります。 人がゴミが横たわっているのを見ると、ビンとの会議を待つよりも、何かを投げる方がずっと簡単です。
この理論を使用して、ニューヨーク警察は、大きな違法行為を回避するために、違法行為の小さな兆候（壁の落書きなど）を積極的に抑制し始めました。
一般的に、この理論は私たちの生活の膨大な数の側面に適用できます。
これはプログラミングとどのように関係していますか？
直接。 アプリケーションの設計またはコード自体に「壊れたウィンドウ」を残すと、後続のコードを記述するときに、プログラマーは「システムは不注意に作成されます。 このコードを不注意に書いても、それ以上悪くなることはありません。」 私は自分自身や他の多くのプログラマーでそのような考えを目撃しました。 その結果、システムは不注意に記述されたコードの山に変わり、状況は時間とともに悪化します。
ほとんどの場合、これはチームが終了し、次の世代のプログラマーに恐怖を植え付けるコードを残します。プログラマーはすべてのコードを書き直すか、失敗した場合はこの会社に留まらず、すぐに出発します。
非常に高度なケースでコードを書き換えることが唯一の方法です。 完全に最初から書き直すべきではない可能性がありますが、段階的に書き直すことで状況を改善できます。 そうしないと、プロジェクトは最終的にコードの放棄されたブロックに変わります（もちろん、プロジェクトが「一度限り」でない限り）。
ところで、ほとんどの場合、この一見必要な状況の修正は、管理者によって正確に妨げられます。 ここに彼らの判断の例があります：「すべてのプログラマーは、以前のプログラマーのコードを批判し、そして/または常に理想に近づける準備ができています。」
時間をかけて状況を修正することは、より高価になります。コードを書くほど、書き直されてテストされます。 したがって、コードの書き換えにつながるよりも、「壊れたウィンドウ」に気づいたらすぐに復元することをお勧めします。
さらに、開発を目指している自尊心のあるインテリジェントプログラマーは、劣化の感覚が現れているため、「壊れたウィンドウ」の破壊のためにまっすぐに転がるプロジェクトでは動作しません。 （ほとんどの場合、これは単なる感覚ではなく、たとえそれが劣化ではなくても、間違いなく開発ではありません。）同時に、平凡なプログラマーは、実際にはコードの品質を気にしません。 賢いプログラマーが去り、平凡なプログラマーが残るという事実の結果として、結成されたチームはこれらの非常に平凡なプログラマーで構成されます。
経営陣が犯すよくある間違いは、そのようなプロジェクトの作業に耐えることができない「弱い」プログラマーであると信じることであり、残りは「強い」ものです。 しかし実際には、ほとんどの場合、すべてが正反対です。
どうする？
プロジェクトに「壊れたウィンドウ」を残さないでください。 それらに会ったら、すぐにそれらを訂正するためにいくつかのアクションを取ります。 この場合の不活動でさえ、非常に不快な結果につながる可能性があります。
ソース
- ウィキペディア：壊れたウィンドウの修正 （そこからの写真）;
- 実用的なプログラマー：ジャーニーマンからマスターへ 。
- 自分の経験と知識。