コンソールのワーニングは必ず消せ！放置することによる3つの危険性

コンソールのワーニングは、ついつい後回しにしてしまうことがあると思います。

現在時点でエラーではないものの、特に将来に対して大きなサインであることもあるでしょう。

今回は、特に3つのポイントに絞って注意すべき理由を書きます。

また、過去にコンソール(JS)の概要をまとめてますので、ぜひご参照ください。

はじめに

コンソールに表示されるワーニングは、開発者からの「警告」にあたります。

統一概念はありませんが、レベルとしては5～7段階程度あるうちの、緊急(emergency)、エラー(error)、注意(warning)ぐらいの順です。

中上位程度に位置しており、意外と高い印象ではないでしょうか。

ワーニングが示す意味

イメージとしては、そのまま信号が近いでしょう。

まさに「止まれ」といった感じで、ワーニングを残したままのリリースは避けるべきです。

黄色信号と同様、近い時期に「赤信号」になるというリスクを抱えた機能を使った状態と言えます。

ワーニングに対する最もシンプルな対応について

コンソールメッセージは、開発者またはブラウザから出されるものです。

場合によっては、具体例が示されている時があります。

既にベストな方法があるということなので、要件が合いそうなら素直に従いましょう。

ワーニングを残してはいけない3つのポイントとは？

ポイント1：コードの品質や将来的なリスクに影響する

先ほどの例を引き継いで表せば、ワーニングは黄色信号のようなものです。

要は、それを無視することは黄色のまま道路を突っ切るようなものです。

※あくまで例としてなので、さすがに黄色信号を突っ切るよりはまし。

ベストプラクティス(最適な状態)を無視した状態と言えるでしょう。

常に余計なコードを抱えた状態になるので、保守対応にも悪影響を与える可能性があります。

ポイント2：やがてエラーになる可能性を抱えている

ワーニングの出る代表的な例としては、「非推奨」機能を使用している場合です。

非推奨機能は、次かその次あたりには削除される可能性があります。

したがって、近日中に使えなくなる(=エラーになる)ということです。

どのようなワーニングが出ているかは、当然ながら読んでみないと分かりません。

結局確認するのであれば、一緒に直してしまうのがやはりベストと言えます。

ポイント3：セキュリティリスクになる場合がある

ディフェンス面でいうと、やや脆弱性のある機能にワーニングが付く場合があります。

あるあるで言うと、CORSやXSS系統だと思います。

とりわけ、中長期でメンテナンスがされていない場合は、リリース後に発覚した脆弱性を指摘されている場合もあるでしょう。

ワーニングを修正するための具体的な方法について

ダメなことは分かった。ではどうするか？

もう少し実践的な部分に踏み込んでいきたいと思います。

まずはメッセージを読む

自明ではありますが、内容を把握することが大切です。

過去記事でも書いた通り、場合によっては改善案も書いてあります。

対応するにも一番の近道になりますので、第一に取り組みましょう。

メッセージで分からない場合は、原文検索やフォーラムを利用する

この点については、エラー発生時と同じです。

メッセージを読んでも分からない場合は、翻訳を通さず検索してみましょう。

恐らく、英語系の質問サイトやフォーラムが出てきます。

解決方法が分かったら、最も最低限の対応を行う

プログラミングの基本(YAGNI原則)に従うことに近いです。

提案や改善方法が分かったら、必要最低限の改修を行いましょう。

余計な機能は、バグやまた別な脆弱性に繋がるかもしれません。

まとめ: ワーニングは病気の初期症状。重病に発展する前に治療しよう！

ワーニングを見るうえで重要なのは、既知の問題であるという点です。

※知らなかったらメッセージも出せないですね。

おおよその場合、「より良い手段」が存在するでしょう。

互換性として残しているだけで、既にレガシーである可能性もあります。

リリースの品質レベルとして、エラーの修正は当然です。

一歩先として、ワーニングも出さないようにすることを心がけてはいかがでしょうか。