リファクタリングでスキルを伸ばす
■できてからが始まりだ
技術の勉強といえば手を動かすことが必須だと思う。適当に本でも買ってきて、勉強したとしよう。本にもよるが、書いてある内容をそのまま操作していくと、だいたい1日くらいあれば一通りの内容を試せる。
スキルの伸びる人と伸びない人の違いは、一通りの内容を試した後の行動に出ると思う。スキルの伸びにくい人は、ここで「できた」と認識する。つまり、100やるべき事がある内の95くらいを終えた心境になる。
スキルの伸びる人は、「で、これをどうするんだ?」と疑問を持つ。100やるべき事がある内の10くらい着手したような心境になる。本に書いてある内容ができて、そこから追求が始まる。
本の内容を基準にすると、スキルの伸びない人はゴールが近くにある。スキルの伸びる人はゴールが先にある。つまり、スキルの伸びない人は簡単な技術で満足して、スキルの伸びる人は高度な技術でなければ満足できない。だから継続的に学習する。
■では目標を高く持てばいいのか
高い技術を身につけたければ高い目標を持て。というのはよく言われる。では高い目標を持つにはどうすれば良いのだろうか。まず、すぐに浮かぶのは頑張るという手段かもしれない。より難易度の高い資格を目指したり、難易度の高い技術に着手することだろう。
ただここで疑問に思う。いちいち目標って、人に説明できなければダメなのだろうか。目標を達成する度に、いちいち人に証明する義務なんて無い。自分の目標なんて、もっと軽いノリで決めて好きな方法で追求してもいいのではないだろうか。
一冊本を読んで、内容を実践してみる。できたとかできないとか、そういう基準ではない。納得いくまで弄り倒す。本に書いていない方法を、心ゆくままに試してみる。思いっきりツッコミを入れてみる。そういう自由さが持てると、学習が楽しくなると思う。
まず、理屈抜きで弄り倒さないと何も感じるものが無い。弄り倒している内に、もやもやした感覚が一つの疑問にまとまって、言葉で表現できるレベルまでまとまっていく。目標や手段を語る前に、まず弄り倒して色々と感じることが大事だと思う。
■感じたものに答えを出していくのがリファクタリング
例えば、何かのプログラミング言語をやっていたとして、「面倒臭い」「効率悪い」「何じゃこれ」と感じることがあると思う。こういう思いを起点に、「もっと良い書き方はないか?」「こう書けばどうなるだろう」という発想が湧いてくる。
こういう発想に答えを出していくのがリファクタリングだ。発想に対する答えはそれぞれが決めれば良い。これもいちいち説明できなくても良い。心ゆくまま試して、納得がいった時点で説明できるようになるからだ。目指すポイントは自分の納得でOKだ。
自分で納得しただけじゃ足りないと感じる人もいるかもしれない。だが、自分が納得しなければ、言葉に出して説明も難しい。自分が納得した内容を人に話して、「いや、それはどうなんだ?」と言われたら、それはそれで問題無い。そこからまたリファクタリングしていけば良い。
大事なのは、対象になる技術に対してどれだけ試行錯誤したかだ。普通に「できた」時点で満足していたら、試行錯誤の量が少なくなる。一見無駄なようだが、リファクタリングを通して大量の試行錯誤を繰り返さないと、技術を理解して応用するのは難しいだろう。
■現場でリファクタリングしてますか?
私は現場でリファクタリングをしている人をほとんど見た事が無い。ビジネスは無駄を嫌う。動いて用件を達成した時点で目的は完了だ。リファクタリングをしている暇があったら、他の案件もこなして多くのお金を稼いだ方が良いと考える。
ビジネスでは明確な説明が常に求められる。自分の直感で、なんて理由は通らない。理由の説明できない行動を繰り返せば、信用を失ってしまう。リファクタリングでは、理由は後から付いてくる。場合によっては、何もしないのがベストでした。なんて結果が返ってくることもある。ビジネスに傾倒している環境ではなかなかやりにくいと思う。
しかし、リファクタリングをしなければ、どんなに仕事の量をこなしてもスキルは伸びない。試行錯誤が抜けるからだ。だったらどうすればいいのだろう。仕事をさっさと済ませて、仕事中にリファクタリングすればいい。
半日時間を作るのは難しいかもしれない。一日の中で三十分でもリファクタリングに時間を割り当てるだけでも、大きく流れが変わると思う。業務時間外に勉強するにしても、課題が見つけられるようになるはずだ。
スキルを伸ばす一番の基本は試行錯誤だ。新鮮な「なぜ?」が無いと、技術に対してモチベーションが保てなくなる。リファクタリングは、技術に瑞々しさを保つ効果的な方法ではないだろうか。
コメント
やまぐち
組んだ後であーだこーだやりだすヤツなんてレベルが低いよ
そもそもクラス名も変数名も設計書に書いてFIXした後で触りだす意味がわからない
設計書書いてるときに本気出せばよかったじゃん
組まなきゃわからんか?(泣)
ってのが世間一般の認識かと
ま、たしかにいきなり組みだす現場も結構ありましたけどね
月曜クォーターバック
anubisさんの実績を知りたいです。オープンソースの世界でがしがし
プログラム書いたりしてるんですか?!
まったく
設計書書けば全て不具合無くなると思ってる人発見w
そこまでのクオリティの設計書あるんか?
lav
組んだ後にリファクタリングするのは正解やと思う。
ただし、自動テストがされてること前提で。
赤、緑で全部緑になった状態からのリファクタリングならね。
いくら設計で頑張っても、やっぱりいけてないところは見えちゃうし。
可読性とか拡張性とか含めてね。
特にいろんな人が一緒に実装やるとスキルレベルによってコードはマチマチになるし
lav
結局のところPDCAなのかも。
ソースコードだけでなく、実務もリファクタリングせなあかんと