はじめに
一年目のエンジニアはみんな「なんかプログラムが動かない」という状況に陥っていると思う。
自分自身もそんな状況がとても多くあった。今でもある。一日潰れることもある。
ただ最初と比べて変わったことは、「原因を調査して動かす状態に持っていく」ことが出来るようになった。
そこに行きつくまでにどんな歴史があったか、振り返ってみることにした。
この記事を読むことで新卒研修がより良いものになってもらえる事を期待する。
歴史
第1フェーズ ~デバックってなんだ？~
ここはIDEを使ったりすることですぐにできると思う。
初歩なのでほとんどの人が出来ていると思う。
デバックポイントを張って、ポイント毎に自分の期待する動きになっているか中身を確認する。
期待する動きになっていなかったら、修正していく。ただの繰り返しだ。
第2フェーズ ~スタックトレースってなんだ？~
自分のコードが動かない時、必ずスタックトレースにエラー内容が書かれる。
このエラー内容を読むことで、どういった問題がプログラムにあるか事実がわかる。
最初はエラー文を最後まで読まずに、適当にコピーしてネットで調べていた。
まずは、落ち着いてエラー文を全部読み今起きている事実を認識することが重要。
適当に検索すると、問題でないことに対して検索している状態になる。
第3フェーズ ~英語？ I can read~
エラー文に関わる事だが、まずエラー文は基本的に英語で書かれる。
英語に抵抗があると、読まなかったり、上記と同じくコピペする。
最初はゆっくりでもいいから英語でも頑張って読む。何度も読む。
そうするとコツがつかめる。
また、ネットで検索するときも日本語でないなら英語で検索をする。
普通に英語の方が情報量も違うことは明白だ。
第4フェーズ ~ライブラリの中身を見ていく~
自分の書いたコードが動かない時、自分のソースコードは読むが、
フレームワークやライブラリの中身は読もうとしない。
理由は単純に「難しそうだから」だと思う。
だが、ライブラリの中身を読むことで、intしか受け付けないのに、stringで渡していた！
など気づくことがある。副産物として良いコーディング方法も知れたりする。
第5フェーズ ~仕様書を読むぜ~
qiita等のネットの情報はとても有効だが、あっているか間違っているかは自分で判断しなければいけない。
嘘もあれば、バージョンが違うこと、記事の内容が古いこともある。
一番「正」は仕様書である。
まずはqiitaで良いが、解決できなければ仕様書も読む。
※仕様書はまだ自分も読むのに苦戦している。
まとめ
今回はコーディングに絞って自分がどうしてきたか振り返ってみた。
数年経験しているエンジニアからしたら当たり前の事かもしれないが、
一年目や二年目にとっては当たり前ではない事だと思う。
エンジニア歴2年目だからこそ新卒に伝えられる内容も多くあると思った。
また、振り返ってみることで、新しい発見もあった。
新卒エンジニアの参考になれば幸いです。