(CJP) 始める前に…
一部の読者から連絡があり、この投稿で説明した技術的な問題の解決策について話してくれました。 この投稿は、バグの対処方法や防止方法に関するものではないことを明確にしたいと思います。 気分が悪く、ストレスの多い時期に私がどのように感じたかについて、感情について話し、内省して改善する方法について語っています. 以上で、この投稿に価値があることを願っています。
その夜、私は不安とストレスで家に帰りました。 帰りの電車の中で涙をこらえなければならなかったことを認めても恥ずかしくない。 それは悲しみの涙ではなく、恐怖の涙でした。
マネージャーが私のところに来て、クライアントの 1 人が、連絡フォームに記入した後に電話がかかってくると思っていたのに電話がかかってこなかったと言って、誰かから電話がかかってきたと苦情を言いました。 彼らは私にそれを調べるように頼んだ。
ほら、このクライアントは特定のサービスを人々に販売しました。彼らはウェブサイトのフォームに記入して見積もりを求めることができました。 居住地によっては、そのフォームに記入した後、最寄りのオフィスから電話がかかってきます。 これは非常に複雑なフォームではありませんでした。3 つのステップがあり、人々のプロジェクト、チェック ボックス、ラジオ ボタン、ドロップダウンに関する情報を尋ねました。 送信されたすべてのリクエストは「リード」(潜在的なクライアント) と呼ばれるため、内部的に「リード フォーム」という名前を付けました。
見込み客の 1 人がクライアントのオフィスに電話をかけてきて、電話がまったくかかってこないことを訴えたとき、オフィス マネージャーは賢く、見込み客のメール アドレスを尋ねてくれたので、仕事が楽になりました。 私がしなければならなかったのは、データベースにアクセスし、そのリードの電子メール アドレスのフォーム送信を見つけて、何が問題だったかを調べることだけでした。
ジュニア開発者として、私が最初に考えたのは、外部の問題を探すことでした。 見込み客がフォームを送信するたびに、すべての情報が記載された電子メールが対応するオフィスに送信されます。私の推測では、その電子メールが何らかの理由でスパムになってしまったか、またはメール サービスに問題があった可能性があります。
ただし、その電子メール アドレスのエントリがデータベースに見つかりませんでした。
「住所が間違っているのだろう」と思ったのを覚えています。 フォームが送信されたときに最初に行われるのは、その内容がデータベースに保存されることです。 そうすれば、オフィスへの郵送で問題が発生した場合に備えて、常にデータのコピーを保持できます。 そこで私はマネージャーにクライアントに連絡するように言い、彼らが私にくれた電子メールアドレスはおそらく間違っていると伝え、私の一日を続けました.
数分後、上司から、メールアドレスは絶対に正しいと言われた。
わかりました、それはフォームが送信されなかったということですか? 私は大声でため息をつきます。 チーム マーケティングは、A/B テスト ライブラリや Mouseflow などのツールを使用してユーザーの画面を記録し、人々が Web サイトとどのようにやり取りしているかを分析できるようにすることに非常に熱心でした。 これらのツールの 1 つがフォームの送信を台無しにしたとしても、私は驚かないでしょう。
そこで、私は彼らのマーケティング チームに電話して、このリードについて何か知っているか尋ねました。 彼らはそれを調べると私に言いました、そして私は再び、私の一日を続けました. 1時間が経ち、「私の問題ではない」という考え方のおかげで、私はすでにすべてのことを忘れていました. 突然マネージャーが戻ってきました。チームのマーケティング担当者が私と話をしたいと言い、彼は私に電話を渡しました。
彼らは、その特定のリードの画面記録を見つけました。 すべてのセッションの約 50% が記録されていたので、それを見つけることができたのはかなり幸運でした。 見込み客が実際にフォームを送信したことがわかりました。今すぐ録音を送ってくれます。
これは私がそれを考慮し始めるポイントです そうかもしれない 結局のところ私の問題ですが、結論に飛びつくのはやめましょう。 私は録画を見ましたが、確かにそうです。リードはステップ 1、ステップ 2、ステップ 3 に記入し、それを送信しますが、それは適切なページではありません。 フォームを送信すると、「ありがとうございました」ページが表示されます。 代わりに、Web サイトのヘッダーとフッターを含むページが表示されますが、コンテンツはありません。
それは良いことではありません。
テスト環境に入り、まったく同じデータでフォームを送信します。 私は同じ空白のページに行き着き、確かに私の提出物はデータベースに保存されていません. このページですか？ 私は前にそれを見たことがありません。 だから私はログを見ます。 エラー： null passed instead of boolean. それは深いところにある型エラーです 私の コード。
先に進む前に、エラー、なぜそれが起こったのか、なぜ誰もそれを知らなかったのかをお話ししましょう。
したがって、このフォームには、チェック ボックスを含む多数の入力フィールドがありました。 見込み顧客のリクエストが送信されるたびに、データをキャプチャし、データベースに保存する準備をしました。 それは次のように見えました：
$formSubmission = new FormSubmission();
$formSubmission->name = $form->get(‘name’);
$formSubmission->email = $form->get(‘email’);
$entityManager->save($formSubmission);
バグは単純に聞こえるかもしれませんが、単純なタイプミスでした:
$formSubmission->more_feedback_required =
$form->get(‘more_feedback_requierd’);
あなたは見つけることができますか requierd 電話するとき $form->get()?
結局のところ、フォーム ライブラリ (社内フレームワーク用に作成されたもの) は、不明なプロパティを取得しようとしてもエラーを発生せず、単純に返されます。 null.
ただし、データベースはブール値を予期していたため、エラーがスローされました。
誰もそれを知らなかったわけではありませんが、これはそれほど大きな問題ではありません。 バグの 2 番目の部分は空のページでした。このページは、エラーが発生するたびに nginx から直接提供されていました。訪問者がエラー ページに悩まされることは望ましくありませんでした。 同僚の 1 人が数か月前にセットアップしたことが判明しましたが、私はそのことを知りませんでした。 空のページを見た見込み客は、おそらくフォームが問題なく送信されたと思い、代わりに「ありがとうございました」ページがあるべきだとは知りませんでした。
次に、テスト中にエラーが発生することはありませんでした。これは、エラーのあるコードが特定のケースでのみ実行され、誰もそれらをテストすることを考えていなかったためです。 フォーム自体はユニット テストされましたが、すべてのエッジ ケースがテストされたわけではありません。
最後に、本番環境でのエラーが自動的に通知されることはありませんでした。つまり、クライアントが苦情を言うまで、誰もエラーについて知りませんでした。 当時、同社は本番環境でエラーの監視を行っていませんでした。
タイプミス（最初に書いたもの）の修正を展開し、マネージャーに問題について話し、修正されたことを伝えました。 次に、彼は何人の人が影響を受けたかを私に尋ねます。 私は彼にこれを調べるように言います。 私は自分のデスクに戻り、このバグがいつコミットされ、本番環境にデプロイされたかを確認します。 一ヶ月前。
この時点から、気分が悪くなり始めたのを覚えています。
ログ ファイルを確認し、エラーをスキャンします。 一瞬ビックリです。 ほんの数個のエラーではありません。 数百です。 過去 1 か月で失った数百のリード。 少し揺れ始めました。 数分後、私は上司に報告しました。 私は再びバグ自体を説明し、なぜそれが 1 か月間検出されなかったのかを説明し、最終的に彼に具体的な数字を伝えました。 私たちにできることは何もありませんでした。それらのリードは失われました。
# 余波
次の日は、おそらく今日までの私のキャリアの中で最もストレスの多いものでした. 誰も私を直接責めなかったことに感謝しています。私たち全員が、これはチームの責任であり、私自身の責任ではないことに同意しました。 それでも、タイプミスを書いたのは私であり、1 か月前にフォームへの変更をテストして展開する任務を負ったのは私でした。
正直に言うと、上司や同僚は理解してくれていましたが、この罪悪感に対処するのに苦労しました。
もちろん、他の人に指摘することもできます。風変わりなフォーム検証を備えた独自のフレームワークを使用するべきではありませんでした。 Devops には何らかのエラー追跡機能がインストールされているはずです。 空のエラー ページがより明確になるはずです。 数日後、これらすべての考えを考えたことを認めます。しばらくの間、何人かの同僚に対して怒りさえ感じました。 しかし、怒りは私をどこにも連れて行かないことを学びました。 私はどのように見て時間を費やしたほうがよい 私 他の人に指を向けるのではなく、これらすべてから学ぶことができました。
それで、数週間の処理の後、私にはトラウマのように感じました。 違うやり方で何ができたのかを考える勇気を見つけました。 このことから私が学べたこと。
まず、同僚にレビューを依頼します。 私が後輩か先輩かは関係ありません。 私のコードの新鮮な外観は常に価値があります。 ほとんどの人は自分自身が忙しく、具体的に頼まない限り助けてくれないことを学びました. 今日まで、よく同僚に PR のレビューを依頼しています。 経験年数が長くなったとしても、同僚の意見を高く評価しています。 これをどれだけ長くやってきたとしても、私はまだ間違いを犯します。
次へ: 知らないツールや信頼できないツールは使用しません。 カスタムの社内フレームワークの限界に出くわしたのはこれが初めてではありません。 大規模なオープン ソース コミュニティによってサポートされているツールを使用する方がよいことを学びました。 その特定のプロジェクトでどのフレームワークを使用するかは私の決定ではありませんでしたが、それは私の次の仕事の要件でした.本番環境のクライアントプロジェクトに関しては、コミュニティがサポートするよく知られたフレームワークのみを使用したい.
3 番目: 自分でもっとよくテストする必要があります。チェックボックスが単なるチェックボックスであると想定するべきではありません。 私が書くコードのすべての行に対して懐疑的であるべきです。 この出来事は、私が強く型付けされたシステムをますます好きになった理由の 1 つです。 私は、スマートになろうとしてあちこちで型をジャグリングしようとする言語は望んでいません。 起こるべきではない何かが起こったときに激しくクラッシュする言語が欲しいのです。型システムが強力であればあるほど良いのです。
次へ: 私はより防御的にコーディングする傾向があります。 私は常に自問自答しています: null 値は可能ですか? 予想外のことが起こる可能性はありますか？ 正常に動作すると仮定するよりも、余分なチェックを追加することを好みます。
そして最後に、まず他人を責めないことを学びました。 問題が別の場所で発生したと考えるのは、多くの若手開発者の特徴だと思います。 それは学ぶべき重要で謙虚な教訓であり、私は最近、外部の当事者を非難する際により慎重になる傾向があります.
このブログ投稿を書いているのは奇妙です。 これが起こったとき、私は若い開発者でした。これは、私のプログラミング キャリアに永続的な影響を与えたと思います。 また、これについては十分に話し合っていないと思います。 クライアントがどれほど怒っているか、私が働いていた会社にどのような影響があるかを考えながら、私は夜中に目を覚ましました。 私の感情のほとんどは誇張されていたことに気づきましたが、それでもそこにありました。 それらをオフにすることはできませんでした。 私は恐怖と恥ずかしさを感じ、それについて話す人はほとんどいませんでした.
私たちは成功事例について書きますが、過ちについてはどうでしょうか? この種の経験が私たちのメンタルヘルスに与える影響についてはどうでしょうか? ソフトウェア業界にいる私たちの多くは内向的であるか、自分の最も深い感情について話すことができないと感じています。
代わりに、お互いに注意を払いましょう。
読んでくれてありがとう！ この投稿は、開発者としての私自身および個人的な経験について書いている「開発日記」シリーズの一部です。 もう少し読みたいですか？
このブログの最新情報を知りたい場合は、私をフォローしてください。
Twitter上で または私のニュースレターを購読してください：