本記事を閲覧いただきありがとうございます！
この記事は、クラウドワークス Advent Calendar 2022の17日目の記事です。
はじめに
2022年9月からクラウドワークスでWebエンジニアとしてのキャリアをスタートさせた
駆け出しエンジニアの松尾です。（現在実務3ヶ月目）
今回はそんな私が実務に入ってから苦労したことをピックアップして紹介します。
そして、苦労したことへの対応策も併せて、記しました。
なので、以下のような方には参考になるかと思います！
- 未経験エンジニアとして中途入社前の方
- 来春から23卒のエンジニアとしてキャリアをスタートさせる方
- 自分と同じく歴の浅い（1年未満）エンジニアの方
▼入社前の勉強・転職活動のことは以下の記事にまとめてあるので、よろしければご覧ください。
結論
結論から言います！
新人エンジニアが実務に入ってから苦労したことは、以下の3つです。
苦労したこと
①Git
②テストコード(RSpec)
③影響範囲
①Git
【エピソード】苦労したこと
入社してから、言語(Ruby)よりGitが理解できてないことに気づきました（笑）
入社前までに理解していたことは、チーム開発でよく用いられるGit運用の手法（git-flow)などです。（詳細はこちらの記事）
転職活動用のポートフォリオの制作もGit・Githubを使って、開発してたので、ある程度自信はありました。
ですが、現実はそんなに甘くなかったです。
入社してすぐに以下のような状況になりました。
自分「リモートにプッシュしましたけど、実装中に方針が変わって、リモート・ローカルの両方でn個前のコミットまで状況を戻したいです。」
先輩「git reset --hard とかでいけるんじゃないですか。」
自分「すみません。git resetとかちょっとよく分かんないです。」
その時は先輩の言う通りにgitコマンドを叩いて、なんとか状況は打開したんですが、
「やばいな（焦り）」 と思いました。
先輩からは、「git resetのコマンドは結構使うので、自分で使えるようになると良いですよ。後、Gitの全体像も理解しといたほうが良いです。」と助言を貰いました。
それからはGitの理解に力を入れました。
今後の対応策
以上のことを通して、
Gitの理解には以下の全体像を理解して、開発することが重要だと思いました。
なので、現在Gitで詰まった時は全体像に立ち返って考えるようにしています。
- ワーキングツリー（自分の作業場）
-git add：「ワーキングツリー → インデックス」への反映- インデックス
-git commit：「インデックス → ローカルリポジトリ」への反映- ローカルリポジトリ
-git push：「ローカルリポジトリ → リモートリポジトリ」への反映- リモートリポジトリ(みんなの作業場)
全体像を理解して、開発することの具体例(１例)を以下に示しました。
- 【目的】：n個前のコミットを取り消してワーキングツリーの変更も取り消したい
- 【目的達成のため理解が必要なこと】
git reset --softとgit reset --hardの修正範囲の違いが分かること
--soft：「ローカルリポジトリ」のみ--hard：「ローカルリポジトリ・インデックス・ワーキングツリー」全て- 【目的達成の為の手段】
git reset --hard HEAD~{n}
▼自分でも文章だけじゃなく、Gitの全体像を図解でまとめてみました。
タメになった記事
理解度を上げるのに、以下3つの記事が有用だったので、紹介しておきます。
▼git resetの全容把握
▼Gitの全体像把握
▼Gitコマンド逆引き辞典（ブックマークしてます）
ここまでレベルを上げたい
▲上記のGit理解度チェックリストが
Gitの使いこなせるレベルを定量的に示した分かりやすいものだったため、引用します。
- merge に失敗したらmerge前に戻れることを知っている
- そのやりかたも知っている
- rebase に失敗したらmerge前に戻れることを知っている
- そのやりかたも知っている
- (cherry-pick についても上記merge,rebaseと同じ程度理解している)
- merge中のコンフリクトを解消できる
- rebase中のコンフリクトを解消できる
- rebase -i で自分のコミットを綺麗にまとめることができる
上記のこともサクサクできるようしていきたいです！
Gitに関しては毎日使うものなので、エンジニアライフのQOLを上げるため貪欲にレベルアップを図りたいと思っています。
②テストコード（RSpec）
【エピソード】苦労したこと
正直テストコード（RSpec）をろくに書いたことなかったので、入社したては色々と苦労しました。
そして、入社後に初のタスクで、テストを書く時、テスト用フォルダの中身が膨大すぎて、
「まずどのファイルを編集すればいいんだろう」
というテストコードを書くスタートラインにも立てない状況がきました。（笑）
その時の実務1発目の頭の中を振り絞ったテストコードを先輩に見てもらうと
「そもそものテストコードを書くファイルが違った」 ことが発覚しました笑
その後、1からテストコードを修正し直しました笑
▼他にもいろんなことがありました
- テストコードが意図した通りに全く動かないこと
- やっと実装できたタスクも「あ、テスト書いてない」とすっかりテストを忘れていたこと
- 数時間かかっても書けず、ハマって先輩に助けを求めたこと
今後の対応策
まだテストコードに関しては、難しく感じることが多く、実務を通して知見・書くスピードを上げていきたいと思ってます。
実装前の段階で、テストの箇所にあたりをつけたいので、以下のことをやっていこうと思ってます。
- 「このタスクを行う上で、追加・変更すべきテストコードは何か」を調査
- 調査後、追加・変更するテスト箇所をドキュメント(Notion)に書き出す
タメになった記事
以下4つの記事は、テストコードのバイブルとして、いつも見ていて有用だったので、紹介しておきます。
いずれも@jnichitoさんの記事です。
③影響範囲
【エピソード】苦労したこと
プルリク発行後のコードレビューで、先輩から以下の指摘がありました。
先輩「〇〇コンポーネントはサイト全体で共有されているので、画面Aの要件に寄せた改修が画面Bにも影響出ちゃってます。」
ここで何が起こっていたかというと、
Reactコンポーネントのデザインを仕様通りに変更すると、
「画面Aのデザインを変えたいだけなのに、画面Bのデザインも変わった」現象が起こりました。
原因としては、Reactの共通コンポーネントの「影響範囲」について理解していなかったからです。
▼図解すると以下のような状況です！
▼その時は、解決策として
共通コンポーネントに条件分岐を入れ、画面Aの時だけデザインが切り替わる仕様に変更
今後の対応策
以上の少しやらかしたエピソードの原因は、共通コンポーネントの影響範囲を理解していなかったことによるものです。
なので、共通コンポーネントの変更を要するタスクを行う際、どの画面でそのコンポーネントが使用されているのかを把握してから、実装するように心がけています。
まとめ
というわけで今回は新人エンジニアの私が実体験を通して、苦労したこと3つを書いてみました。
特に未経験で入社前のエンジニアの方に参考になると嬉しいです。
振り返ってみると、Git・テストコード(RSpec)に関しては入社前にもうちょっとできるようになっておけば良かったなあと思っています。
特にGitに関しては毎日触れるものなので、「Gitって何？」てレベルだったら普通に詰むと思いました笑
そして、私の「分からないことが分からない」系の質問に対しても、丁寧に答えてくださる先輩方がいる環境にも感謝しています。
この記事を読んでいるあなたへ
最後に、僕が所属しているクラウドテックの開発チームでは事業と開発をリードしてくれる仲間を募集しています！
ご興味のある方は以下のリンクからご応募ください！