リファクタリングはコードだけの話ではない
ソフトウェアエンジニアにとって、リファクタリングは身近な言葉です。
ざっくり言えば、動きを変えずに中身を整えることです。
たとえば、こんなコードがあったとします。
def calc(x, y)
x * y
end
動きは分かりますが、何を計算しているのかは少し読み取りづらいです。
これを次のようにすると、動きは同じでも意図が伝わりやすくなります。
def calculate_total_price(unit_price, quantity)
unit_price * quantity
end
この変化は、ただ名前を長くしただけではありません。
未来の自分や次に読む人に向けて、「これは何をするものなのか」を渡しやすくしています。
最近、この考え方はコードだけではなく、日常や仕事にも使えるのではないかと思うようになりました。
現実世界にも、動きは変えずに整えたいものがある
日常や仕事の中にも、動いてはいるけれど少し読みづらいコードのようなものがあります。
たとえば、
- なんとなく続けている朝の準備
- 毎回探している書類やリンク
- 口頭だけで伝えている作業手順
- 何度も同じ説明をしている業務
- いつも後回しになる振り返り
どれも、完全に壊れているわけではありません。
ただ、少しずつ疲れを生んでいます。
こういうものを一気に変えようとすると大変です。ですが、リファクタリングのように「動きは変えずに中身を整える」と考えると、少し取り組みやすくなります。
本質を残して、やり方を変える
リファクタリングで大事なのは、全部を壊すことではありません。
残すべき動きは残しながら、読みやすさや変更しやすさを上げることです。
現実世界でも同じだと思います。
たとえば、毎朝の情報収集を考えてみます。
Before:
ブラウザを開く
ニュースサイトを開く
技術記事を探す
気になったものを読む
どこかで時間切れになる
After:
読むサイトを3つに絞る
気になった記事はあとで読むリストに入れる
毎週1回だけ振り返る
やっていることは「情報を集める」のままです。
でも、流れを整えるだけで迷う時間が減ります。
これは、現実世界のリファクタリングだと思っています。
変える前に、残すものを決める
何かを改善しようとすると、つい全部変えたくなります。
ですが、全部変えると疲れますし、何が良くなったのかも分かりにくくなります。
まず決めたいのは、残すものです。
- 何のためにやっているのか
- どの価値は残したいのか
- 何が今うまくいっているのか
- どこだけがつらいのか
これを見ないまま変えると、必要なものまで捨ててしまいます。
仕事でも同じです。
会議が多いから全部なくす、ではなく、
- 何を決めるための会議か
- 事前共有で済む部分はどこか
- 同期して話す価値がある部分はどこか
を分けるほうがよいです。
要件定義：具体と抽象を往復する仕事 と同じで、抽象的な目的と具体的な手段を分けると、判断しやすくなります。
小さく整えるほうが続きやすい
リファクタリングは、小さく進めるほうが安全です。
現実世界の改善も同じで、一気に変えようとすると続きません。
まずは、こういう小さなところからでよいと思います。
- よく使うリンクを1か所にまとめる
- 毎回書く文章をテンプレート化する
- 迷う作業をチェックリストにする
- 何度も探すファイル名を変える
- 週1回だけ振り返り時間を置く
小さいですが、何度も通る道なら効果は出ます。
やる気に頼らず生産性を上げる にも近いですが、気合いで頑張るより、迷いが減る形に整えるほうが続きやすいです。
リファクタリングしないほうがよいものもある
何でも変えればよいわけではありません。
中には、あえてそのまま残したほうがよいものもあります。
- 思い出があるもの
- 人との関係に関わるもの
- 変えると混乱が大きいもの
- まだ目的がはっきりしていないもの
コードでも、理由なく大きく書き換えると危険です。
現実世界でも同じで、変える前に「これは本当に変えるべきか」を一度考えたいです。
明日からできること
まずは身近なところを1つだけ見直すのがよさそうです。
- 最近よく迷っている作業を1つ書き出す
- その作業の目的を書く
- 残したいものと変えたいものを分ける
- 5分でできる改善だけ試す
- 1週間後に楽になったか見る
このくらいなら、生活や仕事を壊さずに試せます。
まとめ
リファクタリングは、コードだけの話ではありません。
動きは変えずに中身を整える。
本質は残して、やり方を変える。
未来の自分が扱いやすい形にする。
この考え方は、日常や仕事にも使えると思っています。
まずは小さな不便を一つ選んで、現実世界のリファクタリングを試してみたいです。