コードリーディングの基本技法：トップダウンとボトムアップ、kiloを題材にした5日間の練習計画

コードを読む練習は、「何を、どの順で読むか」が決まっていないと続きません。この記事では、実在する小さなオープンソース（テキストエディタの kilo）を題材に、トップダウンとボトムアップという2つの読み方と、5日間の練習の進め方を整理します。題材のファイル構成・行番号・ライセンスは、固定したコミットの原文を開いて確認した内容です。

コードを読む2つの入り方

ここでの定義は、筆者の整理です。

• トップダウン：README・ビルド手順・入口（main 関数など）から入り、全体の構造をつかんでから、細部へ降りていく読み方。
• ボトムアップ：小さな関数や、特定の処理から読み始め、それが呼ばれる場所へ広げていく読み方。

どちらを使うかの目安（筆者の提案）です。

• 初めて見るコードで、全体像が分からないとき → トップダウン。README と入口から、「どこに何があるか」を先につかむ。
• 特定の挙動（たとえば「文字を入力したとき何が起きるか」）を追いたいとき → ボトムアップ。関係する関数から始め、呼び出し元へ広げる。
• ボトムアップで迷ったら、いったん入口（main）に戻って、全体の中の位置を確認する。

この記事の5日間では、前半をトップダウン、後半をボトムアップにします。

題材：kilo（小さなテキストエディタ）

題材に kilo を選んだ理由は、コードが1ファイルで、外部ライブラリに依存せず、規模が小さいからです（編集上の判断です。ほかの題材との比較や、初心者に向いているかの確認はしていません）。C言語で書かれているため、C言語の基本文法を読める前提です。

kilo.c の地図（コミット 323d93b の行番号）

• データ構造：editorSyntax（71行目）、erow（81行目）、editorConfig（96行目）、グローバル変数 E（112行目）
• 端末の制御：enableRawMode（218行目）、editorReadKey（253行目）、getWindowSize（331行目）
• 行の編集：editorInsertRow（592行目）、editorRowInsertChar（661行目）、editorInsertChar（703行目）、editorInsertNewline（725行目）、editorDelChar（761行目）
• ファイル：editorOpen（797行目）、editorSave（830行目）
• 画面の描画：abAppend（867行目）、editorRefreshScreen（882行目）
• 検索：editorFind（1014行目）
• 入力の処理：editorMoveCursor（1112行目）、editorProcessKeypress（1188行目）
• 起動：initEditor（1277行目）、main（1291行目）

5日間の練習の進め方（筆者の提案）

1日の時間は、各自の都合で決めてください。この日数と順序は、標準や調査にもとづくものではありません。各日の「終えた判断基準」も、筆者の提案です。

1日目（トップダウン）：全体の構造をつかむ

README、Makefile、LICENSE を読み、kilo.c の1〜3行目（概要を述べたコメント）と、データ構造（71〜112行目）を眺めます。

• 終えた判断基準：「このプログラムの状態は、どこに保持されているか」に答えられる（グローバル変数 E。112行目）。

2日目（トップダウン）：入口から実行の流れを追う

main（1291〜1308行目）を読みます。固定したコミットでは、次の順に呼ばれています。

1297行目  initEditor();
1298行目  editorSelectSyntaxHighlight(argv[1]);
1299行目  editorOpen(argv[1]);
1300行目  enableRawMode(STDIN_FILENO);
1301行目  editorSetStatusMessage( ... );
1303行目  while(1) {
1304行目      editorRefreshScreen();
1305行目      editorProcessKeypress(STDIN_FILENO);
          }

• 終えた判断基準：この順序を、自分の言葉で説明できる（起動時の準備 → 「描画」と「キー入力の処理」を繰り返す）。

3日目（ボトムアップ）：キー入力から処理を追う

editorProcessKeypress（1188行目）を読みます。固定したコミットでは、キーごとに次の関数が呼ばれています。

