序文
本日は本来、東福寺で紅葉を鑑賞する予定だった。
結論、行かなかった。
というのも、「Go言語で作るインタプリタ」という書籍を一緒にペアプロする約束をしていたからである。
（その約束を忘れていた）
しかし、大いに学びがありヒントを得たのでメモすることにした。
初めてのインタプリタ開発
抽象構文木を構築するように構造体を定義していき、スモールステップ（著者の歩幅）でテスト駆動開発しながら開発を進めていく形式だった。
書かれているソースコードを理解するために、かなり何度も同じ箇所を読み直した。
なぜ読めないのか考察をしてみたら、「脳のメモリからデータ構造やメソッドが揮発するから」であった。
さらに、同じメソッドを何度も呼び出しているうちにどこに戻るのか忘れてしまうという現象に陥った。
この事象にあったのはこの業界に飛び込んで最初の1.5年くらいまでだったと思う。
自分が関わってきたwebシステムはスモールなので、読んでるうちにメモリから揮発するなんて事象はここ数年味わったことがなかった。
伸びる感じがした。
ペアプロしてくれた人からのフィードバック
「焦りすぎなんだと思います」
非常に良かった。
疲れてくると自分は投げやりになるのだが、実はここに「焦り」が混ざり込んでさらに理解を難しくしているのだった。
そこを意識してからは「なぜ読めてないのか」が理解できるようになり、コードを追えるようになった。
どうしたらコードが読めるようになるか？
手法はたくさんある。
繰り返し処理を追う、わかる人と一緒にとことんやる。
著者は個人用のデバッグコードを仕込んで値を追っていた。
そうしてデータ構造の中に格納した値がどう変遷していくかに気を付けて読み進めていく。
webシステムがなんなのかよくわからずにひたすらにやっていた頃を思い出した。
実はもう成長の種自体は持っていたのだった。
それを明確なスキルセットとして意識して使えるようになることが重要だった。
気づき
イミュータブルな実装が流行っているが、理由がわかってきた。
腕があまりなくても対応できるようになる代物ということである。
一度生成されたオブジェクトを不変として扱うことで、余計なことを考えずに済む。
ある程度わかりやすくなる。
様々な設計論（フォルダ構造とそれにつける修飾子の論）が存在しているが、それはつまるところ「どんな人が書いてもルールさえ守ればある程度の綺麗さを保てる」という代物なんだな、と理解した。
（速度は知らない。パズルが得意ならすぐ慣れると思う。僕としては、スタートアップのケースであれば、無駄にファイルを大量に生やす行為には疑問を覚えるのだが・・・）
最後に
自分としては、読めるコード、書けるコードを増やしていくため、さらに様々なソフトウェアの中身を読んでいきたいと思う。
そのために、わからなくても繰り返し処理を追ったり、デバッグコードをうまく仕込んだり、「諦めないこと」「焦らないこと」をモットーにやっていきたいと思った。
