ボーイスカウト・ルール、先に直すか、後から直すか。 - ちなみに

ボーイスカウトルール。 機能追加より、 先に直すか、 後から直すか。— 人生踊れば丸儲け (@tomohi_ro) 2022年4月3日 まれによく目的の変更にリファクタリングを混ぜたプルリクのレビュー依頼を受けるので、そのたびに変更とリファクタリングは分けてねって話をしている。 レビューするときにもdiffが混ざっていて見にくいし、将来的に変更の経緯を追いかけるときにもノイズになってしまう。 コミットが分かれていたらまだマシなんだけれど、そういう場合はたいてい同じコミットに複数の目的が混ざってしまっている。 www.clear-code.com 僕は1コミットには1つのことというルールを出来るだけ守ろうと思って暮らしているのでどちらかというと過激派なのですが、プルリク単位くらいではやることを絞って欲しいとは思っています。 みんな単一責任原則は大好きな気がするけど、コミットやプルリクにも同じ

[onk]

リファクタリングを始めたら思った以上に時間が掛かって締め切りを守れない、を繰り返した結果、後から直すのを他人には言うようになった。（自分は実装が楽しいのでリファクタリングからやるし締め切りも守れません

[sh19910711]

"みんな単一責任原則は大好きな気がするけど、コミットやプルリクにも同じ姿勢で取り組んで欲しい / ボーイスカウト・ルール: 来たときよりも美しく + チーム全員で当たり前のようにやっていくのはなかなか難しい"

[mas-higa]

"より品質の高い価値となってユーザーに届くのではないでしょうか" ユーザには、そこ見えないし、そこにお金払ってくれない。何年もかけてジワジワ効いてくるので、経営者に理解がないと数年後に競合に負けるかも。

[minemuracoffee]

“先にリファクタリングした方が、機能追加も楽になって、結果的に早く価値を届けられるのではと言うことです。 しかもメンテナンスしやすいコードになったということは、より品質の高い価値となってユーザーに届く