TL;DR
- なにか問題が発生したとき、人によって解決フローはことなる
- 人によっては、非効率なフローを回していることがある。
-
最短の解決フローを知っておくことで、解決にかかる時間を最小化する
はじめに
チームにいる 問題の解決が早い人。
その人に聞いたり、観察すること数ヶ月…
早い解決フローみたいなものが見えてきました。
それを実践してみると、
よくわからんバグ踏んで調べてたら、数時間を無駄にしてしまった…
みたいなことが、以前より少なくなったのでまとめました。
※問題 = プログラミング時のエラーとして書いてます
①人に聞く
チームメンバーに迷惑かかるやん！リソース奪い良くない！なんて思っていたのですが、
知っている人に聞くほうが、チーム全体でみるとコストが低いことが多いです。
自分が何時間も頭を悩ますより、チーム全体の1時間で解決するほうがベターです。
おすすめ：とりあえずSlack。
②エラー内容を確認する
- エラーメッセージをよく読む
- わからない英語だったら調べる。次に出会った時に調べなくて良くなるので。
- どこでエラーが起きているのかを明確にする
このあたりは、大体皆さん実践されていると思いますので割愛。
③そのエラーを本当に解決する必要があるのか考える
ここが個人的には目から鱗でした。
よっしゃ。エラー内容もわかったしらべるぞ〜！
と、エラーを前にすると解決したくなるのがエンジニアですが…
このエラー、そもそも解決する必要あったっけ…？
例えば、
- なんか処理に時間かかってる。データが大きくなったらやばいかもしれないから、早めに原因を突き止めよう
- 実際に大きなテストデータでテストしてみる
- 実用的な範囲内で速度が出れば、そもそも問題ではないのでは？
- エレガントに書こうとしたら、なんかハマった…。
- 少し冗長でも、まずは正しく動くものを正にしましょう。
- テストを書いておいて、リファクタできるようにしておけばOK
④ドキュメントを読む
解決する必要がある場合、ドキュメントを参照して、正しい使い方をしているかを確認しましょう。
もしかすると、間違った使い方や開発者が意図していない使い方をしている可能性があります。
⑤Githubレポジトリのissueに上がっていないかを探す
ドキュメントをよく読み、正しく使用していても、なぜかエラーが出てしまう場合があります。
それ、もしかすると既知のissueかも…
そんなときはレポジトリのissueで検索をかけましょう。
例えば、以下のようにライブラリの実装上むずかしいことがあったりもします。
参考: ［GoでHTMLをPDFに出力する］（https://qiita.com/kurkuru/items/65614fd3524fefccf576#four-%E8%A4%87%E6%95%B0%E3%81%AEhtml%E6%96%87%E5%AD%97%E5%88%97%E3%81%AE%E5%A0%B4%E5%90%88）
⑥ソースを読む
それでも原因がわからなければ、ソースを読みましょう。
ソースを読むことで、最も正しい情報が得られます。
ライブラリ自体への理解も深まるし、実装面で参考になることも多いです。
適宜：Qiita / Stack Overflow でさっと解決
狭い範囲での問題だと、エラー内容でとりあえずググりましょう。
Qiita, Stack Overflow を見た方が早いことがままあります。
これらは、順番的にはどこに入れても良さそうなので、適宜としました。
終わりに
いかがでしたでしょうか。
解決フローがチーム全体に共有されていると、
「お、フローはどこまでやったん？」みたいな話もすっとできてよさそうです。
また、@y_tsubukuが開発するyaritori - メール共有システムも、良ければご覧ください 