なにそれ？
これは、1982年にジェームズウィルソンとジョージキリングが記事「壊れたウィンドウ」で説明した動作の特殊なケースです。 事実は、誰かが自分の前に誰かがすでにそれらに違反していることを知った場合、確立された規範に違反する可能性がはるかに高いということです。 汚れた壁、汚れたごみ、壊れた窓が中庭に現れると、酔っ払いの会社、廃車、ゴップストッパーなどが磁石のように引き寄せられます。 これを回避するには、芽の小さな違反を絞殺する必要があります。
これはITとどのように関連していますか？
コードの品質が非常に悪い、かなり大きなプロジェクトに取り組む機会がありました。 内部標準はなく、出演者のレベルは非常に異なっていました。 一般的な無関心の泥沼は私を非常に素早く吸い込みました、そして私は流れで泳いで、とにかくコードをぼかすだけでなく、古いものの修正中に新しいバグを植えます。 会社の日付は絶えず壊れていて、時間通りに降伏した単一のマイルストーンではありませんでした。
しばらくして、人事異動が起こり、私の監督の下に、そのような無関心なプログラマー5人のグループがいました。 作品の正面は私に輪郭を描かれ、私の目の前の沼は新しい落胆の色合いで遊び始めました。 しかし幸いなことに、そのとき、ある同僚がこの理論について私に言ったのです。 そして、ここから私が結論を出した。
- 私の部署の開発は別のモジュールに割り当てられました。
- 製品の他の部分とのすべての作業は、規制されたインターフェースを介して行われました。
- ハード標準コードが部門に導入されました。
- すべてのタスクは、必須のコードレビューを通過し始めました。
- 他の部門からのすべての変更は、必然的に監視およびレビューされました。
無関心なプログラマーはあまり好きではありませんでした。 一部のタスクは2〜3回ラップされました。
何人かは解雇され（幸いなことに、私にはそのような権限がありました）、新しい人を募集しなければなりませんでした。 古い沼地のリファクタリングは約1年続き、時には徐々に、時には機能の一部を最初から完全に書き直しました（これを行う前に十分に注意してください！）。 その結果、明確で直感的なインターフェースと理解可能な実装を備えた、アーキテクチャ的に細いモジュールができました。 部門でのプログラミングのレベルは成長し、人々は失敗をしないことを学びました。
しかし、すべてが素晴らしいとは限りません。
部門レベルでは、このアプローチは見事に機能しました。 残念ながら、他の部門は古いスキームに従って作業を続けました。 彼らは、コードの変更のレビューに関して「偏心」に耐えましたが、彼ら自身は古い方法で作業することを選択しました。 コード内のバグの検索は非常に遅くなり、マイルストーンのすべての失敗は日常的なものとしてではなく、「私たちはすべてを行い、それらのために再びファイルになった」と認識されました。 一般に、数年後、会社全体に文化を植え付けることができなかったため、転職しましたが、それは悲しいことです。 それにもかかわらず、私の経験が他の人がそのような企業で生き残り、さらにそれらをより良く変えることさえ助けることを願っています:)
UPD： 「壊れたウィンドウ理論」の実験に関する記事
UPD 2： cruel_clownとLiksysのイラスト
