経営陣は最近、あなたは多くの時間がタスクを完了するためにもかかわらず、各タスクの完了を確認するために多くの時間を費やし、中小規模チーム、別のビューを持っていた、開発プロセスで扱わない多くの詳細がありますが、それかもしれませんそこにバグの存在。例えば、数が何にアクセスするためのフロントエンドインターフェースを配置し、実際の状況が完了した後に私がチェックしに行って、いくつかの場所で何の契約が存在しないことが判明し、このような入力パラメータが時間のクラッシュに、別のインターフェイスジャンプからいくつかのインターフェイスをチェックしないように。
したがって：
開発と管理の1.完了は、各タスクが実装をチェックしようとして終了した後、各タスクを制御する必要があります。
2.開発管理は、各メンバーが開発中で実施されるよう、細部に注意を払うように開発者を思い出させます。
バックエンドの開発ニーズに共通のメッセージング機能を経験し、話題に戻ります：
各ユーザーは、赤い点が消えクラシファイド掲示板を表示し、[移動]をクリックします（ドロップダウンリストにはショールームを更新する際に、対応する分類の赤い点があるでしょう）リマインダ1.システムの発表を受け取ることができます。
2.ユーザーは、そのカテゴリにお知らせリストを削除すると、空になった後、以前の発表が削除することはできません再び引き、分類（空）の発表を削除することができます。
実際には、問題は、それが単にフィールドを読み込むことでは十分ではありませんか、ユーザーをマークするために、発表後のカテゴリを表示するには、ユーザーは、この分類の下に注意事項を読んでいるということですが、また、二番目のルール制限。
だから、あなたが分類され、最終的な読み取りを行うために時間を使って考える場合には、各ポストのリリースタイムを識別し、発表は分類の一部であり、分類はまた、最新のリリース日です。最後に、時間の発表を分類読み出し時間を使用して、最後の三つのパラメータは、需要のルールを行うことができます公開された分類。焦点は、最後の投稿時刻フィールドが更新されますショールームテーブルを対応発表、あるとき。
そして、最終的に削除し、分類のアイデンティティをする時間を増やし、数2のルール、このカテゴリの下での発表の時よりも少ないが引き戻されません。
データベースのテーブルの設計をまとめるには：
発表の分類：分類（ID、名前、last_publish_time）
公告表：通知（ID、タイトル、内容、publish_time、classify_id）
読み込みレコードテーブル：readStatus（USER_ID、classify_id、last_read_time、last_delete_time）
プロセス：
お知らせ：お知らせ挿入テーブル - >アップデートのショールームテーブル公開された最後の分類に対応
分類リストを引っ張る：最後の読み取りレコードテーブルに従って、時間を読んで、赤い点あればカテゴリが表示されるかどうかを判断します
下の分類の発表を引い：最後の時間を削除するに応じながら最終更新読み取り時間は、記録シートを読んで、削除の時間よりも長いスクリーニングを発表しました。
削除のカテゴリー（例）下の通知：直接のアップデートは、レコード形式を読んで最後の時間を削除