わからない技術をわかる技術
コード書いてる時、わからないことをわかるのは大変。(わかりますね?)
知らん単語とか出てくると、うーんと唸りながら調べるけど、やっぱわからない。そういうことが多かった時期は、コードを書くにしても手が進まず結構辛かった覚えがある。
最近だと、静的解析、CQRS + ES、DIツールの理解などを進める際に時間を消費してしまった。が、前に比べてわからないことにキャッチアップする手順が画一化されつつあり、頭を抱え続ける時間は減ったように思う。
大体いつもどんな風に進めてるか、2通りに分けて明文化する。
参考資料が多く存在する時
静的解析とかはこういうケース。すでに参考資料がたくさんある場合は、整理されてるものなら幅広く集める。
1. 公式ドキュメントを集める
2. 良さそうな解説資料・ウェブサイト・書籍などをリストアップする(10件くらい)
3. 汎用的かつわかりやすい解説と、自分の得意な言語でそれを実装したものがあればピックアップして繰り返し電車とかで読む
という流れを踏む。集めたURLはSlackにメモっておく。
参考資料があまりない時
解説記事がない場合はダイレクトにソースをみるしかない。GoのAnalyzerとかは最近追加された機能なのでまじで資料なくてウケた。
資料が豊富にあるときとは調べ方が若干違ってて、少数でもいいから実装にクリティカルに効くソースを集めるようにしてる。
1. 公式ドキュメントを集める
2. 参考になるソースコードを集める
3. 自分が実装で使う部分のコードだけピックアップして、どう利用するか戦略を立てる
同じくSlackにペタってやる。
最後の共通手順:実装する
そらそうだという話だが、実践しないとなんもわからない。静的解析は(privateリポジトリだけど)APIクライアントの実装で使ってて、海外のカンファレンスネタとしてCfP出したりするのに使ってる。
CLIツール作ったりサッとサーバーに導入したりすると便利。特定の画面・APIだけツールを組み込んでみるとか。
重要なのは、あとあとメンテするモチベが湧かない(役に立たない)ものを作ったり、「入門しました!」で終わる実装。トークネタになるけど小規模な実装ってどんなもんだろなあ、というのを考えて、実装目標を決めたら調べ始めると良い。
この記事が気に入ったらサポートをしてみませんか?