プログラミングの原則の1つ「ボーイスカウトの原則」が素敵すぎた

みなさん、「ボーイスカウトの原則」というプログラミングの原則をご存知でしょうか？

僕がこの原則を見つけたのは「プリンシプルオブプログラミング」という本です。この本には101の原理原則が書かれてあるのですが、僕が一番好きな原則がこの「ボーイスカウトの原則」です。

ボーイスカウトの原則とは

ボーイスカウトの原則とは一言で表すと「来たときよりも美しくを実行しましょう」という原則です。

つまり、私達が新規開発や仕様変更・バグ修正などでソースコードを変更する際に、どこか1つでも良いからコードをきれいにして、自分が作業する前よりも作業した後の方がソースコードが綺麗になっているという状態を目指しましょうということです。

コードを綺麗にする例としては例えば下記のようなものが挙げられます

• 変数の名前を変える
• メソッド分割する
• クラスの責務を整理する
• 重複を排除
• if - elseを見やすくする

クラスの責務を整理するという少し大きめなものから、変数名を変えるというような小さめのものまでありますが、そのときの余裕に応じて対応するレベルを変えると良いでしょう。

大リファクタリングよりお手軽に出来てシステムの品質が徐々によくなる

リファクタリングやリアーキテくティングをするとなるとだいぶ労力がかかってハードルが上がってしまいますが、毎回の作業でちょっとずつ綺麗にするだけならさほど労力はかかりません。

塵も積もれば山となる的な思想なので品質がよくなるスピードは当然遅いですが、お手軽さはかなりメリットだと思います。

デメリットとしては、新規開発・バグ修正の本タスクとは別の部分のコードを触ることになるので、プルリクが汚くなります。どれが本タスクのもので、どれがソースコードを綺麗にした部分なのかがわからなくなります。これはチーム内でルールを決めるかなんかして柔軟に対応するしかないです。
またユニットテストを書いていない場合、ボーイスカウトの原則を適用してソースコードを少しずつ良くしようとしてコードを変更したことに起因するバグが発生する可能性があります。必ずユニットテストを書いてバグに気づける環境を作っておきましょう。

終わりに

リファクタリングって新しいものを生み出してないので重要視されない傾向にありますし開発者的にもちょっと退屈に感じられる部分があるかもしれませんが、ボーイスカウトの原則を適用すれば日々少しずつ改善されるのでストレスなく良いシステムになるかと思います！