shadowing により本番バグを発生させてしまった話

技術

はじめに

機能開発においてテストは極めて重要である。

しかし、エンジニアとしての最初の頃はその意識が不十分であり、いくつかの失敗を経験した。

今回は自戒の意味も込めて、数年前に失敗してしまった話を記録として残しておく。

背景

Go を用いた API の改修を行っていた。

内容自体は比較的シンプルなものであったが、意図せず変数の shadowing を発生させてしまった。

その結果、返却される値が 0 となり、クライアント側ではその値をもとに処理が行われたため、想定外の挙動が発生し、本番バグへとつながった。

なぜ起きたのか

原因は主に以下の3点である:

  • 動作確認を行っていれば発見可能な問題であった
  • shadowing を検知する仕組みが存在しなかった
  • そもそも「shadowing」という概念を理解していなかった

動作確認を怠っていた点

今回のケースでは、新規作成処理を実際に動かし、値が正しく設定されているかを確認していれば、早期に異常に気づくことができた。

しかし当時は、開発した機能が正しく動作するかどうかを十分に確認せずにコードを反映してしまっていた。

この失敗を通じて、「本番反映前には必ず動作確認を行う」という意識を強く持ち、反映前の動作チェックを徹底して行うようになった。

shadowing の検知不足

当時は、変数の shadowing を検知するような静的解析ツールを導入していなかった。

現在では、go vet に -shadow オプションを加えて、shadowing を自動検出できるようにしている。

参考:https://engineer-want-to-grow.com/go-shadow/

ただし、Go において頻出する err 変数の再定義については例外として扱い、除外するように設定している。

まとめ

本件を通じて、「開発したら必ず動作確認を行う」という基本的な原則の重要性をあらためて実感した。

また、shadowing というエラー要因についても、実際に失敗したことで深く理解することができた。

今後も同様のミスを繰り返さぬよう、仕組みと意識の両面から改善を図っていきたい。