2019/05/15 コードを読むことについて

今日はまとめたいことがあったので日記はおやすみ

---

自分のエンジニア的な力量不足を感じていて、もっとコード読みたいし、書いてかないとなあみたいなことをぼんやり考えていたんだけど、書くのは仕事でできるとして、コードを読むということがちょっと頭打ち気味だなあと思っていた。

今までの仕事では、そこまでライブラリのコードまで深追いするということはやってこなかったし、やったとしてもよくわからないという感想だけが残るみたいな状況がよく続いていて、はてどうしたものかなあと考えていたところ、ちょっと良さげな方法が出かかっているので試そうとしている。

それがエラーや予期しない挙動に遭遇したら、その部分のコードを読む。という方法で、もしかしたら多くの人は既に実践しているのかもしれない。

この方法がいいのは、時間のかけかたのバランスの良さと、コードの追いやすさ、そしてコードを追うモチベーションの作りやすさにあると思う。

時間のかけかたのバランスの良さ。これは、とにかく内容を把握してくぞ！みたいな感じでコードを読み始めると際限なく時間を消費してしまうのに対して、普段コード書いているときにたまにエラーに遭遇して、たまにだけ深掘りして読むみたいなことができるという意味でのバランスの良さのこと。

コードの追いやすさ。これはエラーに遭遇したとき限定なんだけど、エラーメッセージで検索すると一発で該当箇所が引っかかったりするので、読みたいところにすぐたどり着きやすい状況になりやすいということ。

コードを追うモチベーションの作りやすさ。これはまあぼんやりあの部分を把握したい。みたいなぼんやりした欲求ではなくて、この入力値の場合どうしてエラーになってしまうのかというより具体的な欲求にできるので、より心が折れにくいし、より調査が効率的にできるということ。

というわけで今日はjestのエラーに引っかかったので、jestのコードを追っかけてみて、初めてだし、JS、TSの業務経験そこまで無いからほぼ無理かなあと思ってたけど、追いかけるだけならエラー箇所と、そこにたどり着くまでのコンテキストはわからないなりにも実行開始部分から大体流れを把握できたし、エラーメッセージ以外にも実際にエラーになったであろう部分、そしてそれが呼び方とどういう関係なのかも大体把握できた。あれ、すごくねこれ？

なのでこれ続けてけば結構現実的なのでは・・・？みたいな手応えはちょっと感じた。わからないとこだらけで結局具体的な原因特定までは行けなかったけど、全体感が分かったというのはでかい。これからも気づいたらコードを読んでいこうと思う。

ライブラリのコード読むのが結構めんどうではあって、いちいちgit cloneとかしてられないので、他の人はどうしているのかは気になる。githubガチガチに使ってるんだろうか。自分は今の所sourcegraphをつかっている。

これ、ちゃんとした記事にしようかと思ったけど単なる思いつきなのでもうちょい実践してみて、良さげだったらそうするかも。ひとまずはやってみます。という報告みたいな感じで残しておくことにした。