大規模ソースコードの読み方

23,894 views
22,235 views

Published on

大規模ソースコードを読むためのコツについて記載

Published in: Software
0 Comments
88 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
23,894
On SlideShare
0
From Embeds
0
Number of Embeds
1,728
Actions
Shares
0
Downloads
51
Comments
0
Likes
88
Embeds 0
No embeds

No notes for slide

大規模ソースコードの読み方

  1. 1. 1 大規模ソースコードの読み方 v1.0.0 2016/2/13 Satoru Takeuchi <satoru.takeuchi@gmail.com>
  2. 2. 2 はじめに ● 大規模ソースコード(以下ソースと記載)を、未 経験者が前提知識を持たない状態で読もうとす ると、ほぼ確実に挫折する ● 例えばLinux kernelの場合一千万行をゆうに超える ● 一日千行読んでも一万日かかる… ● 本スライドは大規模ソースを読む上でのコツを いくつか紹介 ● 想定読者 ● これまで大規模ソースを見たことが無い人/見よう としたが、挫折した人 ● Linux/UNIXユーザ
  3. 3. 3 目次 ● ソースを読む前 ● 目的の明確化 ● 設計意図の理解 ● 読むソースの絞り込み ● ソースを読むとき ● タグジャンプツールの使用 ● 実際に動かしてみる ● まとめ
  4. 4. 4 目的の明確化 ● まず自分がどの機能の実装を理解したいのかを明確化 ● 目的が無いまま闇雲にソースの字面を眺めるだけでは 内容の理解は困難 ● 「全てを理解しなくては!」や「とりあえずmain()か ら芋づる式に辿ろう」という考えかたは挫折への近道 ● 大規模プログラムでは、全ソースを完璧に理解して いる開発者は少ない/居ない。全部を理解していな いのは別に恥ずかしいことではない ● 最終目的はあくまで機能の実装を理解することであり、 ソースを読むのは手段であることを常に意識しておく
  5. 5. 5 設計意図の理解 ● 機能が何のためにあるのか、どういう方針で設 計されているかという意図を理解する ● ドキュメントを見る ● マニュアル、コメント、パッチのコミットログ ● 自分なりの仮説を立てる ● この機能を実現するためには設計はこうなってい るはず…と考える ● 構造体の関連図がわかっていると、仮説を立て やすい ● アルゴリズム+データ構造=プログラム ● 仮説が外れていても、無いよりは全然よい
  6. 6. 6 gitの活用 ● 設計意図を知るのにはgitが役立つ ● 無論ソースがgitで管理されていることが前提 ● 他のVCSについては割愛 ● ここでは2つのgitコマンドを紹介 ● git log ● git blame
  7. 7. 7 git log ● git log <path>: <path>を変更したパッチの一覧を 表示 ● 機能追加、実装の再設計をしたパッチセットの先頭 パッチに設計意図が書いていることが多い ● パッチそのものではなく、当該パッチセットを開発 MLに投稿した際の”[PATCH 0/X]”というメールに 書いていることもある
  8. 8. 8 git blame ● git blame <file>: <file>の各行を最後に変更した パッチを表示 ● <file>の各行が、どのような意図で現在そうなって いるかがわかる ● もちろんまともなコミットログがあることが前提 ● git logより細かい粒度の情報が得られる
  9. 9. 9 読むソースの絞り込み ● ソース全体のうちの、どこを読めばいいのか、 及び、どこを読まなくてよいのかを絞り込む ● 余計なところを”読まない”ことが重要 ● なるべく読む対象のソースを少なくする ● 大規模ソースは大抵複数、かつ階層状のモ ジュールに細分化されている
  10. 10. 10 絞り込みの例 ● 興味のある機能の実行中に出てくるメッセージ を用いてgrepをかけることによって、関連ソー スの位置を知る ● デバッガを使ってプログラム内の興味のある機 能を動かしてみることによって、当該機能の ソース上の位置を知る
  11. 11. 11 実際にソースを読むにあたって ● ここからようやく実際にソースを熟読する ● これまでに述べたことが全てできていれば、必 要な作業の八割程度は終わっている ● 一部しかできていなくても、漫然とソースを読むよ りは、はるかに良い ● ソースを読む前の作業は戦略、実際にソースを読む 作業は戦術
  12. 12. 12 タグジャンプツールの使用 ● ソースを読むにあたって、テキストエディタと基本コマン ドだけでソースを読むのは非常に面倒。以下、一例。 ● foo()という関数内でbar()という関数を呼んでいる。bar()が何 をしている関数か知りたい ● foo()の引数の型であるstruct hogeの定義を知りたい ● grepコマンドなどでソースを全て検索した上で、マッチ したファイルを開いてカーソルを所定の場所に移動、と いった操作を毎回実行するのは面倒、かつ非効率 ● bar()やstruct hogeの調査後、foo()の調査を再開したいよ うな場合はさらに面倒 ● これを解決するのがタグジャンプツール
  13. 13. 13 タグジャンプツールの仕組み ● ソースコードを走査して、ソースのどこにどのような シンボル(前述の例でいうとfoo,bar,およびhoge)が定義 されており、それぞれどこで使用されているのかを記 録したデータベースを作成 ● エディタなどからシンボルを指定すると、当該シンボ ルの定義場所、および使用箇所に自動的にジャンプ ● 検索ごとの全ソース調査が不要なため、高速。マシ ンパワーも節約可能 ● ジャンプ履歴を覚えているため、たとえばfoo()から bar()へのジャンプ後に、元のfoo()に戻ることも可能
  14. 14. 14 タグの形式 ● タグには色々な形式があり、それぞれ一長一 短。以下に著名なものを記載 ● cscope ● GNU Global ● ctags ● etags ● 詳細はそれぞれのドキュメントを参照 ● タグジャンプ相当機能を内蔵している開発環境 もある(例: eclipse)
  15. 15. 15 プログラムを動かしてみる ● ソースを読みつつプログラムを実際に動かして みるのは非常に有用 ● デバッガを用いてプログラムを動かしてみることに よって、関数の呼び出し関係、引数、およびデータ 構造の意味を知る ● 興味のある箇所にprintf()などのデバッグメッセー ジを突っ込んで実行してみる ● ソースを少し変更した上で挙動の変化を見る ● ソースの読み/書き、実行を行き来することに よってソースの内容を理解
  16. 16. 16 まとめ ● 大規模ソースを読むためにはソースを読む前/読 むときについて様々なコツがある ● 最終目標はソースを読むことではなく、実装を 理解することだと常に意識する ● 機能の実装を理解するために必要なことの八割 は、ソースを読む前に終わっている ● 実際にソースを読む際も、ただ読むだけではな く、タグジャンプツールを使ったり、読み書き 実行を行き来したりして、作業を効率化する
  17. 17. 17 Happy Hacking!

×