まれによく目的の変更にリファクタリングを混ぜたプルリクのレビュー依頼を受けるので、そのたびに変更とリファクタリングは分けてねって話をしている。
レビューするときにもdiffが混ざっていて見にくいし、将来的に変更の経緯を追いかけるときにもノイズになってしまう。
コミットが分かれていたらまだマシなんだけれど、そういう場合はたいてい同じコミットに複数の目的が混ざってしまっている。
www.clear-code.com
僕は1コミットには1つのことというルールを出来るだけ守ろうと思って暮らしているのでどちらかというと過激派なのですが、プルリク単位くらいではやることを絞って欲しいとは思っています。
みんな単一責任原則は大好きな気がするけど、コミットやプルリクにも同じ姿勢で取り組んで欲しい。
話はそれたのですが、ボーイスカウト・ルール。
来たときよりも美しくっていうやつです。
言うは易く行うは難しというやつで、簡単に見えてこれをチーム全員で当たり前のようにやっていくのはなかなか難しい。
最初の話から機能変更と一緒にリファクタリングするのはよくないと思っているのですが、じゃあいつするのかと言うと、変更の前か後になります。
なんとなく期日に対するプレッシャーがあると、先に機能を実装してしまって、あとから余裕があったらリファクタするということになりがちなんじゃないかと考えています。
しかしながら、なんで綺麗にするのかというと、今後のメンテナンス、つまり機能追加や不具合修正なんかをやりやすくするためです。
つまり何が言いたいかというと、先にリファクタリングした方が、機能追加も楽になって、結果的に早く価値を届けられるのではと言うことです。
しかもメンテナンスしやすいコードになったということは、より品質の高い価値となってユーザーに届くのではないでしょうか。
あとからリファクタリングするということは、綺麗に出来るコード、つまり綺麗じゃないコードに対して頑張って機能を追加したのだから、複雑度が増してしまっていて変更にも時間がかかるし、不具合が発生する確率が高まっていると思うのです。
そして多くのは場合は「あとでやる」と決めたことは実行されません。
つまりユーザーに対して価値を提供したつもりが、システムとしては価値の毀損を招いているとも言えるのではないでしょうか。
よって僕は機能を追加する前にボーイスカウト・ルールを発動するべきだと思うのです。
