常に全部できているわけではないが、こういうことを試せばいいのではないかというのをメモ
調査
- 公式サイトに書いてある目的とかを読む
- ググる
- なるべく1年以内の情報から読む
- 同じワードでの検索結果の上位10件くらいを読む
- API referenceを読む
- 何に使われるものなのかを調べる
- 何とよく比較されているのかを調べる
- 他に何と組み合わせることが多いのか、設計・構成を調べる
- Google Trendsで代替技術・周辺技術の利用傾向を見る
- 周辺ライブラリの開発の状況を見る
- Githubのissueの状態、最終コミット
- 最近のChangeLog
- 利用状況を見る
- Githubスター数
- npmのダウンロード数など
- Qiitaでよくストックされている記事
- はてブのホッテントリ
- 誰かに質問できるようなコミュニティやフォーラムがあるか探す
- キーパーソンのブログを熟読する
手を動かす
- 作業ディレクトリを作ってgit initする
- 公式チュートリアルを写経する
- スニペット/プロトタイプを作る
- 何を使って何を作るのかを決める
- どういうインターフェース・設計・データフローなのかを知る
- 何をすれば動き、何をしなければ動かないのかを知る
- 必要以上にいろいろ組み入れない
- 動きを理解できる最小のコードベースに保つ
- つまらないものを作る
- できたものが面白いか、意味があるかに拘泥しない
- ローカルでもよいのでまめにgit commitする
- AWS,Heroku,Netlifyなどのクラウドにデプロイしてみる
- ローカルでの挙動とどうちがうかしらべる
- メモリ利用量・処理速度に影響しそうなパラメータを変更してみる
- 既存コードベースに適用してみる
- 調べたりコードを書いたらKobitoにメモする
- 他の選択肢と比べてどんなpros/consがあるのかを知る
詰まったら
- 複数のプロトタイプをつくり、うまくいく条件をみつける
- デバッガを使う
- ログをよく読む・ログレベルを上げる
- エラーメッセージでググる
- 誰かのサンプルコードをググる
- 例えばGithubでCodeの検索だけに絞ってライブラリ名などで検索するとだいたいの使い方がわかるので、見比べて問題の切り分けをする
- テストを実行する
- 利用するライブラリのバージョンを上げたり下げたりする
- バグの再現性を調べる
- いくつか前のコミットに戻ってみる
- git bisectでバグの混入時点を特定する
- 最初からやり直してうまくいったら、とりあえず先へ進む