まず最初に断っておきたいのが、自己学習やプログラミングスクールは意味がない、ということではありません。
実務と違う点があるので、何も知らないと「え、やってきたことと全然違うじゃん」と面食らってしまうのです。
なので、現場に入る前にこれを意識しておくだけで面食らいにくくなりますよ、という事前注意です笑
自分の経験としては、プログラミングスクールは経験しておらず自己学習のみでした。
今の自分の現場で、プログラミングスクールから入ってきた方がいますので、その人から聞いてみた話と合わせて記事にしています。
実務と違うこと
ファイルの量が全然違う
例えばMVCモデルだったとして、自己学習やプログラミングスクールだと、コントローラのファイルで10個もいかないんじゃないですかね？
いっても10前後かなぁ、と思います。
ところが、実際の現場ですとこれが20以上とか平気であります。
しかも、1個のファイルにメソッドがいくつもあったりします。
それ以外にも、見たことないようなフォルダの中にファイルがたくさんあったりしますね笑
また、1つのファイルでもコードの行数が1万近かったりすることもあります。
データの量が全然違う
DBのデータ量も基本的には同じ感覚です。テーブルの数がまず多いです。
そして、1テーブルの中のレコード数も平気で何万もあります。
これの問題点としては、扱うデータや実装したコードによってはスロークエリや高負荷になってしまうことですね。
つまり、実際にユーザが使っても処理が終わらなかったり、サーバダウンなんてこともあったりします。
条件の複雑さが全然違う
もちろん、シンプルな条件文になることも全然あるんですけど、非常に複雑な条件分岐を書く必要が出てくることもあります。
分岐が複雑、分岐させるためにテーブルの結合が複雑、とかですね。
コードの書き方という問題もあるんですけど、しっかりと条件を洗い出せるか、という思考力も必要になりますね。
要件や設計が抽象的
これをどこまで学習するか不明ですが、基本的に要件定義や詳細設計がきちんと書かれていることはありません笑
（そこに時間を割けるほどPMやPLに工数の余裕がない現場がほとんどです）
おそらく実務未経験の方ならば、基本設計や詳細設計を見ることになると思うんですが（要件定義はまだ見ないかなぁ）、ネットで検索して出てくるような内容で設計は書かれてないです。
実際にはもっとラフに書かれていますし、内容も漏れがそれなりにあります。
なんなら、設計自体がないことも珍しくないですね。
現場によってルールが違う
どうしても現場に出ていないため、ルールが同じだと思ってしまうんですよね。
ですが、実際には現場によってルールは結構違います。
ブランチの切り方、プルリクエストの出し方、slackの使い方、設計や仕様書の書き方などなど、全部が現場によって違います。
対策方法
ファイル量
解決策としては、結局頭から処理を追えるようになるしかないかなぁ、と思います（最初の頃は）
量が多かったり複雑になっているだけで、どういう流れで処理をしているかは変わりません。
なので、感覚やセオリーで自己解決せずに、ちゃんと処理の流れを把握するようにしておくように心がけてください。
データ量
正直、ここは後回しでもいいかなぁと個人的には思います。
というのも、いきなりここで面食らうことはないと思うので（後々はぶつかるかもしれませんが笑）
データ量が多くて困ることって、さっき書いたスロークエリや負荷の問題くらいだと思うんですよね。
（かつ、いきなりここを任されることはないかなぁ、と）
データが多くて見づらいとかは、別にSQLでwhereやlimitとかで絞ればいい話なので、面食らうような話ではないと思います。
これで面食らうのであれば、むしろwhereやlimitなどの難しくない選択肢が頭にないことになるので、そっちの方が問題だと思います。
条件
ここは結構プログラミングの思考力のセンスが出ると思います。
（センスがなくても努力や経験でなんとかなりますよ）
最初はマトリックス表を使うのがいいと思います（自分も今でも使います）
または、条件分岐の図を書くのもいいかと思います。
複数の条件を1個ずつ整理していく感じですね。
複雑な条件は頭の中だけで解決する必要はないです。どんな方法でもいいのでちゃんと整理することが大事です。
要件や設計
ここは現場のシステムの理解度も必要だったりするので、現場にしばらく勤務してないと難しい部分は多いと思います。
ただし、書かれている文章だけではなく、その裏の意図を汲み取るようにすると多少は良くなると思います。
基本的に意図があって、クライアントから要望があり、それを実現するために要件をまとめたり設計に起こしているわけです。
なので、その意図を達成するためにコードを書くわけであり、その意図の達成がゴールです。
例えば「顧客一覧で顧客の個人情報は表示させない」みたいな設計があったとします。
その場合、セキュリティの観点から個人情報を表示させたくないわけです。
なので、住所や電話番号など、表示させたらまずいものを非表示にするんだなぁ、ということがわかると思います。
もちろん、質問することも大事ですが、その回答に相手の時間を極力取らせないようにしましょう。
質問することが悪いのではないです。理解力と相手の手間が問題になるんです。
ルール
これはどちらかというと、社会人的としてのスキルになりますね。
会社によってルールは違うので、それは会社に合わせましょう、ということです。
そして、そのルールはプログラミングでもありますよ、ということですね。
なので「え、プログラミングスクールでは〜〜でしたよ」って言ってしまうのはダメです。
別に「会社に染まれ」ということではなく、社会人として臨機応変に対応しようとしないとそりゃダメですよね、って話です。
あくまで基本は変わらない
やっていることの根本は変わらないんですけど、それが実務だとより広くなったような感じですね。
つまり、一言で言うと対応力ですね。
ファイルが多くても処理の流れは変わらないし、設計が抽象的でも意図があって実装するのは変わらないです。
ただ、やっぱ実務経験がないとビックリしてしまうんですよ。かつ、経験が少ないから対応もうまくできない。
なので、実務でうまくいかなくても、それまで学習してきたことが全然ムダということではないです。
そして、少しでも初めての実務がうまくいくように、この記事が参考になればと思います。
