自分は、よくある「まず文法から完璧に覚える」みたいな勉強法がかなり苦手です。
もちろん基礎は大事だと思っています。 でも、自分の場合は「これを作りたい」が先にないと、あまり頭に入ってきません。
なので普段は、
アイデアを思いつく
そのために必要な技術を考える
技術選定する
概念を理解する
AIで壁打ちする
実装する
自分のプロダクトのコードを読み返す
みたいな流れで学ぶことが多いです。
まず「何を作りたいか」が先に来る
例えば、
こういうUI作りたい
AIを使ったこんな体験作れそう
この不便さ解決したい
こういうサービス面白そう
みたいなアイデアから始まります。
その後に、
じゃあリアルタイム通信必要？ 状態管理どうする？ バックエンド何が合う？ そもそもこの技術って何を解決するために存在してる？
みたいに、必要になった技術を掘っていきます。
なので、自分にとって技術は「目的」ではなく「実現手段」に近いです。
文法より先に「概念」を理解したい
自分はAPIの使い方だけ覚えても、結構すぐ忘れます。
それより、
なぜこの技術が存在するのか
何を解決したいのか
他と何が違うのか
どんなトレードオフがあるのか
みたいな「概念」を先に理解したくなります。
例えば最近だと、
型システム
状態管理
Server Component
副作用
アーキテクチャ
みたいな“仕組み側”に興味を持つことが増えました。
「便利だから使う」より、 「なぜ必要なのか」を知りたいタイプなんだと思います。
AIは「答え生成機」じゃなくて壁打ち相手として使っている
最近かなりAIを使っています。
ただ、「全部書いてもらう」というよりは、
サンプルコードを読ませる
この設計の意図を聞く
他の実装との違いを聞く
自分の理解を整理する
疑問を掘る
みたいな使い方が多いです。
実装中に、
この責務分離って必要？ この状態管理ややこしくない？ なんでここで再レンダリングされる？ もっとシンプルにできない？
みたいな感じで壁打ちしています。
AIを「完成コードを出す機械」というより、 「理解を深めるための対話相手」として使っている感覚に近いです。
自分のプロダクトを読み返して学ぶことが多い
自分はOSSを読むというより、 自分で作ったプロダクトのコードを後から読み返すことが多いです。
実装した直後は気づかなかったけど、
この状態管理ぐちゃぐちゃだな
ここ責務分けた方がよかったな
このコンポーネント肥大化してるな
なんでこの実装にしたんだっけ
この設計あとから辛くなってるな
みたいなことが結構見えてきます。
逆に、
この設計意外と良かったな
って気づくこともあります。
なので、自分の中では「作る → 振り返る → 改善する」がかなり大きい学習ループになっています。
アーキテクチャを最初から完璧にやろうとしていない
これは賛否あると思います。
でも自分は、個人開発の段階では「まず動かす」をかなり重視しています。
もちろん設計は大事です。 ただ、最初から完璧なアーキテクチャを組もうとしても、自分の場合は抽象概念だけ膨らんでしまいました。
なので、
まず作る
問題が出る
なぜ辛いか考える
必要になった設計を学ぶ
みたいな流れの方が理解しやすかったです。
最近は逆に、「大規模になるとなんで設計が必要なのか」が少しずつ分かってきました。
まだ試行錯誤中
この勉強法が正解かは正直まだ分かりません。
CSの基礎や数学みたいに、体系的に積み上げないといけない部分もあると思っています。
ただ、自分は「作りたい」から入る方が圧倒的に学びが続くので、今はこのスタイルで色々試しています。
同じように、
勉強だけだと続かない
作りながら学びたい
AIを壁打ち相手にしてる
実装しながら理解したい
みたいな人がいたら、結構相性のいい学び方かもしれません。