ユーザーと一度も話す前に14,000行のコードを書いてしまった。そこから学んだこと。

著者は当初、プルリクエスト内のPythonコード変更に対して敵対的テストを実行するように設計されたGitHubアプリ「LogoMesh」を開発しました。このアプリは、敵対的入力を生成し、強化されたDockerサンドボックスでテストを実行することでバグを特定することを目的としていました。アプリの高度な機能と技術的な洗練にもかかわらず、重大な問題に直面しました。実際のプルリクエストでのアプリの沈黙率は高く、報告された多くの発見は無関係なアーティファクトでした。決定的に、アプリのパフォーマンスは遅く、高いレイテンシがあり、望ましい時間枠を超えていました。これにより、著者は根本的な欠陥に気づきました。それは、初期の仮定を検証せずに構築したことです。著者は、真の課題が将来のバグを防ぐことではなく、既存のプロダクションバグに対処することであると認識した後、焦点を移しました。この発見は、よりシンプルな解決策につながりました。Sentry URLに基づいて失敗するpytestを生成し、クラッシュを再現するツールです。このツールは、Dockerサンドボックスなど、LogoMeshのために開発されたコアテクノロジーを活用していますが、目的は異なります。現在、著者は、プロダクションバグを修正する前に再現テストを作成することが普遍的な問題であるかどうかを評価しています。適切なユーザー入力なしに別のツールを構築するのではなく、真の課題を解決していることを確認するために検証を求めています。著者は、自分が本当の問題を解決しているのか、それとも単に個人的なワークフローの非効率性に対処しているだけなのか疑問に思っています。