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

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

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

リファクタリングは「思考のツール」でもあります。

気づいたら解決した

意気揚々とプログラミングしていて、ふと壁にあたって熟考が必要になったとき、jfluteはおもむろにリファクタリング

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

そこまでは、全体構成を掴むためにも、全速力でロジックを積み上げる。

「この方法で本当に実現できるのか!?」

これでいいのかわからない方法で丁寧に書いていって、やっぱりだめだったーっていうと時間がもったいない。それを早く確認するためにもスピードが必要です

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

ふと壁にぶちあたる。

うーんとパソコンの前でうなってもしょうがない。リファクタリングを始める。おもむろに部屋のお片付けをし始めるようなもの。

壁を越えるためには今まで積み上げてきたプログラムを振り返る必要があるが、リファクタリングが自然とその振り返る道に導いてくれる。リファクタリングの過程で目の前のプログラムの様々な形を目にすることになるのだ。そのプログラムの変化を目のすることで、そのプログラムの本質が見えてくる。

もちろん、リファクタリング自体に思考力をすべて取られては意味がない。エディターの機能は使いこなしていますか?リラックスしながらリファクタリングできると良い。

リファクタリングの結果、気付いたら高い山の上にいる。そこには複雑な構造を一望できる素敵な風景が広がっている。それは思考を自由にし、壁を越える発想を生む。

プログラムが見やすく読みやすく把握しやすいものになった。

「ああ、なんだ、こうすればいいんじゃん」

問題は解決した。

そう、リファクタリングは思考のためのツールなのだ。

まずはラフスケッチ

「最初から、綺麗に書いたら?」

しない理由...

...

先ほどの理由が一つ、「これでいいのかわからない方法で丁寧に書いていって、やっぱりだめだったーっていうと時間がもったいない」

まずは、スピードを出して実現可能性を掴む。

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

...

もう一つ、「最終的な良い形って組み立ててからじゃないとわからないもの」だから。

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

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

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

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

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

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