はじめに

「プログラマが知るべき 97 のこと」の「8. ボーイスカウト・ルール」を読んで考えたことについて書きたいと思います。

ボーイスカウト・ルールについては本当に良い姿勢だなと思っていて、自分自身も意識しているし、チームにもこの文化を創っていきたいなと思っています。

実践していく上で気を付けること、またこれを文化にしていくためにどうしたら良いのかを少し考えてみたので書いていこうと思います。

そもそもボーイスカウト・ルールとは

「プログラマが知るべき 97 のこと」にはボーイスカウト・ルールとは、以下のように定義されています。

モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする

つまり自分が見たコードは見る前よりも綺麗にするということです。

大々的なリファクタや設計のやり直しなどの大きな修正である必要はなく、メソッド名を適切なものにする、役割を持ち過ぎている関数の処理を分割するなどのレベルなどを地道に行っていくことで少なくともシステムがどんどん劣化していくということはなくなっていきます。

このような文化ができてくるととても良いチームになると思うのですが、プロジェクトに追われていると、たとえ簡単な修正でも良いと言われても実践するのは簡単ではないかもしれません。

そこで文化を創っていくには、次のような取り組みが良いのではないかと思います。

チーム内の振り返りなどの時間で各自が「良いな」と思った PR を共有するというものです。

ボーイスカウト・ルールを実践できていると思った PR を共有しながら、具体的にどういった点が良いと思ったのかなどを言っていくことですでに実践している人は続けようとするし、周りも「こうすれば良いのか」「自分もやってみよう」と思ってもらい安くなるのではないかと思います。

PR を共有することは、コードの共同所有の観点やナレッジの共有などのためにも良いことなので是非時間をとってやるべきだと思いました。

ボーイスカウト・ルールは開発者として皆が持つべき素晴らしいマインドだと思いますが、実践する上で注意しなければならないこともあると思います。

それは他人に配慮するということです。

コードを整理して綺麗にしていくのは綺麗にする側は気持ちいいですが、元々そのコードを書いた人からすれば、自分が書いたコードにバンバン手を入れられるのはあまり気持ちの良いものではないと思います。

その際にボーイスカウト・ルール自体は良いことですが、「直してやったぞ感」が出てしまうとチーム内でコミュニケーションエラーが起きかねません。

プロダクションで動いているコードは綺麗だろうが汚かろうが価値を生み出しているコードです。書いた人へのリスペクトを忘れてはいけないなと思います。

ボーイスカウト・ルールについて考えたことを言語化してみました。

自身の頭の整理のために書いているものですが、誰かの参考になれば幸いです。