どうもこたにんです。
リファレンスを読む程度の能力
ちょっとしたツールを作ることがありまして、とあるAPIリファレンスを読んでいたのですよ。
実現したい機能を満たすAPIがないか、リファレンスページを辿って探すわけです。
「なんちゃら.getみたいなのあればいいなあ」とか。
「なんちゃら.listみたいなのあればいいなあ」とか、思うわけです。
そう思いながらペラペラと、リファレンスページの階層を下っていくわけです。
そうして、ほしい感じのレスポンスを持つAPI巡り合うわけです。
これ、リファレンスページから欲しいものを見つける。
っていうのを当たり前にやっているんだけど、これってスキルだよなって思って。
そもそも何かを技術的に実現したいときにまずやるのって、ぐぐる。
例えば「Twitterのフォロワー一覧からフォロー数1000人以上のアカウントを取得したい」ってなったとき。
「Twitter API フォロワー 取得」みたいなググり方をするのかな。
そしたらなんだかQiitaやら何やらが出てきて、サンプルコード付きで理解が進むみたいな。
そのやり方って、悪くはないんだけど。
だけどそうしたときに手に入るのって往々にして「サンプルコード付きの実装」じゃない？
そうしたときに、言語を読み替えるコストだったり、実はバグが潜んでたりなど、自分ではどうしようもない不確実な部分と向き合う必要が出てくる気がしていて。
そのリスクというかコストを取っ払うには、自分でリファレンス読んだほうが良い気がするんだなあ。
実装するための生の情報を手に入れて、そこから自前で組んでいく。
これこそが実装者としての力の見せ所だし、一番楽しいポイントなんじゃないのかなって。
だからリファレンスからやりたいことを見つける方がなんだかいいのかもしれないって。
たしかに実装するときに詰まることはままある。
だがそれすらも自力で解決するからこそ、実装力がつく。
し、さらにリファレンスを読むときの勘、みたいなものも養われる。
リファレンスを読むことって、結構大事なんじゃないのかな。
というお話でした。
（ちなみに作ろうとしていたものはTwitterとは全く関係ない）
それでは聴いてください。
