こんにちはカレイドです。
先日
こちらの記事で実際のインターンの面接の様子をお話ししました。
あれから1週間あいつ実際の実務の方はどうなんだ？俺もそろそろ実務近いしどんな感じなのか気になるぞ
って方もたくさんいたのではないでしょうか。
今回は実務と独学の壁（プログラミングスクールも同様）感じたことについてまとめてみます。
文が長くなってしまったので全編と後編に分けます。
課題をもらう前のお話し
まずは課題を頂く前に簡単にどのようなツールを使って開発をしているかの簡単な説明とプロジェクトの構造を簡単に教えていただきました。
私はReactのコンポーネント設計で主に携わるのですが通常ページ遷移はReact-Routerと呼ばれるものを今まで使ってきていたのですが、
違うものを使っていたのでこういう些細な違いがところどころ見られました。
他にもどのようなパーツに分解してどこに保存されているかや、プロジェクト全体の概要を把握することが第一ステップになりました。
ワンポイントアドバイス
自分の経験でこのプロジェクト理解をするのに一番役に立ったのはGithubで自分の言語を使っているものを引っ張ってきて読むことでした。
全くの0から始まるのでいい勉強になります。加えて変数の命名方法や、大まかなパターンなどの知見なども手に入りました。
難易度は高いですが、実力試しにはかなりオススメです。
最初は他人の書いた言語なので戸惑いがありました。でもUdemyが講師が1行ずつ書いていた時はそんなことありませんでした。
今はプロジェクト全体を見てしまっているからちょっと大変になっているだけで、きちんと1行ずつたどって細かく理解していけば大丈夫だと、自信を持ちながら読んでいきました。
ちなみにコピーして四六時中読み込みました。
どんな課題が与えられる？
一通りのプロジェクトの内容を説明してもらった段階で課題を頂きました。
これについてはインターンとなると割と軽めの物を与えられると思います。
実際にインターンにはいきませんでしたが面接をした最初のところですと小さな機能の追加だったり、小さなバグ修正とかそういうものですね。
私の場合はまずどのくらいコーディングが出来るのかのチェックということでデザイナーの方が書いてくれた画面の設計書を見ながらまずはこの部品を作ってみようかということでお話を頂きました。
実際の物を見せることはできないので簡単な例で行くと
例えばGoogleで検索をかけた時に途中から同じリストの集まりが出てくると思います。
この一つの塊を作成して実際に複数個配置させたときの物を作成しました。
実践① 資料の読みこみ
話は戻りますが、まずはいきなり作り始めるのは愚の骨頂。せっかく先輩たちが作ってくれたものがあるのでその日はいきなり作業することはなく帰りました笑
これにはきちんと意図があって、いきなり作り始めても当然ゴールは見えないのでまずは今まで作られたコンポーネントたちを読み込むことから始めました。
いやいやいや、わからないところ聞けるんだから残れよって思いますよね。でも僕はわからないところしかないだろと思ったので、まずはじっくり読んで自分なりの解釈とまとめて質問
という手順を踏むことにしました。新しく入って1日すら資料を読み込めずいきなり作業取り掛かるのは多分無理ですし砂漠の上を歩き回るようなものです。
私は今まで割と独学で、自分の裁量で大体の画面のバランスがとれていればオッケーのスタイルで勉強をしてきているのでこのように与えられた設計から逆算することをあまりやってきていません。
ですからどのようにして最終形までもっていくかにすごい悩みました。
加えてコンポーネントに一からすべて作るのではなくフレームワークを採用しているのである程度自動で設計が出来る反面、中をいじることが難しいという両面性を改めて感じることになりました。
実践② 既存の物を参考に似せて作る
一からはやっぱりHTML/CSSの知識めちゃくちゃあるわけじゃないので苦労しそうということで、
こういう何か一つのコンポーネントを複数ループで回して配置するのは結構いろんな部分で出てきそうだなと思ったところ、社員さんからありがたくこの部分参考になりそうだからと
参考になる部分を頂きました。
はい。めっちゃ助かりました。読み込むとはいってもなかなか実務レベルとなると難しくて苦労していたところ金色の糸を垂らしてもらえました。
すごい、やさしい方で以前IT10年ぐらい働いている先輩からもらったアドバイスの
誰の下につくかが正直一番重要だね。しかも自分で選べないのが厄介だけど
と、言われたのを思い出してめちゃくちゃラッキーと思いました。
ワンポイント
素直にわからなそうなときはどこか参考になる部分はありますかと聞いてしまうのがいいと思います。
もちろんいきなり聞くのは成長しないので考えた末に無理そうならずっと悩まず聞いてしまいましょう。
というわけで、見よう見まねで細かいCSS等はとりあえず置いといて、一先ず方針が良さそうかだけGitへプルリクして確認してもらいました。
実践③自分の意図、相手の意図をしっかり汲み取る。
一度レビューをしてもらったら、すべて鵜呑みにするのではなく、自分の設計はどこがまずかったのかをキチンと理解しましょう。
それはなぜか、相手も人間だし、超完璧ではないので疑問に思った設計部分については素直に聞くことが大事です。実際どうしてこの設計にしたかを書いてくれるととても助かるとお話し頂きました。
新人でも意見をしっかり受け入れてくれる、聞いてくれる会社かどうかは個人的にすごい大事だと思います。
これが正しいからという先輩はあまり当てにしない方がいいかもしれません。
僕の先輩は必ず、この設計よりこっちがよくてそれは、後々の実装面でこの部分が責任を持たないようにあくまでこいつはこれが役割だから見たいな感じでキチンと説明してくれたので
すごい納得して編集することが出来ました。
前編のまとめ
主にプロジェクト参画から最初の苦難までのお話しでした。
まずは初日、二日目までの内容をまとめてみました。実際かなりのデモアプリを作ってきたので余裕かなと思っていた自分がいたのですが、まずコミット数8000とか見て
あぁすごいなと思いました。これが個人とチームの差なのかと笑
ちなみにコミット数は初心者さん向けに話すなら進捗の度合いとその時のコピーを取っておいた回数のこと私の自作アプリManehabiで約200程度です。
次回は自分のCSSスキル不足の話と、今まで実感のなかったあの役割が実はめちゃめちゃ大事なんだなって思った瞬間のお話をしていこうと思います。