はじめまして。株式会社PRUMでエンジニアをしている、すもも🍑です
日々、プログラミング学習や実務の中で、つまずきやすいポイントや
考え方を整理して発信しています。
PRUMについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト
尊敬する先輩のようなコードが書けるようになりたくて、書き方やツールの使い方を一生懸命真似してみたことはないでしょうか。
ところが、同じように書いているつもりでも、なぜか実力が伸びている実感が持てず、もどかしさを感じてしまう——そんな経験がある人も多いと思います。
最近になって、その理由がなんとなく分かった気がしています。
真似ても伸びない人がやっている、ありがちな真似の仕方
「良いコードを書く人の真似をすればいい」というアドバイスは、間違ってはいません。ただ、多くの人が真似しているのは、変数名の付け方やショートカットキー、使っているエディタの設定といった、目に見えやすい表面的な部分です。
表面的な部分を真似ること自体は悪いことではありません。ただ、それだけを繰り返していても、応用が利かない場面に出会うたびに手が止まってしまいます。書き方は似ていても、初めて見るエラーやイレギュラーな仕様変更に直面したとき、同じようには対応できないんですよね。
これは、真似ることそのものが無意味なのではなく、真似る対象を間違えているだけなのだと思います。
写し取るべきは、コードではなく判断基準だった
優れたエンジニアのコードには、書き方そのものよりも、「なぜこの設計にしたのか」「なぜこの手順でエラーに対処するのか」という判断基準が隅々まで刻まれています。真似るべきは、この判断基準や思考の前提の方です。
とはいえ、「思考を真似しましょう」と言われても、具体的に何をすればいいのか掴みにくいものです。ここで有効なのが、優れたコードを実際に自分の手で書き写す「模写」という方法です。
一見遠回りに思えるかもしれませんが、キーボードで1行ずつ打ち写していく過程で、「なぜここで条件分岐を使っているのか」「なぜこの順番で処理しているのか」といった、書いた本人の意図に否応なく向き合うことになります。目で読むだけでは素通りしてしまう論理の繋がりも、手を動かして再現することで、体に染み込んでいく感覚があります。
表面的な模倣が「見た目を似せること」だとすれば、模写は「考え方を体に通すこと」です。この違いが、応用が利くかどうかの分かれ目になっているのだと思います。
とはいえ、「判断基準を写し取ることが大事」と分かっただけで満足していては、結局これまでと同じ、分かった気になるだけで終わってしまいます。ここからは、実際に何から始めればいいかを整理してみようと思います。
具体的な行動リスト
判断基準を写し取るために、次のようなことを意識してみようと思います。
- お手本にしたいコードを見つけたら、読むだけでなく実際に自分の手で書き写してみる
- コードを書き写す中で「なぜここでこの処理にしたのか」を都度言語化してみる
- 先輩に質問するときは、「どう書けばいいか」ではなく「なぜそう判断したのか」を聞くようにする
- 自分がコードを書くときも、判断の理由をコメントとして残しておく
書き方を真似ることに使っていた時間を、少しだけ「なぜ」を追いかける時間に振り替えてみる。それだけで、真似の質は変わってくるはずです。
まとめ
真似をしても伸びないと感じていたのは、真似ることが無意味だったからではなく、真似る対象が、書き方ではなく判断基準だったからなのだと思います。
優れたエンジニアから本当に写し取るべきは、コードの見た目ではなく、その人がその設計・その手順を選んだ判断基準そのものです。
表面的な模倣で伸び悩んでいるなら、一度手を止めて、憧れの先輩がどんな判断基準を持っているのか、模写を通して確かめてみてはいかがでしょうか。
PRUMのエンジニアの多くは未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
▶ PRUM採用ページ
エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
▶ エンジニアに役立つ記事サイト