始めに
ハイこんにちは！
まんじです！！
今回はプログラミング入門時？0から実務まで？と実務に入ってからも少しやっていた「間違った勉強法」というよりも個人的に「微妙だった勉強法」について解説したいと思います。
結論から書いてしまうと、以下のようなプログラミング勉強法がすごく微妙でした。
- なんとなく技術書を読む
- なんとなく技術系のサイトを読む
- なんとなく動画を見る
- なんとなくコードを読む
- コードの細かい部分にこだわる
- 説明とかを書写する
すごくざっくりと書くとするなら、考えてアウトプットをしていない系の勉強活動はわりと微妙だったと振り返ってみると思います。
AWSの本を読むよりも、AWSで必要な要件を実装をしながらそのためにAWSの本を読む方がよくね？という考え方のが学びが深いです。
フロントエンドならReactを勉強したいならReactで働くのが1番良い。みたいな感じでござんすね。
というわけで微妙だった勉強方法を解説したいと思います。
なんとなく技術書を読む⇒微妙
※ 読んでお腹いっぱいになるやつ
昔、nginxの本やその他いろいろをAmazonのプライムリーディングとかで無料で読めたので朝1時間とか読んでいました。
が、微妙でした。
確かにnginxでロードバランシングする方法にラウンドロビンがあるとかそういうのはうっすらと今でも覚えているんですけど、うっすら覚えているだけだと実装（nginxの設定）は普通にできないからです。
「いやでも、知ってることに意味があるのでは？」と思ってたこともあるんですけど、ある程度の一般的な網羅は必要だとしても網羅ベースで勉強していくと結局いつまでたってもなんかいろいろ知ってはいるけどいざやろうとするとわりと微妙君みたくなりがちだなって思いました。
nginxの場合なら実際にラウンドロビンの記述をnginxのファイルで書いてみて、そのラウンドロビンでサーバーを構築するほうが勉強になります。
ただ例外として、アウトプットするための受け皿がある場合には、技術書でインプットするとか有効だと思います。
- 例
- コーディング試験を突破するために練習しながら定番のアルゴリズムをオライリーの本で勉強する
- Reactの実装を実務でやりながら本を読んでみる
- などなど
なんとなく重めの技術系のサイトを読む⇒わりと微妙
QiitaとかZennとかは具体例が多く分かりやすく解説されているので良い（普段アウトプットしているジャンルに関しては）と思っているんですけど、ドキュメントとかをなんとなく読むのは微妙だなと思います。
昔インターンで高田馬場の駅に向かってる最中にmongooseのドキュメントをなんとな〜く読んでいたりしたんですけど、やっぱり実装しないと全然身に付かなかったです。
身につかないというよりも読んだ瞬間忘れていくというか、そもそも手を動かしていかないと理解も進まないという感じで、網羅的な暗記っぽい勉強はやっぱり不要だと思いました。
大学受験みたく覚えようとして覚えられるというよりも、深く理解していたりよく使っていると勝手に覚えてくるのがプログラミングだとナイスな勉強法なのではないかと思います。
暗記っぽい学習とか網羅的に何周するって勉強方法はプログラミングだと微妙ッスナ。
なんとなく動画を見る⇒微妙
ドットインストールとかをプログラミングに入門したての頃にただぼ〜っと寝っ転がりながらよく見ていました。
が、微妙だったと思います。（ドットインストールをdisっているわけではないです。ドットインストール最初に文法学習のために少しだけやりました。）
動画をなんとなく見て追っていても、今まで書いてあることと同様に定着はしないので、いくら見たところで実装はできなかったりします。
見て満足する、てきな。
ただ、普段実装している技術内容を動画とかをぼーっと見て小さいコツとかを知る分には良いような気がします。
例えば、Reactやっているとして、「memo化とかよく分からないな〜」と思っているのをReact系の解説動画を見て理解を深めるようなイメージです。これは良きです。
アウトプットの受け皿もなくなんとなく動画をひたすら見る系の学習方法は微妙でした。
繰り返しになるんですけど、アウトプットの受け皿があれば、イケてると思います。
コードの細かい部分にこだわりすぎる⇒微妙
ぼくはPythonからプログラミングを始めたんですが、forループではなくてリスト内包表記をひたすら使うようにしたことがありました。
理由としてはforループよりもリスト内包表記のほうが速度が早いからって知ったからです。
明らかに可読性が悪くなってもリスト内包表記にしないと！みたく思ってなぜかそういう結構どうでもいいことに時間と意識を多く使っていましたが、普通に時間の無駄でした。
実際いわゆる実務でも全てのコードが最強に良いコードで書かれてはいなくて、ある程度は妥協しながらコードはマージされていきます。
本当に大規模なソフトウェアとかだとそういうわけではなくて超シビアにコードレビューとQA（動作確認）をすることになるらしいですが、基本的にはチーム内でのある程度の水準を満たせればOKなのです。
なので、コードの細かい部分にこだわりすぎてしまうのは、あんまり良い勉強法ではないと思いますし個人的には微妙でした。
あとは何が正解ってのも案外ないというか、地味にトレードオフな側面もあります。
JavaScriptで配列のループ処理する時にforループとforEachどっちがいいんじゃ？って言われると、自分はforEach派だけどforループを使う人もいて別に同じっちゃ同じという。
厳密には速度とかが違うらしいですけど、大体の場合は問題にならないです。
という、ある程度はざっくりプログラミングを勉強してコードレビューで指摘が入らない程度の水準にすればOKっていう布教でした。
（細かいところにこだわりすぎると進まないし）
説明などを書写⇒意味なし
技術書（ドキュメントも）を読むといろいろその技術に対しての解説が書かれていると思います。
例えば、Reactは仮想DOMを用いることで高速にウンタラカンタラ〜とかDockerはカーネルを共有するから高速ウンヌンってやつなんですけど、それを書写していた頃が一時期ありました。
すごく微妙というかこれに関しては完全に無駄だったと思います。
まず実装することに関して言うと、そういう説明文を理解していなくても実装はできます。
Reactが仮想DOMうんぬんみたいなことを深く理解してコードを書いてる人なんて全体の1%もいないと思いますし、仮に仮想DOMうんぬんを理解していたとしても実務で求められる品質やスピードに到達しないReact力だといくら詳しくても「遅くて使えないやつ」となるだけです。
あと、そういった説明文はある程度調べてると勝手に覚えます。
いくら書写量を増やして勉強した気になってもチーム開発なら実装できないと微妙なわけでございます。
個人開発の場合でも、結局コード書いて何か成果物が出てこないなら微妙なので、なんにせよコード書くことが大事ですね。
まとめ
とりあえずアウトプット（チーム開発で実務をやる、個人開発のコードを書く、コーディング試験の問題を解く）とかそういった事をベースにプログラミングを勉強しない場合は、かけてる時間に対してあんまり技術力は伸びないと思います。
思いますというよりも、個人的にはすごく微妙でした。
逆に言うなら、以下のような勉強方法は良い感じだと思っています。
- アプリを作りながら勉強する
- 実務でコードを書きつつ不明点を調べる・学習する
目的のためのインプット（勉強）になっていれば基本的に身につくし、なんとなくできた方がいいかなぐらいのやつは大体身につかない、と、思います！！いや、思いました！！！
