新卒一年目の自分が、エンジニアになったばかりの人たちに声を大にして伝えたいこと
この記事は、NAVITIME JAPAN Advent Calendar 2021 最終日の記事です。
こんにちは、「Vimmerになりたいエンジニア」のせーじです。2021卒の新卒でナビタイムジャパンに入社し、現在は法人向けサービス「ビジネスナビタイム 動態管理ソリューション」のWeb、コンテンツの開発を行っています。
Advent Calendarの募集が社内でされたときに「とりあえずやろ〜」と思い、なにも考えずに応募していました。
記事の内容について色々と考えた結果、この記事ではエンジニア歴が浅い方に向けた声を大にして伝えたいことを書くことにします。
Vimはいいぞ〜
私がVimに出会ったのは大学生2年生の頃でした。先輩が少ない操作で、しかも目にも留まらぬ速さでコーディングをしてたんです。
「え？なにしてんですか？あれ？編集が速すぎて目が追いつかない…！！」
色々と聞いたところ、Vimと言うらしく、カスタマイズも自由自在で「できるプログラマ」という感じがとてもしました。とりあえずカッコよかった。
そこからはずっとVimを使っています。
私はコーディング以外でも、メモを取るだけ、文章を書くだけでも利用しています。この記事もVimで書きました。
もっとVimについて知りたい方は下の記事を読んでみてください。きっとVimを試したくなるでしょう！
コードを読もう、できるだけ多くの
言葉を話すためには言葉を学ぶ必要があります。加えて、丁寧な言葉遣いや（必要があるかは置いておいて）侍のような喋り方をするにはまずはそのような言葉遣いについて知ることが大切です。
今、エンジニアになったばかりの皆さんは言葉こそ話せても（コードが書けても）細かい言葉遣い（わかりやすいメソッド名やよみやすいコード）はできていないと思います。
読みやすいコードを書くために、積極的にコードを読みましょう。
まずは社内のコードから始め、できればGitHubなどのオープンソースのプロジェクトでstar数が多いものを読むといいです。または、尊敬できる人のコード、ツヨツヨの人のコード、あるいは自分がよく使っている小さめのツールのソースコードでもいいと思います。
先程「メモを取るだけ、文章を書くだけでも利用しています。この記事もVimで書きました」と申し上げました。その際にmattnさんのmemoというツールをよく利用してたので、私はmattnさんのコードを追うことが多いです。
レビューは勉強会
入社して配属されてから一ヶ月ほどは「先輩のプルリクをレビューするなんて恐れ多い」と考えていました。加えて、そもそも先輩のコードを見てなにもわからなかったのです。そんな状態でプルリクに対してあれこれ言えないですよね。
では、「わからないことを質問する場」と考えるとどうでしょう？
レビューの場は最高の勉強会になりました。
「レビューは強い人がやる」という思い込みを捨てて質問しましょう！
"""
今後もパラメータ調整が発生することを考慮して下記の通り変更
対応前：String#format
対応後：StringBuilder
"""
と書いてあったんですが、String#formatとStringBuilderの違いがよくわかっていません。
Stringの加算とStringBuilderの違いは理解しています。
処理が重い軽いではなく、StringBuilderで書いたほうが読みやすいから採用したのでしょうか？
上記は私が実際にした質問です。とりあえず、気になる、ちょっと疑問に思ったことは「自分で仮説を立ててから」質問するようにしています。
テストはコピペから始めよう
テストはしばしば後回しにされることがあります。だって、書かなくてもプロダクトは動きますから。
ただ、楽しいのもつかの間、時間が経ってから変更を加えようとしても「どんな入力に対してなにを保証すればいいか」がわからなくなってしまいます。困るのはなにもかも忘れた自分かもしれませんし、未来の若人かもしれません。
私は実際とても困りました。たまーにテストが書いていないコードがあると「なにが正解なのかわからない」のです。そうなると修正にも時間がかかるし、検証も時間をかけてやらなければいけません。作業にかかる時間がテストありのコードに比べ何倍にもなります。
逆にテストが書いてあると「安心感」が違います。コードを修正してテストを実行（ワンポチ）すれば、修正が適切かどうかが一瞬でわかるのです。
ただ、私もそうでしたがテストには謎の抵抗感があります。書いてあるテストにパターンを追加するだけでも良いです。まずは、コピペから始めましょう。
影響範囲の調査は下から上へ
影響範囲とは「変更を加えた箇所が影響を及ぼす可能性がある範囲」のことです。
もう少し簡単に言うと、calcSalary()の内部処理に変更を加えた場合、呼び出しもとはすべて影響範囲になります。
影響範囲を調査する時は必ず、根本から、最下層から調査しましょう！
DBのカラムが変更になるのであればテーブル名でプロジェクトを全文検索した後、すべてのDAO層のメソッドから上に上に調査を進めればすべての影響範囲を出せます。
開発者検証は自分のために徹底的に
多くのチームにはQM（Quality Management）がいらっしゃると思います。
QMはサービスの品質を保証する立場の方々です。私達エンジニアが変更を加えた機能やら色々な検証を行ってくださいます。
「だったら開発者検証はガッツリはやらなくても良いのでは？」
そう思っていた時期が私にもありました。
「「だめです！」」
自分のためにも開発者検証はガッツリ徹底的にやりましょう。検証が始まってからのバグ対応はスケジュール的にもきついものがあります。なにより申し訳ない気持ちでいっぱいになります。
私は開発者検証をガッツリするためには徹底的な影響範囲調査が必要だと考えています。影響範囲がすべて出せれば、少なくとも機能単位の見落としはなくなるでしょう。
まとめ
ここまでお付き合いいただきありがとうございました。
偉そうに色々と言ってきましたが、私自身もやりきれていない点がいくつもあります。
同じ境遇の方は参考にしていただけると幸いです。そして「私はこう思う」などあれば是非記事を書いてほしいです。
先輩エンジニアの方からみたら「違う！」や「こっちのほうが大切！」と思うことがあるかもしれませんが、その時は一緒に考えていただきたいです。
それでは良いお年を！