🐈

「来たときよりも美しく」ボーイスカウトの規則が大事

2022/07/21に公開

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

有名なエンジニア本の「プリンシプルオブプログラミング」の中の101の原理原則の中の一つです。
その中ですぐに行動に移せて、プログラマーとして大切な心構えを持つことができます。

ボーイスカウトの規則　＝　「来たときよりも美しく」という意味で間違いないでしょう。

既存の実装の修正をする時は予期せぬバグが怖いため、自分の修正する箇所しか触らないプログラマーの方も多くいると思います。
この規則はせっかくコードを触るなら読みにくい箇所やちょっとしたリファクタリングをしてから帰りましょうという心構え（ルール）を具現化したものです。

例えば大規模な修正ができなくても以下のようなことは簡単にできると思います。

これだけ意識するだけでもコードが徐々に綺麗になっていきます。（メインの修正箇所により汚くなってしまうこと考慮しない場合ですが、、）

簡単なものから以下のような大きめの修正も余裕があったらできるかもしれません。

もちろん私はエンジニア歴が2年目ですので、勝手に大改修とかできるレベルではありません。
しかし、少し気になる点があれば相談しに行ったりしています。（割と勝手に改修していますけど）

「遊んだ後は来たときよりも綺麗にして帰る」と子供のときに散々言われたかもしれません。
その教えをプログラミングにも転換してみるだけで、少しずつレベルを上げることができます。

ざっと私が考えたボーイスカウトの規則のメリットを挙げてみます。

徐々にコード品質が上がっていく
大規模リファクタリングよりコストが掛からない
リファクタリングという作業が嫌な人でもリファクタリングしてくれる
コードを綺麗に書くことができるようになる
大体こんな感じだと思います。
もちろん小さなリファクタリングをするにはユニットテストがしっかり書かれていないと不安なところもあります。
ですので、テストをしっかりと書くという心構えも出来上がるのではないでしょうか。

メリットだけかと思いきやデメリットも少々あります。

タスクの範囲外による修正によりMRが汚くなる
予期せぬバグが生まれる可能性は少なからずある
やはり自分のメインのタスク以外を修正するので、「こういった理由でここを修正しました〜」みたいな説明をするコストもかかっちゃいますよね。
ですので、チームで決まり事を作って進めていくのが重要だと考えています。

明日からすぐに実践できる良い規則だと私は感じています。
意外と先輩方もこの規則を知らない人も多いのではないでしょうか。

知っとくだけで周りのエンジニアとちょっと差を付けれるので、ぜひ明日から実践してみてください！