腐っていくとき

English version.

いろいろなレポジトリでコードを書いていて、なんか心地よくない、気持ち悪いと思ったことはないでしょうか？自分もいくつかそういうレポジトリを見てきましたし、自分でそういう場を作ってしまったこともあるな、と思っています。

一般的にその感じを「腐っている」と表現されることがあり、今回のブログでは自分の体験を織り交ぜながら、その腐っていく過程、その小さな症状、そしてその対処法について書いていきたいと思います。

割れ窓理論

もちろん最初から腐っているレポジトリというのはないはずで、最初にファイルを作ったとき、最初のコードを書いたとき、最初の自動ビルドを作ったときというのはすごく綺麗な状態だと思います。多分、自分の中でも最高なコードを書けているのではないでしょうか？
ただ、時間が過ぎていき、自分や自分のチームメンバーがコードを書き加えていって、期日も迫ったりしてくると、ちょっとだけ今までの質に届いていないようなコードが入り込む瞬間を感じると思います。期日も迫っていて直す時間もないので「後で直そう」と思うかもしれません。正直、ただの if 文でだし大して悪いものでなはない、と自分に言い聞かせつつも、「なんかちょっと違うな」と思っている自分がいます。
それだけであれば確かに良いかもしれません。問題は、そのコードで終わりではないことです。そのコードを見たチームメンバー（自分も含め）が「それでも良い」と考えてしまい、同じようなコードを書いてしまうことです。おそらく同じような if 文を書いてしまうと思います。 これを５回も繰り返したら…… 腐ったコードの出来上がり です。

いわゆる 割れ窓理論 というやつですね。割れ窓理論では、建物の窓が割れていると、すぐに他の窓も割れてしまうということを表現しています。最初に出てきた悪い習慣1つが次の悪い習慣を生み、最終的には大変なことになるということを表現しています。

小さな腐りの初期症状

上の例で、腐っていくときの初期症状が少し垣間見えると思いますが、もう少し例を挙げてみます。

• 悪い命名：メソッドやクラスに対して良くない名前をつけてしまうことで、簡単にやりがちです。最初は大したことないと思っていても、それを見たチームメンバーが同じような名前をつけてしまい、どんどん波及していってしまいます。

• 使われていないファイル：以前の実装の名残りや、参照されていないクラスなどの残骸ですね。他のチームメンバーが見つけてしまい、使われている実装と勘違いしてしまうことがあるため、実は結構危険な腐り方です。

• 放置された警告：コードをビルドするときや実行するときに大量に警告が出てくるのを目の当たりしたことがあると思います。エラーなら実行が止まってしまったり、そもそも動かなかったりするので対応すると思うのですが、警告では作業の障害にはなりません。最初に出てくるやつは見逃してしまうと指摘されたりするため対応する人が多いと思うのですが、1つ見逃すと、残りはどんどん見逃されてしまい、大量に警告が出てきても誰も対応しない状態になってしまいます。

• 古いREADME：これはあるあるだと思います。READMEは新しいメンバーが入ってきたときにキャッチアップしてもらうために必要なものであり、実はとても大切です。しかし、開発が進んでいくと、READMEを更新するのを忘れてしまうことが多いです。

ほんの一例ですが、雰囲気は分かっていただけたのではないでしょうか。繰り返しになりますが、腐りは大したことないと思っていた小さいものを見逃すところから始まります。

大きく腐ってしまったとき

次に腐りを放置してしまったがために、大きく腐ってしまったときの話をしたいと思います。

以前、自分が所属していたチームでは、チームメンバーのエンジニア体験を良くしようという意識があまりなく、チームメンバーの多くは「自分の仕事だけやる」という考え方でした。そのため、腐りがどんどん入り込くような状態になっていました。
その中でも特にひどかったのはGitのブランチが大量にあることでした。チームメンバーは20人ほどだったのですが、レポジトリにはブランチが 250 個も存在しているような有様です。原因は辞めてしまった人のブランチや、忘れられてしまったブランチ、レビューされていないPRのブランチなど様々です。
また、あるAPI開発で新しいAPIバージョンを切っているにも関わらず、そのコミュニケーションがなされていないため、同APIの旧バージョンのものに変更を加えて行っていったりもしていました。

ただ、そういう状態である中、自分として一番ひどいなと思ったのは、ときどきあるチームメンバーが「ブランチを掃除したほうが良くないですか？」という話を出しても、チームメンバーの反応がなかったことです。
腐りがコードからチームに感染ってしまったのかもしれません。

腐りを直す方法

直前の例では自分には正す気力もなかったのですが、もし今直せ、と言われたら、まずは小さなことを直すことから始めていたと思います。コードのちょっとしたタイピングミスを直す、ドキュメントを追加する、READMEを更新する、コンパイル時の警告を消すなどです。オススメの条件としては、

• 直すのが簡単（1時間以内で終わるものとか）

• 揉めるような内容ではない

• 気付いてもらいやすい

最初の2点は言わずもがなかもしれません。なるべく簡単に直せるもので、他の人と揉めないようものが良いと思います。3点目は、気付いてもらいやすいものを直すことで、他のチームメンバーが気付いて、自分も直してみようかな、と思ってもらえるようにするためです。
なお、この前提はチームメンバーもグッド・プラクティスは真似してくれる、という性善説に立っています。一人真似してくれれば、他の人も真似してくれる可能性が上がります。小さいものでもいいから直すことの狙いは、これにより良い循環が生まれることにあります。一人ができることには限界がありますが、他の人も巻き込めると、大きく変わってきます。

このブログを書き始めてから何度も同じことを書いてしまっている気もしますが、容易なことではなくて時間もかかります。もちろん、一番良いのは最初の腐りが入り込まないようにすることですが、一度入り込んでしまったら、それを直すのにも時間と労力をかける必要があります。