みなさんは「割れ窓理論」をご存知でしょうか？
元々は犯罪学の分野で提唱された次のような理論です。
建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される
Wikipedia
一見するとソースコードの扱いとは関係のないように見えますが、大規模なプロジェクトや、他チームから巻き取った案件のソースコードを思い起こしてみてください。
以下のような状況に心当たりはないでしょうか？
- 数千行ある中に一行だけコーティング規約違反を見つけたが、修正コミットを打つのが面倒なので放置した
- 他者のソースをレビューした際に、コメント文の誤字を見つけたが、細かいやつだと思われたくないので指摘しなかった
多くの人が心当たりがあるのではないでしょうか。
プログラムの動作上は問題がないため、コーディング規約違反やコメント文の誤字脱字などは放置されてしまうことが往々にしてあるかと思います。
割れ窓理論的に考えるとこれは良くない兆候です。
その小さな綻びを放置すると、ソースコードの品質に対する意識が低いという象徴になり、やがて重大なバグを引き起こしてしまう可能性があるのです。
犯罪学における割れ窓理論は批判的な意見も多く見受けられますが、ことソースコードの品質という点に関していうと、割れ窓理論は十分に現実に即しているのではないかと思います。
理論や可能性の問題ではなく、これは十分に起こりうる問題なのです。
実際問題、私が携わったプロジェクトでも、ある時点からPEP8(pythonのコーディング規約)違反のソースコードが増え始め、試験の頃には目を疑うような品質の物が出来上がっていたことがありました。
これも初めからソースコードの品質が悪かったわけではなく、Gitのヒストリーでみてみると、本当にある時点からソースコードの品質低下が発生していたのです。
小さな問題を放置することは、チーム内の品質に対する意識低下につながり、その結果、十分に自己レビューもできていないソースを平気でプルリクするような悪しき環境が生まれてしまうのです。
一度このような環境ができて仕舞えば、それを元に戻すのは非常に労力がかかります。
人間の意識はエントロピーのもので、混沌とした状態から統制の取れた状態にするには大きなエネルギーが必要となってしまうのです。
小さなミスを修正するために態々コミットを打ったり、レビュー指摘・再レビュー依頼のやりとりをすることが億劫だというのも勿論分かります。
ですが、チーム内でのソースコード品質に対する意識を高く保つためには、例え小さな過ちであったとしても、見つけたらなるべく早く指摘・修正するべきなのです。
コメント