コードを読む

どんな技？

ファイルを1行目から順に追うのをやめて、入口を1か所だけ決めるところから始めます。実行が始まる関数や、画面のボタンが押されたときに呼ばれる処理を選び、そこから呼び出し先へ飛び、戻ってきたら次の分岐へ進みます。たどった順番は短いメモに残し、関数の名前と役割の対応だけを控えていきます。読み切ることではなく、一つの動きを追い切ることを目標にします。

なぜ効くのか

文章には書いてある順番しかありませんが、プログラムには実行される順番という別の順序が最初から入っています。呼び出しをたどる読み方は、その順序に沿って一度に見る範囲を狭めます。作業記憶に載せきれずに迷子になる場面が減るという説明になります。熟練者ほど直線的には読まないという観察はありますが、同じ読み方を真似れば分かるようになるかは確かめられていません。

やり方

入口を決めたら、呼び出しを3段ほど下って15分で行き止まりまで進みます。名前と役割の対応をメモにして、分からない関数は名前だけ控えて飛ばします。次に同じ流れを逆からたどり、どこで値が変わるかを追います。行き止まりまで来たら、流れを口で言い直してみます。全体を見渡す前に、1本の流れを通しで終わらせるほうが先になります。

はまりどころ

読む順番を変えても、その言語や書き方を知らなければ進みません。速さを決めるのは目の動かし方ではないという話は文章と同じで、語彙と背景知識の側が先に来ます。全部を読む方針は行き止まりになりやすく、逆に流れだけを追うと全体の形が見えないままです。ページを写真のように読む方法のような、一目で掴む手立てはありません。

確かめられ方

Busjahn ら 2015 の眼球運動の研究で、コードは自然文ほど直線的には読まれず、熟練者ほど実行の流れを追う読み方をしていたと報告されています。見ているのは読んでいる最中の目の動きで、画面に映したプログラムを読む場面に限られます。その読み方を教えた効果を比べた研究は乏しく、真似れば理解が上がるかは分かっていません。

解説動画（海外・英語）: Using Developer Eye Movements to Assess Expertise while Reading Source Code／ICSME 2020

視線で熟練度を測る: 開発者の視線を測り、ソースコードを読むときの熟練者と初心者の違いを見た研究発表です。読み方のくせから熟練度を見分けられるかを問い、分かれば開発者への支援や、教育用の道具づくりに使えるという見通しを置いています。もう一つの問いは、どの部分に視線が集まるかです。

使ったデータ: 使ったのは2015年に集められた視線計測のデータで、公開されている大きなソフトウェアを題材に、22人の開発者が三つの変更作業でバグを探し、直せるなら直すという課題に取り組んだものです。この発表ではそのうち一つの課題の18人分だけを取り出して分析しています。

要素ごとに数える: 解析ではツールでソースコードから要素の一覧を取り出し、語と行・列の位置を持たせたうえで視線のデータと突き合わせています。そして見られた要素の割合を、識別子やメソッドの宣言部、型、演算子、キーワード、引数の名前と型、条件分岐や繰り返しの行といった単位ごとに数えました。

初心者ほど広く見る: 調べたどの部分でも、初心者のほうが多くの要素に視線を向けていました。識別子やメソッドの宣言、変数の名前と型、キーワード、演算子などでは差が統計的に有意で、注意がいちばん集まる要素に挙がったのはメソッドの宣言部です。熟練者は細部まで追わないという結果でした。

これから確かめる: 発表者は今後の課題として、別のコード作業の視線データを足して同じ調べ方をやり直すことと、視線計測のほかの指標でも熟練度を見分けられるか試すことを挙げています。つまりこの発表は観察と再現の途中で、その読み方をまねると理解が上がるのかまでは扱っていません。