ディープダイブの正しいやり方：書籍・公式ドキュメント・ソースコードを使いこなす技術学習の順番

バグをひとつ直したら新たなバグが十個も出てきた——そんな経験はありませんか？あるいは、コードがあまりにも奇妙な壊れ方をするので、「自分は本当にこのコードを理解できているのだろうか」と不安になることもあるでしょう。そんなときこそ、テーマを根本から掘り下げる「ディープダイブ（deep dive）」の出番です。

しかし、深く学ぶ必要があると気づくこと自体は、ほんの第一歩にすぎません。実際にどうやってトピックを基礎から学べばいいのでしょうか？そして、知識が自然に引き出せるレベルまで到達するには、どうすればいいのでしょう？

どこから始めるべきか？

学習の入り口はたくさんあります。私が短時間でトピックを広く深く学びたいとき、最初に選ぶのはやはり書籍です。たとえばGitをディープダイブしたいなら、『Pro Git』という本がまさに求めているものになるでしょう。

書籍がディープダイブに向いている理由は、その網羅性にあります。中規模程度のトピックなら、200〜400ページほどの本でおおむねカバーできます。読み終えた時点でエキスパートにはなれないかもしれませんが、十分な理解と、その後の成長につながる確かな基礎が手に入ります。この基礎があると、次の段階としてソースコードや仕様書を読む際にも大きく役立ちます。

とはいえ、本を買いたくないケースもありますし、そもそも自分の扱っているトピックに関する本が存在しないこともあります。そんなときは、どこを見ればいいのでしょう？

有力な代替手段は公式ドキュメントです。Railsのようなフレームワークの特定の領域や、OAuthのようなWeb技術を深く学ぶ場合、公式ドキュメントは特に相性が良い相手です。

プロジェクトやフレームワークを学ぶなら、「○○ガイド（Guide）」と名付けられたドキュメントから始めるのが最善策です。たとえば私は、Railsを始めたばかりの開発者にはRails Guidesをよく勧めますし、Elixir GuidesもElixirのコードの書き方を学ぶ絶好の入門地点になります。

ただし、ガイドはブログ記事より網羅的だとはいえ、完全に網羅しているわけではありません。そこでおすすめなのが、ガイドを出発点として、RDocのようなリファレンスドキュメントへと進むアプローチです。

リファレンス資料は、無数のメソッドやクラスを文脈の中に位置づける手段がないまま読むと、非常に理解しづらいものです。構造のない細部の寄せ集めに見えてしまうからです。だからこそ、リファレンスはガイドや書籍とセットで使うときに最も力を発揮すると感じています。

たとえば、ActiveModelのAPIドキュメントを読み込む以上にActiveModelを深く教えてくれるものはほとんどありません。しかし、ActiveModelガイドがあれば、断片的な知識を全体として組み立てられます。

「ほとんどない」と述べたのは、公式ドキュメントよりもさらに網羅的な情報源がひとつだけ存在するからです。それがソースコードを読むことです。ただし、ソースコードを読むことは本を読むようなものではなく、経験と練習、そして導きが必要になります。最も詳細な情報源である一方、最初に取り組むべき場所ではありません。

こうした文章教材を掘り下げていくと、答えの見つからない疑問がいくつか必ず残ります。そうしたら、遠慮なく質問しましょう。ライブラリの作者は通常、誰よりもそのライブラリに対する優れたメンタルモデルを持っており、自身の思考プロセスを辿りながら助けてくれるはずです。多くのオープンソースプロジェクトやフレームワークの作者は、SlackやIRCなどで連絡を受け付けています。詳細はプロジェクトページで確認できることが多いでしょう。

作者本人にアクセスできない環境でも、質問することはできます。同僚や、より経験を積んだ開発者に聞いてみましょう。友人にひとつの未解決の質問を投げかけただけで、それ以外のすべてがパズルのように噛み合う瞬間に、何度出会ってきたことか。

私が実践しているディープダイブの順序

ディープダイブの必要性に気づいたら、いくつかの入り口があります。私が普段たどる順序は以下の通りです。

1. 書籍、または公式ガイド
2. 公式リファレンスドキュメント（RDocなど）や、仕様書・RFC
3. ソースコード

そして、途中で生じた理解のギャップは質問によって埋めていきます。決して最速のプロセスではありませんが、これまで見つけた中では、学習の広さと深さのバランスが最も取れた方法です。

あなたは日頃からディープダイブを実践していますか？もしそうなら、役立ったリソースをぜひ教えてください。コメントをお待ちしています！