駆け出しエンジニアが就職する前に学んでおくべきこと
こにゃにゃちわ〜 無職やで。
今日はスクールを卒業した駆け出しエンジニアがほんまにエンジニアとして就職する前にやっとかなあかん勉強を教えるで！
今から教えるのは通り一辺倒のこの本やっとけってだけやない。実際にワイが独学エンジニアからほんまのエンジニアになってめちゃくちゃ苦労した体験を踏まえて教えたるんやで。
スクールの勉強こなすだけで大変や〜って思うこともあるやろけど、エンジニアとして働き出したら今やっとる内容の10倍は難しいから覚悟しといた方がええで！ビビらせるわけちゃうけど、これほんまなんや。うまくエンジニアとして転職するのもそら狭き門なんやけど、入ってからの勉強の辛さはハンパないってことは肝に銘じておきや。下手したら3ヶ月で退職するなんてザラやねんから。
そういう辛い現実にぶち当たる前に心の準備ができた方がええやろなと思ってこの記事を書いてるんや。
確かにエンジニアとしてやらなあかん勉強は果てしなく多い。特にスクールとか独学とかでやってたやつがやらなあかんことは星の数ほどあるわ。でもな、その中でも優先順位ってやっぱあるんやわ。駆け出しエンジニアには時間がない。全部の分野やっとったら貯金してたお金尽きてまうやつもおるやろ。ここは抑えとかな死ぬ思いするでっていうところをピンポイントで突いていくわ。
ほないくで。
どんなルートでエンジニアになるんかは人それぞれやろうけど、たぶん今の日本でエンジニアへ転職するやつは Rails やっとるんちゃうかな。スクールもたくさんあるし。やから一応 Rails をやってて Rails をベースにした小さなベンチャーに入ることを想定するで。
まずやらないかんのは Rails や。
当たり前やんけ！って思うやろ。そう、当たり前のことや。やけどじゃあ、「こういう画面欲しいから API 側作って」って言われてハイーってすぐ作れるかな？ なかなか難しいんちゃうかと思うで。まずやらないかんのは Rails の開発の流れを頭で整理しておくことや。
具体的に言うと、Raills での API 開発をするとしたら、まず routes.rb でルーティングを作る。api/v1 とかの namespace と resources の表現でどんなルーティングになるかはわかっといた方がええ。ある程度 REST の考え方はスクールとかでやったんちゃうかな。
ルーティングができたらモデルを作る。マイグレーションとバリデーションを考える。locale も必要かもしれん。ほんでそれに対応する controller に空の CRUD 処理を作る。binding.pry を入れてアクセスしてちゃんと通ってるかパラメータが渡ってるかとかを確認する。API 開発の場合、 postman っちゅうので確認することもある。strong parameter を作って、 CRUD の中身を作成する。権限系の policy を作成する。N+1 になってないかログを見て確認する。
こっからはテストや。factoryBot を作って request spec とかを作る。Rspec は読めるようにしときや。ドキュメントは AUTODOC とかでやってれば自動作成できるかもしれんな。ほんで seed data を作る。Rakeタスクとかがあったら適宜修正する。
ここまでがめちゃくちゃザザーッとした説明や。フロントがある場合はこれに加えて View の部分を作る感じや。
出てくる言葉がわからんときは調べときやー。今書いたのは知っといた方がええとこやで。
流石にこれを今すぐにパパっとできるようにしとけっていう話やない。要は開発の流れをちゃんと理解しとかないかんということや。
最初は一つ一つのポイントで詰まるのはしゃあない。そら未経験やねんから。やけど全体の流れを分かってて詰まるのと、ただわけわからんで詰まるのとメンタルの落ち具合が全然ちゃうで。なんもわからんで詰まると、ほんま超絶ダウナーになるで。経験者は語る、や。
次に大事なのはデータベース周りや。
Rails 開発しとる時によう詰まったと思うけど、マイグレーションとかのDBのあたりはようわからんのちゃうか？
これ、Rails がよしなにやってくれるからええわーって思っとったら大間違いやで。実際働いてる時にマイグレーションとかDB操作周りで詰まると、もう一切動けなくなるで。まるで沼にはまった馬のように、ズブズブ沈んでいくだけや。先輩エンジニアが忙しかったり割と体育会系やったりして助けてもらえなかった時は、もう会社の天井を仰ぐ状態や。リモートやったら泣きながら寝こんでしまうかもしれん。進捗ゼロや。
やから簡単なDB操作はやっとかなあかん。MySQL と Postgresql が主要な感じやろか。とりあえず Rails 界隈は MySQL が多いかもしれんな。ログイン方法やテーブルの表示とかカラムの表示周りの操作はできるようにしといた方が身のためやで。基本的にはマイグレーションで失敗してもDB直に操作して整合性合わせて自分で復帰せないかんのやから。
ほんでSQL。
これもやっといた方がええ。SQLドリルみたいなやつで手を動かして人と通りの標準SQLはまあ使える状態にしときや。そら Rails だけで大変なのは知っとるけど、お金もろて仕事するときはそれだけでは無理なんよ。ほんまに。とりあえず最初は Rails console でいじるのが実際どんなクエリを吐いてるんか確認する感じでええから、SQLはやっとけ。後で泣きを見るで。
んでそれにも増してめっちゃ大事なんは基本の Linux 操作。
これも別に難しいことできんでもええねん。やけど基本のコマンドでターミナルやらを動かせないとDB周りで詰まったのと同じように、一旦詰まったら身動きできなくなるんやわ。cdとかls -laとかほんまに基本の操作でええ。ただディレクトリ掘っていったりファイル表示したり権限確認したりっていう操作を一応手で覚えておくにこしたことはないで。Linux の基本みたいな本で実際に一冊手を動かしとけば、まああとは調べながらでもどハマりすることはないんちゃうかな。
フロントに関しても書いとくわ。
とりあえず Rails のフロントは Haml か Slim はやっといた方がええ。インデントが最初馴染めへんかもしれんけど、まあやってたら慣れるわ。これは自分でゴリゴリ書けるようになっとけっていうよりかは読めるようになっといた方がええってことや。
現場では個人開発の何十倍もの量のコードを読むことになる。フロントの部分だけでもめっちゃあるんやから、Haml や Slim の記法に慣れてないと読むのにさえ時間がかかってまうんや。CSS と HTML だけやとしても慣れてない記法で読むのはめちゃくちゃきついで。やから今のうちにどういうふうに書くかアタリだけでもつけといた方がええわ。
CSS 設計もやっといた方がええ。ここらは個人開発やスクールではなかなかやらんとこかもしれんけど、Rails は CSS 設計せんかったらすぐにえらいカオスがうまれてしまう。FLOCSS やら BEM やらって先輩エンジニア言われてハテナの顔しとったら「はあ？なんやねんコイツ、そんなんも知らんのか」みたいな態度で責められるで。
小さいベンチャーやったら未経験エンジニアにバックエンドの実装させられへんから、とりあえずデザイナーから上がってきた細かい表示修正のイシュー振るってのはめちゃよくあることやねん。そんなときに CSS さっぱりやったらほんまきついで。Flexbox である程度実装できるくらいには CSS やフロント周りはやっといた方がええわ。まあ多分 JavaScript をゴリゴリやる時間はないと思うけど。
あとは grep や。
grep コマンドとか、VSCode 使っとったら検索のとこで既存コードから目当てのものを探せるようにしといた方がええ。クラス名、文言やら色んな情報からファイルを探り当てて読む。ほんでそこから遡っていってどんな流れでそれが描画されてるんか確認する。要は既存のコードをどれだけ効率的に読めるかがめちゃくちゃ重要になるってことや。自分が実装するときも一からコード考えて書くなんてことは実務ではほとんどない。大体が既存コードと照らし合わせながら書いたり参考にして書いたりするんや。個人やスクールで勉強しとるとあんまやらんことやと思うから、これはしっかり理解しといたほうがええわ。
まあまあ、こんなあたりやな。
確かにちょっとワイの個人的感覚も大いに入ってると思うけど、こんなとこやと思うで。これやっとけっていうおすすめ本の紹介記事はめっちゃたくさんあっても、これやっとかな現場でどう詰まるかっていう記事はあんまないんちゃうかな？ これはワイが実際現場で詰まって先輩エンジニアにゴリゴリ詰められたところやから、そんなに外れてはないと思うで！
ほんまエンジニアになるのって、いきなり数学者目指します！ってぐらいキツイことなんやわ。
未経験エンジニアを採用してくれる会社も減ってきてるけど、この辺りを頑張ってやれれば入れるとこもあると思うで！また運よく入れた後に3ヶ月で大爆死しないためにも、学習しとくとええで！皆の検討を祈るわ！
ほなまたな〜
