こんにちは～Webエンジニアのマッシュルーム🍄です！
JavaScriptで開発をしていると、何かとお世話になるものがありますよね！
そう、これです。
console.log();変数の中身を確認したいとき。
処理がどこまで進んでいるか知りたいとき。
エラーの原因が分からないとき。
とりあえずconsole.logを置いてみる。
そんな経験がある方も多いのではないでしょうか。
僕もよく使います。
しかし、問題が解決した後に、ふと考えることがあります。
このconsole.log、いつ消せばいいんだろう？
今回は、そんなconsole.logの消しどきについて考えてみます！
📋 目次
- console.logは便利
- 問題は、役目を終えた後
- console.logは、すべて消すべき？
- デバッグ用ログと運用ログは違う
- ログには「何が起きたか」を残す
- 出力してはいけない情報もある
- 本番運用ではconsole.logを卒業する
- では、いつ消すべきなのか？
- 最後に
１．console.logは便利
例えば、次の処理が想定通りに動かないとします。
const totalPrice = calculateTotalPrice(items);計算結果を確認したい場合、最も手軽なのはconsole.logです。
const totalPrice = calculateTotalPrice(items);
console.log(totalPrice);これだけで、変数の中身を確認できます。
デバッガーを使う方法もありますが、少し確認したいだけなら、console.logの方が早いこともあります。
処理の通過地点を確認するため、次のような書き方をすることもあります。
console.log("ここまで走ったよー！");さらに原因が分からなくなると、
console.log("ここまではOKだよ！ 1");
console.log("ここまではOKだよ！ 2");
console.log("ここまではOKだよ！ 3");と増えていきます。
決して美しいとは言えませんが、問題を調査するという目的では、とても優秀です。
２．問題は、役目を終えた後
調査中のconsole.logには、明確な目的があります。
しかし、問題が解決すると、その目的は失われます。
console.log("ここまで走ったよー！");
console.log(user);
console.log("成功！やったー！！");このようなログが残ったまま本番環境へリリースされると、少しずつ困ることが増えてきます。
ブラウザのコンソールには、開発者にしか分からないメッセージが大量に表示されます。
サーバー側では、必要のないログによって本当に確認したい情報が埋もれてしまいます。
ログの保存量が増えれば、確認や保管にも余計なコストが掛かります。
役目を終えたconsole.logは、残しておくだけでノイズになってしまうのです。
３．console.logは、すべて消すべき？
では、本番環境からconsole.logをすべて消せばよいのでしょうか。
僕は、そうではないと思っています。
例えば次のようなログは、運用中の調査に役立つことがあります。
console.log("注文処理を開始しました");console.log("外部APIとの通信に失敗しました");処理がいつ開始され、どこで失敗したのか。
本番環境で発生した問題を調査するうえで、ログは大切な手掛かりになります。
つまり、消すべきなのはログそのものではありません。
目的を説明できないログ
を消すべきなのだと思います。
４．デバッグ用ログと運用ログは違う
次のようなログは、主に開発中の確認を目的としています。
console.log("ここだよ！");
console.log(data);
console.log("aaaa");問題が解決した後も残す理由は、ほとんどありません。
一方で、運用のために残すログには、明確な目的があります。
console.log("注文処理を開始しました", { orderId: order.id, });このログには、
- 何の処理が始まったのか
- どの注文が対象なのか
という情報があります。
障害が発生した際に、調査の材料として利用できます。
同じconsole.logでも、役割はまったく異なります。
５．ログには「何が起きたか」を残す
変数をそのまま出力するだけでは、後から見たときに意味が分からないことがあります。
console.log(result);これだけでは、何の結果なのか分かりません。
少し情報を加えるだけで、ログの意味が伝わりやすくなります。
console.log("決済APIの実行結果", { orderId: order.id, status: result.status, });重要なのは、開発している今の自分が分かることではありません。
障害が起きた数ヶ月後に、別の誰かが見ても分かることです。
ログもコードと同じように、未来の誰かに読まれるものなのかもしれません。
６．出力してはいけない情報もある
ログを残す際には、注意しなければならないことがあります。
例えば、次のような情報です。
console.log(user);userの中に、氏名や住所、電話番号などが含まれているかもしれません。
ほかにも、
- パスワード
- アクセストークン
- クレジットカード情報
- セッション情報
- 個人情報
などを出力してしまうと、大きな問題につながる可能性があります。
オブジェクトを丸ごと出力するのは簡単です。
しかし、本当に必要なのがユーザーIDだけなら、必要な項目だけを出力する方が安全です。
console.log("ユーザー情報を更新しました", { userId: user.id, });ログは調査に役立つものですが、情報を残す行為でもあります。
便利だからこそ、何を出力するかは慎重に考える必要があります。
７．本番運用ではconsole.logを卒業する
小さなシステムであれば、console.logだけでも十分かもしれません。
しかし、システムが大きくなると、すべてのログを同じ方法で出力するのは難しくなります。
例えば、ログには次のような種類があります。
logger.info("注文処理を開始しました");
logger.warn("APIの応答に時間が掛かっています");
logger.error("注文処理に失敗しました");- 正常な処理を記録するinfo
- 注意が必要な状態を示すwarn
- エラーを示すerror
このように重要度を分けておけば、必要なログを探しやすくなります。
本番環境で継続的に残すのであれば、console.logをそのまま使うのではなく、ログ出力の仕組みを整えることも大切です。
８．では、いつ消すべきなのか？
僕が考えるconsole.logの消しどきは、
調査が終わり、そのログの目的がなくなったとき
です。
コードを完成させたとき。
レビューに出す前。
コミットする前。
プルリクエストを作成する前。
一度、追加したconsole.logを見直してみます。
そのログを見て、次の問いに答えられるでしょうか。
誰が、いつ、何のために見るログなのか？
答えられないのであれば、そのログは役目を終えているのかもしれません。
逆に、障害調査や運用監視に必要なのであれば、単純に消すのではなく、伝わるログへ書き直すべきです。
９．最後に
いかがでしょうか^^
console.logは、とても便利ですよね。
原因が分からないときにとりあえず置いてみるだけで、問題解決の糸口になることがあります。
だから、使うこと自体は悪くありません。
大切なのは、置いた後です。
調査のために置いたのか。
運用のために残すのか。
それとも、ただ消し忘れているだけなのか。
コミットする前に、少しだけコンソールを確認してみる。
そこに、
console.log("ここまで走ったよー！");が残っていたら、そのログはきっともう役目を終えています。
console.logを書く技術よりも、適切なタイミングで消す技術。
それも、エンジニアに必要な小さな習慣なのかもしれません。
それでは、また次回の記事でお会いしましょう～🍄
