勉強法(2) 測らないと、分かったことにならない

「分かった」と思った直後に、間違っていたことが何度かありました。

いちばん効いたのは、自分の理解を外から確かめる手順を持つことでした。今回はその話です。

1. 数字を出したら、始まりと終わりを見る#

記事の読み進み具合を出すバーを作りました。動いています。そう思っていたら、開いた瞬間の数字が目に入りました。

ページを開いた瞬間に9.5%を指していました。まだ何もしていません。

調べると、計算そのものは正しかった。画面の下端を基準にしていたので、開いた時点で本文の一部がすでに映っていたのです。「画面に映った本文の割合」としては9.5%が正確な値でした。

2. 試した環境が、確かめたい条件を満たしているか#

同じ読了判定で、もっと危ない間違いをしました。

ブラウザを自動で動かして、記事を最後までスクロールさせました。読了として記録されません。「記録されない不具合がある」と結論を出しかけました。

念のため、スクロールのイベントが何回起きたかを数えました。

発火回数: 0

自動で動かしているタブでは、スクロールのイベントがそもそも発生していませんでした。不具合が無くても、同じ結果になります。

そのあとは、ブラウザで試すのをやめて、実際の寸法を使って計算で確かめました。

3. 原因が分からないときは、半分に割る#

コードを含む記事を投稿しようとしたら、サーバーに弾かれました。403が返るだけで、理由は何も出ません。

本文は4500字あります。どこが原因かは分かりません。

そこで、本文を4つに割って1つずつ試しました。

最終的に、引っかかっていたのは2つの書き方だけだと分かりました。理由を推測せずに済んだのは、割って試したからです。

確かめ方は、覚えるものではなかった#

3つ並べてみると、覚えている知識はほとんど出てきません。

どれも技術というより手順です。そして3つとも、自分の理解を疑うところから始まっています。

今回の学び#

まず、「動いた」は「合っている」ではないということ。進捗バーは最初から最後まで動いていました。動きを見ているかぎり、9.5%から始まっていることには気づけません。

次に、確かめた結果より先に、確かめ方を確かめること。0回しか起きていないイベントを待っていたら、どんな実装でも同じ結果になります。出た結果を信じる前に、その試し方で違いが出るのかを見る必要がありました。

そして、分からないときは推測ではなく分割すること。4500字から2つの書き方まで絞るのに、知識は要りませんでした。要ったのは、半分に割って試す根気だけでした。