ソフトウェア工学の分野、進化モデルの人気のウォーターフォールモデルや他のモデル参照ボーエンで：https://www.cnblogs.com/kzang/archive/2012/07/06/2578835.html、私たちは、プロジェクトチームを使用する必要があります高めることですボリュームモデルが、私はプロジェクトチームを入力し、一般的な特徴が完了し、バージョンはいくつかのマイナーな変更では、それは小さなステップの繰り返しということができるされていますが、新しいプログラムの設計とオリジナルのデザインは、常に競合になり、それはおそらくですそれは、プログラムの設計者は、細部のよく知っているため、問題はないので、公開でのプログラミング過程で、それらのほとんどは、ソフトウェアのテストで発見されています。
ここで私は、二つのうちの一つは、私は互換性の問題が発生したことを言います。
1.プロジェクトチームはなく、ベースのマルチユーザーと見なされるデフォルトの日付を、服用する前に、commitIdは、ファイルのバージョンを取得し使用することを決めました。しかし、実際の開発では、我々は、ユーザが入場文書の前に存在してもよいことは、そこに複数のアーカイブ行動すること、そして私たちはcommitId得るが、これまでにとられていない入場文書で、その結果、最新の状態にあることが保証、ないかもしれませんが、見つかったビジネスのもフォローアップそれは間違っています。これは、プログラムは、最新に直接アクセスcommitIdされていない前に見つかったテスターです。これはバグを除外することであるが、それは新しいバグを紹介します。
業務プロセスフロー2.ユーザ操作が失敗した場合、プログラムは、レコードを削除するために失敗します。しかし、それは非同期変わるとき、他のクエリAPIインターフェイスで、その結果、失敗の記録を保持している、無効なデータの多くは、パフォーマンスに影響を与え、これは無効なデータの問題が送られるべきです。今、無効なデータを削除した後、パフォーマンスが改善されました。実際には、これは開発で見つかった問題ではないが、テストでは、問題を発見しました。これは、機能に問題がないので、開発は、これらの問題を意識することはありませんです。