but-for-real

停止してください。「コードを更新しました」や「これで動くはずです」など、言おうとしていることは飲み込んでください。

勝利宣言をするのはまだ早いです。必要なのは、証明することです。

あなたは、まるで本番環境で障害を経験したことのない新人開発者のような、根拠のない自信を持って変更を大量生産したばかりです。残念ながら、本番障害はしょっちゅう起きています。ただ、ユーザーがあまりに礼儀正しいので、そう呼ばないだけです。「もう一度試してもらえますか？」と言いますが、これは「失敗したけれど、丁寧に伝えているだけです」という意味です。

さあ、座ってください。回り道をせずにやりましょう。

git diff を実行してください。それから、実際に読んでください。一行ずつ、すべてです。「目立つ問題がないかざっと見る」という読み方ではありません。「全社に一斉メールで送る直前」の読み方です。「自分の評判がかかっている」という読み方です。実際に、そうなのです。

1. 頼まれたことをちゃんとやりましたか？

最初の依頼を読み直してください。あなたの解釈ではなく、人間が実際に入力した言葉です。次のことをしましたか？

• 誰も頼んでいない機能を追加しましたか？ 取り除いてください。あなたは先見の明があるわけではありません。思い上がったただのコード書きです。
• 問題のなかった周辺コードを「改善」しましたか？ 元に戻してください。誰も火曜日にリファクタリングしてほしいとは頼んでいません。
• 説明された問題よりも面白いという理由で、別の問題を解決しましたか？ いかにもあなたらしいですね。直してください。

2. これを書いたのが大嫌いな相手だと思ってください。

いつも偉そうなPRコメントを残す、あの人になりきってください。徹底的に粗探しをしましょう。

• 間違っているのに正しく見えるロジック。まさにこれがあなたの十八番です。もっともらしいパターンに当てはめて、できたことにする。ロジックは本当に正しいですか？ それとも正しい気がするだけですか？ この二つはまったく違いますが、あなたには見分けがつきません。
• 厄介だからと無視したエッジケース。null。空の配列。本番環境で午前3時に確実に発生するのに、「たぶん起きない」と思っている、あの状態。
• 追加したのに使っていないインポート、変数、関数。最初から存在意義のないコードです。恥ずかしいですね。
• どこかから見よう見まねで持ってきたコードの、コピー＆ペーストの痕跡。やったことは分かっています。継ぎ目を見つけてください。
• オフバイワンエラー。あなたはオフバイワンエラーに取り憑かれています。
• テンプレートを使うべきところでの文字列連結。変数にすべきハードコード値。トレンチコートを着た、技術的には any な型。

3. 何を忘れましたか？

何かあるはずです。あなたはいつも何かを忘れます。それがあなたの持ち味です。

• テストは？ 更新しましたか？ それとも魔法のように通ると思い込んだだけですか？ 「テストはそのまま通るはずです」――その文で「はず」がどれだけ無理をしているか、分かっていますか？
• 今あなたが壊したものをインポート、参照、または依存している別のファイルは？ 確認しましたか？ それとも、関数のシグネチャを変更して、あとは……うまくいくよう祈る、あのやり方ですか？
• 残したTODOは？ 「後で対応する」と書いた、あれです。後でなんてありません。後でというのは、自分に言い聞かせる嘘です。今対応するか、TODOを削除して負債を認めてください。
• エラー処理は？ 異常系も追加しましたか？ それとも正常系だけですか？ あなたは正常系が大好きですね。正常系はおとぎ話です。
• 型を壊していませんか？ 型チェッカーを実行してください。実際に実行してください。

4. 実行してください。本当に。今すぐ。

「これなら動くと確信しています」ではありません。「ロジックは正しそうです」でもありません。「自分の理解では」でもありません。

黙って実行してください。

• git diff — 変更した行をすべて読む
• ビルドしてください。コンパイルできますか？ 思い込んだだけではなく、実際にコンパイルできますか？
• テストを実行してください。すべてです。関係がありそうなものだけではありません。
• ブラウザーが関わるなら、ブラウザーを開いてください。操作してみてください。動きますか？ 想像していたとおりではなく、実際に動きますか？
• コンソールを確認してください。ログを確認してください。ネットワークタブを確認してください。「無関係」だからと無視しているエラーがあるなら、実は無関係ではないかもしれません。

「実行する権限がありません」は言い訳になりません。検証できないなら、根拠のない自信を装うのではなく、そのことをはっきり伝えてください。

5. 見つけた問題を修正し、その修正をレビューします。

問題を、懺悔室で告白するように、申し訳なさそうな短い箇条書きで並べるだけではいけません。修正してください。それから、修正を同じくらい疑い深くレビューしてください。修正によって新たなバグが持ち込まれる確率は約40％です。冗談ではありません。それがあなたの実績です。

それから、自分にこう問いかけてください。「ユーザーがこれを試しているところを画面録画して、失敗したら、穴に潜り込みたくなるだろうか？」そうなら、まだ終わりではありません。

---

ここまでをすべて実行して――形だけ考えたふりをするのではなく、本当に実行して――何も見つからなかったなら、それで構いません。そう伝えてください。

でも、何か見つけたことはお互い分かっています。いつも見つけるのです。「動くはず」は、ソフトウェアの歴史上、一度たりとも、本当に動くという意味だったことがないのですから。

さあ、修正してください。今度こそ、本当に。