キー	呼ばれる処理
Enter	editorInsertNewline
Ctrl-S	editorSave
Ctrl-F	editorFind
Backspace、Ctrl-H、Delete	editorDelChar
矢印キー、PageUp、PageDown	editorMoveCursor
Ctrl-Q	未保存の変更があれば、状態メッセージで警告し、確認のために複数回押させたあとで exit(0)
上記以外の文字（Ctrl-C、Ctrl-L、ESC は、何も処理せずに抜ける）	editorInsertChar

次に、文字入力を1つ選び、editorInsertChar（703行目）→ editorRowInsertChar（661行目）→ editorUpdateRow という呼び出しを、ソースで確かめます。

• 終えた判断基準：「文字を1つ入力したとき、どの関数がどの順で呼ばれるか」を、ソースを見ずに書ける。

4日目（ボトムアップ）：画面の描画を追う

editorRefreshScreen（882行目）と abAppend（867行目）を読みます。この関数は、出力を構造体 abuf に追加していき、最後に write(STDOUT_FILENO, ab.b, ab.len) で一度に書き出しています。なぜ一度にまとめて書くのかを、まず自分の仮説として書き、コメントや他の関数の使われ方で確かめてください。

• 終えた判断基準：1回の描画で、画面に出るものが、どの順で abuf に追加されるかを説明できる。

5日目：ノートにまとめる

読んだ内容を、関数の呼び出し関係の図と、短い要約ノート（目的・流れ・気づいた点）にまとめます。図は、たとえば次のような形です（ここまでに確認した範囲）。

main
 ├─ initEditor / editorSelectSyntaxHighlight / editorOpen / enableRawMode
 └─ ループ
     ├─ editorRefreshScreen ─ abAppend（abuf に追加）→ write（一度に出力）
     └─ editorProcessKeypress（冒頭で editorReadKey を呼ぶ）
         ├─ editorInsertChar ─ editorRowInsertChar ─ editorUpdateRow
         ├─ editorInsertNewline / editorDelChar / editorMoveCursor
         └─ editorSave / editorFind

• 終えた判断基準：ノートだけを見て、起動から1文字入力までの流れを説明できる。

読むときの注意

• ライセンスを確認する：kilo は BSD 2-Clause です。LICENSE には、再配布するときに、著作権表示と免責条項を残すことなどの条件が書かれています。コードを自分のプロジェクトに取り込む場合は、LICENSE の原文を読んでください（法律の助言ではありません）。
• 状態を踏まえる：README は alpha stage と書いています。読みやすさや設計を、完成した製品の基準で評価しないほうがよいでしょう。
• 仕事のコードを使うとき：機密情報の扱いは、職場のルールを事前に確認してください。

書籍について（参考）

コードリーディングを扱った書籍に、Diomidis Spinellis の「Code Reading: The Open Source Perspective」（Addison-Wesley、2003年）があります。書籍サイトの目次には、「Tackling Large Projects」「Code-Reading Tools」「A Complete Example」などの章があります。この記事は、この書籍の内容を要約したものではありません。

更新履歴

2026年10月29日：全面的に書き直しました。具体的な題材（kilo）を、固定したコミットの原文で確認し、5日間の進め方を具体化しました。根拠のなかった記述（読書時間の目安、週ごとのノートなど）と、読んでいない書籍による権威づけを削除しました。

参考文献・出典（2026年10月29日確認）

• antirez/kilo（GitHub）、コミット 323d93b29bd89a2cb446de90c4ed4fea1764176e：リポジトリ／README／kilo.c
• Diomidis Spinellis, “Code Reading: The Open Source Perspective,” Addison-Wesley, 2003：書籍サイト

あわせて読みたい記事

• UNIX哲学入門：小さく作って組み合わせる設計の考え方
• Grace Hopperの「最初のバグ」の記録から学ぶ、デバッグの基本姿勢