この記事はエムスリー Advent Calendar 2018 8日目の記事です。
こんにちは。エムスリー エンジニアリンググループの川俣です。
最近驚いたことは、勉強会*1でLTしてプロテインをもらったことです。
※注 プログラミングの勉強会です。
私は、今年2月に6年務めた消防士から業務未経験でエンジニアに転職しました。
今回は同じようにエンジニアに転職する方に向けて、「転職前にやっておけばよかったな」と思ったことをお伝えします。
1. 他の人が書いたコードを読み込んでみる
業務未経験でエンジニア転職をする方が最初に従事する業務は、0-1での新規開発ではなく、 既存システムの改修・運用だと思います。
そのような時、まず向かい合わなくてはならないのが、誰かが書いた何千何万行ものコードです。
大変恥ずかしいことなのですが、入社前まで他の人が書いたコードを真剣に読み込んだことがありませんでした。なので最初任された既存システムのリニューアル案件では、処理が全く追えず大変苦労しました。
事前に他の人の書いたコードを読み、処理を理解する力を身につけていれば、そこを抵抗感なく乗り越えられたかなと思います。
TRY
GitHubに公開されているOSSのコードを読んでみよう。
RubyだったらGitLab、サーバーサイドKotlinだったら最近話題のKtorなど色々あります。最初は理解できないと思いますが、業務になったら自ずと挑戦することになります。まずはGitHub上でコードを追うだけでもやってみると良いと思います。
2. コードレビューを受けてみる
独学で個人開発ベースで学習していると抜けがちなのが、コードの品質です。
私も入社前まではコードの品質など全く意識せず、「動けば良い」で作っていました。なので今、昔書いたコードを読み返すと大変ひどいものだった愕然とします。
業務で初めてプルリクエストした際など、レビューの指摘が多すぎてGitLabのコメント欄が固まりました....
品質を高めるためには、何よりコードレビューが有効だと思います。個人開発でもコードレビューを受けて、早めにコードの品質に意識を向けて置くと、業務でより本質的な学びを得ることができると思います。
TRY
エンジニアの知り合いがいればコードレビューを依頼してみよう。
また、自動のコードレビューサービスもおすすめです。
sider.review
その他、紹介するまでもない程有名ですがリーダブルコード*2*3を読み、自分のコードを自分でレビューしてみるのも良いと思います。
3. ユニットテストを書いてみる
私は入社前までにも個人で色々開発していたものの、ユニットテストを書いたことがありませんでした。モック？スタブ？なにそれ？という状態でした。
業務で書くコードでは品質を担保するためにユニットテストが必須です。
丁度先日、入社当初に自分が書いたコードからバグが発生し、一日障害対応に追われました。そのバグ混入の原因の一つが、ユニットテストで要件をカバーしきれていなかったことでした。そのような事態を起こさないためにも、事前にユニットテストを書く習慣を身つけておくと良いと思います。
TRY
個人開発のシステムでユニットテストを書いてみよう。
ユニットテストを書くことが、自分のコードを見直すきっかけにもなり、リファクタリングも進むと思います。また、テスト駆動開発*4という素晴らしい本もあるのでそちらを読むこともおすすめです。
おわりに
以上、私が思う業務未経験からエンジニアに転職する上で、やっておいたほうが良いことでした。
今もまだまだ力不足で躓くこと多々ありますが、エンジニアという仕事に、日々充実感を感じています。
もっと異業種からエンジニアに転職して、活躍する仲間が増えれば良いな思っています。
We are hiring!
エムスリーでは、共に医療 × テクノロジーの未来を切り拓いてくれる仲間を募集中です！ ご応募お待ちしています。
