ライブラリの場合、実際に自分の書いたコードで使っている箇所があれば『前後の処理の意味もわからず使っている』なんてことはないですよね?基本的な流れは把握して使っているのであれば、比較的追いかけやすいと思います。
フレームワークの場合、自分のコードをフレームワークの枠組みに載せて、フレームワーク側から動かしてもらう形になるでしょうから、フレームワークから自分のコードがどう扱われているのか?という観点で調べると比較的追いかけやすいかもしれません。あとは、エントリポイントや処理のトリガーとなる箇所から調べていくのも一つですね。
実行中にデバッガなりのツールが使えるのであれば、どのように値が変動しているのか?など動かしながら読み進めると、更に効果的だと思いますが、前後関係も理解できない部分から把握するのは難しいと思います。解っている部分から着実に広げていく。というのが切り崩すための基本ではないでしょうか?
規模が大きくなってくると、実装だけではなく分析や設計の知識を齧っておいた方が読解はしやすいでしょう。特にクラスやモジュール/名前空間なりの範囲で適度に責任分担されているでしょうから、例えばオブジェクト指向のクラスベースのライブラリやフレームワークであれば、デザインパターンなどを齧っておくと全体の役割分担の視点から、ある種のパターンを見出すこともできるようになるでしょう。
眠たくなる体系的な勉強をしておいた方が良いシーンもあるとは思いますが、とにかく、自分でコードを書いて読んで動かして、といった実践を繰り返すだけでも、体系的な勉強を補助する経験則というパターンが得られますから、自分に合うやり方を探して、コツコツ続けるのが良いのではないでしょうか?
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。