小説を書くならば小説を読んだ方がいいし、絵を描くならば絵を見たほうがいいです。当然、最終的には小説を書いたり絵を描いたりすることが目的なのですが、なにも吸収しなければ何も出て来ない、というのが常ですね。たまに、小説も絵も見ないで書/描ける人もいますが、それは例外的な人なので、一般的な話として制限しておきます。
あと、将棋がうまくなるのも、将棋の棋譜を読むのが重要なので、やたらに将棋を指すだけではいけません。棋譜を読むのもひとつの手です。
自分の経験上でも、良質のコード読むのが手っ取り早いです。私が駆け出し＝つまりは会社に入って新人のプログラマだった頃には、インターネット等は無かったので、主に参考にできるのは、少ないコンピュータ書籍とマニュアル、そして既存のコードでした。まだ、コンピュータ書が少なかった時期なので、プログラム言語（VB2.0 や C++ の頃）を学ぶにはマニュアルしかなかった時代があります。もっとも、既に C 言語や Fortran の書籍はいくつかあったので、初心者本というか教科書は手元に置いておきます。当時 VB2.0 はまだ新しかったので、参考にできる書籍はなくマニュアルが頼りでした。
あとは、既存のコードとなるわけですが、果たしてそれが良質なコードであるかどうかはわかりません。今考えれば、とんでもないクソコードだった気もしますし、新人だった当時も私もクソコードを書いて納品していた覚えがあります。まあ、C++ にかぶれていた時期があるので、現場は Unix C なんだけどオブジェクト指向（のつもり）で書いて、実に読みづらかったんですよ。他人が読めるってのは大切です。特に、当時はコンパイルのスピードも遅かったし、テスト駆動以前の時代だったので、紙面でのコードレビューは重要でした。それでも、会社の先輩のコードは「読む」のが普通で、そうしないと仕事にならなかったですよね。
あと、私の場合は “コードを読む” ことに関しては、
- 大学時代に、炉計算の Fortran のコードを読む必要があった
- OpenSSL を修正して検証ツールを作る関係上、OpenSSL のコードを読んだ
ってのが大きいです。炉計算は日立の技術者が作ったもので、これを修正するのが自分だったので読まざるを得ませんでした。OpenSSL は、ガラケーの暗号化のテストツールなのですが、データ解析するために OpenSSL を使ってデバッグコードや特殊なスイッチ（証明書の不正など）を入れざるを得ませんでした。
どちらにしても、大量の “良質な” コードを読まねばならず、これが幸いしたと言えます。
ただし、この方法はいまとなっては効率が悪いです。当時としてもどうかと思うけど、読むにしてもいきなり OpenSSL は大変です。GNU ツールのいくかから始めたほうがよいでしょう。
今だったら何のコードを大量に読むか？
いまだったら GitHub にある OSS のコードを読みます。プログラム言語は JavaScript でも Python でもなんでもいいのですが、できることならば IDE でデバッグ実行と変数が見れるようなプログラム言語がいいです。プログラムをステップ実行して、メモリの中身を確認できるものがいいですね。
まあ、そうなると Python と JavaScript はあまり適してはいないので（ステップ実行できるツールをもっていれば、それでもいいです）、Java とか C# のほうがやりやすいですね。コマンドラインツールでも GUI ツールでも途中でプログラムを止めて中身を確認することができます。ただし、仕事の都合上、React での Web 開発や、Python を使った科学計算をすることも多いでしょう。そういう場合は、真っ先に print デバッグの手法（JavaScript ならば Console.log 、Python ならば print）を覚えて、動作をログ出力しながら動きを確かめていきます。
仕事で使うコードが OSS のプログラム言語とは異なっている場合は、AI チャットを使ってコンバートしてもらうのも良いです。プログラム言語は、似たような文法が多いので（英語、フランス語、ドイツ語の関係のように）ひとつのプログラム言語を覚えておけば、他のプログラム言語を覚えやすいという傾向があります。
いままでは、初心者本を一冊買って文法を下読みするのですが（私の場合は今でもそれをやりますが）、いまだと AI のチャットを使って、コードを変換してもらうといいです。
AI のプロンプトで「○○言語に変換して」と頼むと、高確率できれいに変換してくれます。
当然、固有のライブラリまでは変換してくれないので、これは別途探す必要があります。あくまで、プログラム言語の文法やいくつかの構文の使い方を学ぶときに使います。
固有なライブラリを使っているときは、変換先の言語で適当なライブラリを探して貰います。そして、そのライブラリの使い方についてサンプルコードを AI に書いて貰います。
ライブラリ込みで変換することも可能なのです。が、AI エージェントだと結構な確率で変えてくれるのですが、コードが長くなり複雑になりがちで学習には適してはいません。できるだけ、ライブラリはひとつに限定して確かめていったほうが良いです。
プログラム言語の歴史として、手続き型、構造化、関数型あるいはオブジェクト指向、という形で進化してきているので、最初は手続き型の文法（if文やfor文など）を覚えたあとで、構造化（関数の使い方、構造体の使い方）を学ぶとよいです。その後、状態（ステート）について、オブジェクト指向型を使うか関数型を使うか選んでください。Web API の呼び出しは、構造化のレベルで十分可能なので、オブジェクト指向/関数型言語を最初のうちは意識する必要はありません。
効率よりも、確実に動くコードを目指していきます。
自分で書いたコードは、逐一 AI にレビューして貰うといいです。仕事でチーム開発をしている場合はレビューがあると思いますが（いや、無い場合も多いのでしょうが）、少なくともプログラム言語の学習をしている間にレビューを頼むということはほぼ不可能です。プログラミング教室に行って高いお金を払ってレビューして貰うことも可能ではあるのですが（最近 X では聞かなくなってしまったので、プログラミング教室が駆逐されたのか、果たして…）、AI にレビューをして貰ったほうが安価だし手軽です。
ただし、AI を使ったレビューにしても冗長なところが多いので、いまひとつ何を言っているのかわからないと思います。このようなときは、書き出した全体のレビューを AI に頼むのではなく、部分的にコードを選択して AI にレビューを頼むと良いです。この方法は、仕事でもよくやります。Agent モードを使うとコード全体を直しがちになるので、Ask モードを使って部分的な関数やコードをレビューして貰います。
特に、自分にとってあまり詳しくない言語にはこれが効いてきます。仕事でも Kotlin/Swift のコードは部分レビューを多用しています。
昔風に、コードを精読するのもいいのですが、もっと大量に多読する形でもよいです。
ちなみに、小説ですが私の場合は2,3か月程度で、こんな風に多読をします。金銭的には新刊で買うと辛いので BOOK OFF 等で 100 円程度で買ってきます。いわゆる乱読を意識的にやります。1冊読むのに、1,2日間ぐらいで時間で言えば、2時間弱位の流し読みです。これで文章のパターンを覚えた上で、もろもろの短編を書く、というのを今やっています（乱読自体は20歳代のころからやっているのですが、それは書評日記を書くためだったりするので、ちょっと違う）
上記の学習方法については、以下の本に書いてあります。これは Python がターゲットなのですが、他の言語でもいけますね…って形で書いたんですが、意外と売れないので次がありません（汗
まあ、Python 自体を学ぶのではなくて「Python の学び方を学ぶ」という手法を実際に示したものなので、読むと「いままで AI を使って学んできたやりかたと同じじゃん」という感想しになってしまうのも無理からぬことです。既に AI を使った学び方を知っている人じゃなくて、知らない人向けなので、既に知っているひとにとっては not for me なんですよね。
