エンジニアやってて失敗したこととその教訓を記します。
私について
- IT企業新卒入社4年目
- ウェブサービスの開発エンジニア
- 大学院でNLPを研究
- Python歴6年、Java歴4年
Singleton
とあるプロジェクトでスレッドセーフでないものをリリースしてしまいました。リクエストAの処理中、それとは別のリクエストBに対するAPIのレスポンスが変数に格納されていることに気づきました。その後理由はシングルトンなデザインパターンになっていなかったからだと判明しました。単に機能要件を満たすだけではなく、大規模アプリケーションにおいては、エンジニアとして常にスレッドセーフであることを意識しながらコーディングするきっかけになりました。
NullPointerException
これはどのエンジニアも一度は経験することだと思います。とあるプロジェクトのリリース後、NullPointerException
が頻発していることに気づきました。理由はAPIのレスポンスがnullであったのにも関わらず値をとりにいこうとしたからです。本来、APIがnullを返すような仕様はないと思っていましたが、とあるまれな条件を満たすとAPIのレスポンスがnullになる仕様であったためです。これは仕様管理者もリリース前には気づきませんでした。このようなケースは今後もあるはずなので、保険も兼ねて、APIのレスポンスがどのようなAPIレスポンスが返ってきても問題ないよう、エンジニアとしてnull
チェックは必ず入れましょう。
依頼主との擦り合わせ
とあるプロジェクトでリダイレクト設定の依頼がありました。リクエストURLがhttps://xxxx/yyyy/
の場合どこどこへリダイレクトさせたいという内容でした。私は本番環境のApacheに変更を加え、https://xxxx/yyyy/
というリクエストが来た場合、指定された場所へリダイレクトすることを無事確認しました。それから3日後のこと、依頼主から連絡がありました。内容はhttps://xxxx/yyyy/
は確かにリダイレクトされるが、https://xxxx/yyyy/zzzz
のようなケースはリダイレクトさせないでほしいとのことでした。私はてっきりhttps://xxxx/yyyy/zzzz
も要件に入っているものだと勘違いしておりました。要件の詳細な定義が抜けていました。事前に考えられるだけパターンを用意して、このケースはリダイレクトさせる・させないといった認識の擦り合わせをするべきでした。教訓としては、依頼主と仕様の擦り合わせをする際に、依頼主側のプロジェクト背景まで聞いておくとこのようなミスを防げると思いました。