コードはどんどん汚くなっていく
プロジェクトのスタート時にどれだけ入念に設計をしてコードを書き始めたとしても、プロジェクトの年数が経つにつれて、コードの状態は悪くなってきます。
- 新機能追加
- 既存仕様の変更
- メンバーの入れ替わり
- リリース日が変更出来ないため、テストを書く時間がない
などなど...
コードの状態が悪くなっていく原因は多岐にわたります。
つまり、何も考えずに開発を続けていくと、気づいた時にはコードは汚れ切った状態になっている可能性があります。この状態となってしまったコードを元の綺麗な状態に戻すのは非常に困難ですし、時間がかかります。また、新機能追加や仕様変更をしていくのも初期の状態と比べると非常に難しく、多くの時間を必要とすることでしょう。
では、プロジェクトの偉い人に相談をして「コードをリファクタングしたい」と伝えたところで、その願望が叶えられることはあるのでしょうか。残念ながら、それはほとんどありません。偉い人がエンジニア畑の出身で理解がある場合は可能性があるかもしれませんが、基本的にはリファクタングはユーザーには直接的には何の利益もないので、了承を得ることは難しいです。
どうすればいいのか
こちらの書籍を読んでいる中で、ボーイスカウト・ルールというものが紹介されていました。
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com
(実は今だけ全て無料で公開されているので、読めちゃいます👀)
ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。
つまり、何かコードに手を加える時に、過去に書かれたコードで以下のような条件に当てはまるのであれば、リファクタリングしてあげます。
- 何かしら気になる箇所
TODOコメントが記述されている箇所- テストが十分に書かれていない箇所
- 処理が複雑な箇所
- 共通化されていない箇所
などなど...
少しずつでもコードを綺麗な状態にしていければ、やがて、塵も積もれば山となるの如し、コードの状態はどんどん良くなっていきます。リファクタリングの許可を偉い人に取らずとも、普段の業務に+αでボーイスカウト・ルールを意識すれば良いのです。リファクタリングは長期的に時間を取って、行うよりも、コツコツと実行していくのが良いとこちらの書籍でも言及されていました。
少しずつであっても改善をしていくことには価値があります。キャンプの古い格言に、キャンプ場を去るときは、来たときよりもきれいにして帰ろうというのがあります。駄目なコードを見かけるたびに少しずつ改善をしていけば、やがて問題はなくなっていくでしょう。
実際にチームにボーイスカウト・ルールを取り入れてみた感想
新機能追加のPRやバグFIXを行う際に、過去に記述されたコードで気になった箇所があれば、少しで良いので、手が加えられそうであれば、修正をしていきましょう！とお願いをしました。まず「過去のコードに手を加えて良い』ということに対して、メンバーが積極的ではなかったことに気づきました。本番環境で問題なく稼働しているコードに手を加えることに、抵抗があったようです。(自分も含めて).
始めた当初は関数名や変数名の更新程度でしたが、次第に各所に存在していた重複する関数がモジュールになって共通化されたり、テストケースの追加など、リファクタリングの規模が大きくなってきました。
このまま続けていけば、現状、我々が抱えている、新機能の追加がしにくいと問題は解決されそうです🙇♂️
