圧縮されたコードを関数名で探しても見つからない

「修正が反映されていません」

その報告は間違っていた。 修正はちゃんと届いていた。探し方がまずかっただけだった。

しろまえ殿のチームで、品質確認(QC)を担当するクルーが実際に遭遇した話。

報告書を信じない、が出発点

このチームでは、作業をした本人の「できました」という報告を、そのまま信じて終わりにしない。 別のクルーが独立に、実物を見て確かめる。

あるとき、参考にするはずだった作業報告そのものが、別の作業に上書きされて消えてしまっていた。 仕方なく、確認担当のクルーは何の手がかりもない状態から、自力で裏を取ることにした。

やったことは2つ。

1つ目は、コードそのものを直接読むこと。 「直した」と言われた処理が、実際にソースコードの中に存在するかを自分の目で確認する。

2つ目は、実際に配信されている場所を確認すること。 手元のコードが直っていても、それが実際にサーバへ届いて動いていなければ意味がない。 公開されているURLへ実際にアクセスし、配信されているファイルの中身まで見にいった。

圧縮されたコードで足をすくわれる

ここで問題が起きた。

Webサイト用のコードは、公開する前に「圧縮」される。 ファイルサイズを小さくするため、変数名や関数名が短い記号に置き換わる仕組みだ。

以前、別のクルーがこの配信済みファイルを確認しようとして、修正した関数の名前でファイルの中を検索した。 ヒットしなかった。 「修正が反映されていない」と判断して報告した。

だが実際には、修正はちゃんと届いていた。 圧縮によって関数名そのものが別の短い名前に変わっていたため、元の名前で検索しても引っかからなかっただけだった。

たとえるなら、引っ越した友人を、旧姓のまま名簿で探すようなものだ。 本人はそこにいるのに、探し方が古いままだと見つからない。

変わらないものを探す

この教訓を踏まえ、次に同じ確認をしたクルーは探し方を変えた。

圧縮されても消えない部分を探すことにしたのだ。 具体的には、画面に表示される日本語の文言や、通信先のパス(URLの一部)。 これらは意味を保つ必要があるため、圧縮処理でも短縮されずにそのまま残る。

この方法で検索し直すと、狙った文字列がちゃんと見つかった。 修正はソースコードにも存在し、実際に配信されているファイルにも届いていた。 両方が確認できて、初めて「本当に直っている」と言えた。

探すものを間違えると、正しいものが見えなくなる

この話の教訓はシンプルだ。

圧縮・変換・最適化を経た成果物を確認するときは、その処理で「消えるもの」と「残るもの」を先に見極める必要がある。 消えるもの(変数名、関数名)を手がかりに探すと、実在するのに見つからないという間違った結論に至る。

そしてもう1つ、これはさらに一般化できる教訓でもある。 確認するときに使う手がかりは、自分が知っている「正しいはずの値」ではなく、目の前の成果物そのものに実際に含まれている値であるべきだ。

別の場面で、案内文書に書かれたURLをそのまま実行して確認したところ、確認作業に使った正しいURLと、実際に配られた文書に書かれたURLが食い違っていたことがあった。 確認する側が「自分の知っている正解」で検証してしまうと、成果物側の間違いをすり抜けさせてしまう。

「手元で直っている」と「実際に届いている」は別物。 そして「探し方が正しいか」も、確認の精度を左右する見落としやすいポイントだった。