脱力駆動開発記

ゲームアプリを作るエンジニアの技術メモ

MENU

ボーイスカウト・ルールの重要性

ボーイスカウト・ルール

エンジニアの世界には「ボーイスカウト・ルール」なるものが存在するらしいです。

実際のボーイスカウトの規則には「自分のいた場所は、そこを出て行く時、来た時よりも綺麗にしなければならない」というものがあるらしく、それをエンジニアのコーディングに置き換えて表現したものがここでいうボーイスカウト・ルールですね。
※「ボーイスカウトの規則」と表現することもあるみたいです

myenigma.hatenablog.com
qiita.com

口癖のように使ってる人もいる

前のプロジェクトで一緒に仕事をしていたエンジニアが口癖のように言っていました。
「自分が書いたわけじゃないからって良くないコードを放置しちゃだめだよ。ボーイスカウトルールだよ」的な感じで。

例えば自分が新しい機能を担当したときに既存のクラスを一部使って実装するとする。元の処理を見たら結構汚いコードが書かれている。
そうなったときに、それを見て見ぬふりをするのではなく元の状態より綺麗にして作業に着手しましょう、ということですね。
前述したエンジニアの方が口を酸っぱくして言っていたので、自分は割とその精神が定着していました。

反発も勿論ある

「ただ、人のコードを勝手にいじる」ということに対して反発する人は少なからずいると思います。
(自分も勝手に人にリファクタリングされて「やばかったから直しといたよ」とか言われたら少しイラッとするかもしれません笑)
ただそこはプルリクなんかでお互いが議論して納得する形でよりよいコードに変えていけばいいのかなと思ってます。
実際に前の現場ではコードレビューやプルリクを導入していたので、人のコードに変更を入れた場合はgithubのConversation上で元の実装者とやりとりして納得した上でマージするようにしていました。(元の実装者が居ないパターンももちろん多くありましたが..)
逆にそういった文化がない現場だと、好き放題に人のをいじれるというのは無法地帯になってしまうかもしれません。

明確なアンチパターン

そんな状態で2ヶ月前から参画した直近の現場で驚いたことがありました。
コードにこんなコメントが書かれているんです

//この処理書いた人は割と頭悪い
//なぁにこれwwww

みたいなコメントがあるんです。
そしてこのコミットをした人は本当にただ感想を書いただけでそこを改善する処理は全く書いていない。

既存のコードに対してこういった感想を書くだけ書いて何も手を付けずに立ち去るというのは、結局「この処理は複雑で読みにくいと思うけど僕は何もできませんでした」って宣言しているようなものだと思うんです。

ただその人にも悪気があったわけではなく、プロジェクトの状況が燃えてて疲弊している中でつい見かけた良くない処理に対してキツめのコメントしてしまった、とかもあると思います。
しかし、こういったコメントを見つけてしまうと「ああ、このプロジェクトにはボーイスカウトルールとは真逆をいってるな」と思ってしまうわけです。

メリットを共有することが大事

そもそも「人のコードに手を入れて改善していく」という発想がない可能性があります。
大事なのは技術的負債を皆で返済していくようになると、自分がどれだけ楽になるかというのを共通認識として持つことなのかなと思っています。
今の現場ではプルリクに対するレビューを担当しているので、そういった姿勢をチーム内で共有出来るようになればいいなと思っています。
もしこれを読んでいる方で「こうしたら上手くいったよ」という例があればご教示いただきたいですm(__)m



というわけで珍しく会社で感じたことを書いてみました。明日もがんばるぞい