汚いコードは綺麗にならない

2020年9月2日

先日のローンチ寸前のプロジェクトのコードレビューをして、そのコードの汚さに叱責しました。

「汚いコードは一度書いちゃうと綺麗になりません。」

なぜか。

一度書いたら綺麗にする機会は来ない

と思った方がいいです。

そもそも一度書かれたコードを直したがる人はいません。
バグフィックスなら別ですが、単体テストをクリアしたコードあえてリファクタするのは手間ですし、ローンチして運用に入ってしまったコードをバグも出てないのに修正するのは単純にリスクがあります。

コードレビューや自動テストの文化がしっかり根付いてるところなら、この部分は回避できるかもしれませんが、所感ではそんな現場はまだまだ少ないと思ってます。

経験上リリース後のプロジェクトのコードが綺麗になったことは一度もないです。

汚いコードは増殖する

割れ窓理論というものがあります。
建物の割れた窓を放置しておくと、その周りの窓もどんどん割れていくという話です。

これはプログラミングに関しても言えることで。
あるプログラマが汚いコードを書くと、別のプログラマがそれをコピペしてまた汚いコードが増えていきます。
また、汚いコードが増えると他のプログラマもこれぐらいラフな書き方でも問題ないと思うようになり、新たな汚いコードが生まれます。

大規模開発で関わるプログラマの人数が増えれば増えるほど顕著になり、最初にサンプルにされるコードを書く人の腕が結構重要だったりします。

とにかく、プロジェクト内でそのようなコードを見つけたら広がる前にすぐ駆逐したほうがよいです。

結論：最初から綺麗に書こう

じゃあどうしたらいいのかって話になりますけど、たとえ納期に追われてようが、書いてるのがテストコードであっても最初から綺麗に書きましょうって話になります。

ツールを使ってコードフォーマッタを強制したり、DOCコメントの自動生成をするのもよいでしょう。

月並みな言い方ですが、プログラムは書く時間よりも読まれる時間の方が圧倒的に多いのですから、読みやすいコードを務めて書かなければなりませんよね。

---