変な条件分岐を消す前に——チェスタトンの垣根と、git blame の使い方

「意味のわからない条件分岐があったので、整理して消しておきました」——新しい現場に入って早々、これをやって痛い目を見た人は少なくないはずです。

垣根は、理由もなく建っていない

「チェスタトンの垣根」という考え方があります。道の途中に理由の分からない垣根があっても、まず「なぜここに建っているか」を調べてから壊すべき、という考え方です。「動いているものに触るな」という現場の格言も、これに近い発想で、原則そのものではなくリスク判断です。理由が分かって、変更する必要もあるなら触ってよい。理由が分からないまま消すと、見えていなかった前提が崩れます。

git blame は、犯人探しの道具ではない

理由を調べる道具として使えるのが git blame です。名前は物騒ですが、実際に見るのはその行が入ったコミットとメッセージです。「なぜこんな変な条件が」の答えは、たいていそこに書いてあります。犯人探しに使う文化の現場では、やがて誰も踏み込んだ変更をしなくなりますが、経緯を辿る道具として使えば、垣根を壊していいかどうかの判断材料になります。

分からなければ、聞く

コミットメッセージにも理由が書かれていないことは珍しくありません。そのときは、周りに聞くのが一番早い道です。「質問できる人」が、実は一番早く終わらせているとおり、遠慮して自分で調べ続けるより、「この条件、経緯をご存知の方いますか」の一言のほうが速く済みます。

新しい現場での確認の順番

新しい現場の最初の1週間で目につく「変なルール」は、たいてい過去に何かの事故を経て置かれたものです。整理したくなる気持ちは分かりますが、まず理由を調べてから、直すかどうかを決める。この順番を守るだけで、常駐先での信用が変わります。

こうした判断は、エンジニアの型の問題集にまとめてあります。