事業前提
コレクションに5つのデータがあると仮定します。データで表されるオブジェクトのフィールドの1つはレビュー担当者IDです。バックグラウンドは、レビュー担当者IDに基づいてレビュー担当者の関連情報を取得する必要があります。最初に、フロントエンドは完全な更新メソッドを使用して監査済みを返しますデータ、次にコレクションの最初のデータのレビューアIDを取得して判断を下し、値を設定します。そのため、レビューアIDがある場合、それはレビューアが存在することを意味し、レビューアの情報を検索できます。存在しない場合は、設定をスキップします値のロジック。ただし、権限を追加した後は、お客様は5つのデータに関連する権限のみを確認できます。現時点では、フロントエンドは完全な更新を部分的な更新に変更します。つまり、お客様が確認する権限を持つデータのみが返されます。これにより問題が発生します。お客様が2番目、3番目、4番目のデータを承認する権限を持っている可能性があります。フロントエンドは、2番目、3番目、4番目のデータのレビュー結果のみをバックエンドに更新のために返します。このとき、最初のデータは返されないため、更新されない場合、最初のデータのレビューアIDは引き続きnullですが、実際にはレビューは合格です。2番目、3番目、4番目のデータは実際にレビューアIDを持っているため、元のアイデアに戻りますこの時点で、コレクションの最初のデータのレビューアIDを取得してレビューアの関連情報を設定するのは間違ったロジックです。これはまったくnullであるため、値を設定するロジックはスキップされ、フロントエンドで最後に表示されます。その結果、承認は通過しましたが、レビュー担当者の情報はすべて空です。
解決：
実際、これはあなた自身の論理的思考を発達させる問題です。フロントエンドでロジックを変更した後、時間内に私のロジックに問題があるとは思いませんでした。あるいは、セルフテストが失敗したとは言えません。どちらかがうまくいっていれば、上記は避けたほうがいいでしょう。問題。最初は、逆順メソッドを使用して、従業員IDがnullではないデータを先頭にランク付けして、最初のデータが確認されている間は値が確実に存在するようにしましたが、ロジックの問題により、リストの順序が変更されました。 、監査時にマスターテーブルがあり、監査データテーブルは1対多の関係であり、監査後にマスターテーブルが更新されるため、これは最終的には最適な方法ではありません。したがって、ロジックをスレーブマスターテーブルに変更します。監査が完了している限り、メインテーブルには従業員IDデータが含まれている必要があるため、従業員IDだけを取ってください。結局のところ、ビジネスと組み合わせてこの問題に対処する必要があるため、私は実際には普遍的な解決策を提供しませんでした。技術的な思考でそれを本当に解決することはできません。私が遭遇した落とし穴を主に共有したいと思います。同様のシナリオが発生した場合は、問題を回避してトラブルシューティングすることができます。