リファクタリングは思考のツール

リファクタリングは、
機能を損なわずにコードを良くするもの!?

いえいえそれだけじゃない。

リファクタリングは「思考のツール」でもあります。
意気揚々とプログラミングしていて、
ふと壁にあたって熟考が必要になったとき、
jfluteはおもむろにリファクタリングします。

ここでいうリファクタリングって、
構造をごっそり変えるとか大げさなものではなく、
メソッド構成に変数名の精査やロジックの順序など、
多岐にわたる数多くの細かい精査。

そこまでは、全体構成を掴むためにも、
全速力でロジックを積み上げていきます。
「この方法で本当に実現できるのか!?」
これでいいのかわからない方法で丁寧に書いていって、
やっぱりだめだったーっていうと時間がもったいない。
それを早く確認するためにもスピードが必要です。

その実現可能性の確証度合い次第ですが、
時には、もうメソッド名を xxx とかにして進んだり。
中途半端にそれっぽい名前は逆に付けません。
へたに溶け込んじゃって後で忘れてしまうから。
aaa とか bbb とかなら目立ってしょうがない。

ふと壁にぶちあたる。
うーんとパソコンの前でうなってもしょうがない。
リファクタリングを始める。

壁を越えるためには今まで積み上げてきた
プログラムを振り返る必要がある。どのみちね。

リファクタリングが自然とその振り返る道に導いてくれる。
その道を歩みながら壁を越えるヒントを探るのだ。
リファクタ自体に思考力をすべて取られては意味がない。
command + alt + R と ctrl + 1 は親友だ。
(Eclipse for Java on MacOS)
話しかけるのに躊躇するような関係では成り立たない。

リファクタリングの結果、気付いたら高い山の上にいる。
そこには複雑な構造を一望できる素敵な風景が広がっている。
それは思考を自由にし、壁を越える発想を生む。
(プログラムが見やすく読みやすく把握しやすいものに)

問題は解決した。

そう、リファクタリングは思考のためのツールなのだ。
「最初から、綺麗に書いたら?」

先ほどの理由が一つ、スピード出して実現可能性を掴む。
ジャブを出してストレートパンチを放つタイミングを
探っているようなもの。いきなりのパンチじゃ当たらない。
ボクシングじゃわかりづらい人には空手で例えましょう。
利き足じゃない足で相手の前足への下段蹴りを軽く出しつつ、
利き足での強い下段蹴りや上段回し蹴りを放つタイミ...

もう一つ、最終的な良い形って、
組み立ててからじゃないとわからないもの。
もちろん、実装前のシミュレーションはやりながらも、
それに加えて、組み立てながらの調整もやる。
それでやっと本当に最終的な良い形が見えてくる。

そもそも壁にあたらなかったら(いやあたっても)、
実装後に「本当にこれで大丈夫かな!?」って、
まず自分自身によるソースレビューをする際に、
(jfluteは小心なので自分のコードを何度も読み返す)
リファクタリングが似たような役割を担ってくれる。
ここでも息を吸うかのごとく自然にね。

リファクタリングはプログラミングの一部とも言える

というか、一部にしてしまおう、という発想。
作ることとリファクタリングが既に分離していない。
そうすることで、リファクタリングにかけるコストが、
実装スピードにうまく変換されていくのだと考えます。

リファクタリングのためのリファクタリングには、
なかなかお金はまわってこないから。

この「ミング」の感覚を伝えたい。
 -> 「ミング」の時間ですよ | jfluteの日記