使い勝手の良い「console.log」ばかり使ってはいませんか。
一人開発の場合はやってしまいがちですが、多人数の開発やライブラリ開発では特に注意が必要です。
ログレベルを意識しつつ、目的に応じて使い分けるようにしていきましょう。
こんな方におすすめ
- ログレベルを意識せず使っている方
- ライブラリ開発に興味がある方
メインのログレベルは全部で「5」つ。目的に応じて使い分けよう！
参考: JSのconsole種類とログレベルについて
- log: 汎用ログ
- debug: 開発用(基本は本人) 確実に消すべき
- info: 注釈を加えたいとき 提案レベル。ログレベル1くらい。
- warn: 注意 将来的に削除される、仕様が変わるなど後で対応が必要になる系統。ログレベル2くらい。
- error: 現段階で何らかのエラーがある場合 なるべく早く対応が必要。ログレベル3くらい。
「log」は汎用的過ぎて本番では不向き。「debug」と合わせて最終的には削除しよう！
console系の関数でも、「log」はとりわけ明確な目的がありません。
そもそもコンソールデバッグに対する機能にも関わらず、「ログ」とだけでは漠然としています。
「debug」よりさらに、一時的なものとして意識するようにしましょう。
console機能は「開発者」へのメッセージ。残す場合は「いつまで」「何を」するか示そう！
例に上げたものでいえば、「warn(ワーニング)」以上は今から対応してほしいものにするべきだと思います。
※もしくは、近日中にリリースをする場合など。
理想を言うと、コンソールを見れば何をどうすればいいか、すぐに理解できる状態であることです。
特に「error」は現段階で障害がある状態なので、なるべく分かりやすくなるように配慮しましょう。
意外と答えが書いてある？ライブラリ系のコンソール
実際どのようなメッセージを出すかは、既存のライブラリを見てみるといいでしょう。
有名どころでは、JQueryやnode系のツールを使ったサイトでしょうか。
公開中のサイトでも案外エラーが出ているので、ある程度巡回すればエラーを確認できると思います。
翻訳を使えば英語が苦手でも理解できると思うので、どのレベルでメッセージを出すべきか温度感をつかんでおきましょう。
特に親切なツールでは、修正方法の予測を書いてくれているものもあります。
まとめ: consoleはログレベルを意識することで、開発にも役立つ武器になる！
ざっくりログレベルとメッセージの関係などを理解できると、次のようなことに役立てます。
ポイント
- 自分が機能をリリースした時、開発者に伝えるべきメッセージの考え方が理解できる
- 発生しているログレベルを見て、今危険なのか、やがて使えなくなるのか、など当たりをつけられる
- トレンド・主流の対応を知ることができる
エラーハンドリングができるとリリースまでの意識がグッと高まります。
習得にはフレームワークなどのドキュメントはおすすめなので、ぜひ読んでみましょう。
