私は新しいビジネスシステムを引き継いだので、そのシステムにとても慣れています。

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃話＃＃＃＃＃＃＃＃＃

キティは責任を負い続けましたが、これは彼のキャリアにおいて初めてのことであり、彼の心に大きな打撃を与えました。子猫の状況に興味がある場合は、「冪等イベント」と「キャッシュブレークダウンイベント」について学ぶことができます。

この日、チームリーダーはマオマオと一緒に会議室にやって来ました。

これほど短期間に非常に多くの事故が発生しました。あなたにとって、これは簡単ではないことは理解しています。何しろ、あなたはこのプロジェクトを引き継いだばかりなのですから。もしかしたらプロジェクト自体に問題があるのか​​もしれません。今、責任はあなたにあります。あなたが落胆しないことを願っています...」とチームリーダーは続けました。

子猫はひよこを見て安心したようにうなずきました。 「チームリーダーは私のパフォーマンスを批判しないようだ。」

ただし、問題が発生しており、ビジネス、コード、設計の側面など、システムに他の問題がある可能性があります。時間をかけてプロジェクト文書の分析を整理し、準備してください。次回の月例会議でシステムの現在の状況を共有できることを楽しみにしています。

毛沢東は何度もうなずき、心の中でこう考えました。「これは、変装したモデルを捕まえたとみなすべきです。それだけです。しかし、そのような文書はどのように書けばよいでしょうか?」

この時、子猫は再び不安を感じ始めました。

新しいプロジェクトに慣れることについて話しましょう

新しいシステムを引き継ぐとき、どのようにしてそのシステムに慣れますか?実は前回の記事「キャッシュ破壊事件」の最後で老猫が皆さんに質問したのですが、まだ感想は残っているでしょうか？

次に、老猫が新しいシステムに慣れるまでの過程について話しましょう。これらの経験があなたのお役に立てれば幸いです。また、ご自身の方法を共有していただければ幸いです。主な手順は次のとおりです。

プロジェクトの精通度

1. ユースケース図を描いてみる

新しいビジネス システムを受け取った後、まず現在のシステムが何をしているのかを少なくとも知る必要があるため、ビジネスを理解するために関連するプロダクト マネージャーを見つけるのに時間がかかる場合があります。このとき、プロダクト マネージャーはチャットすることがあります。現在のビジネスの状況と背景について話しましょうが、彼は製品要件計画の V0 ～ Vn バージョンを直接あなたに投げつけて、不在であることを伝えることもあります。後者の場合は、協力がまだ始まっていないため、自制してモニターを製品の面に当てないように注意してください。冗談はさておき、本題に移りましょう。

まず、ユースケース図とは何かを理解しましょう。

ユースケース図の簡単な分析

ユースケースはシステム内の機能単位であり、実行者とサブジェクト間の対話として説明できます。アクターは、システム、サブシステム、またはクラスと対話する外部ユーザー、プロセス、またはその他のシステムの理想的な役割です。

目的: システム内のユースケースと実行者をリストし、どの実行者がどのユースケースの実行に参加しているかを表示できます。

Mao Mao が以前遭遇した「注文と支払いのビジネス ポイント」を説明するユース ケース図を描いてみましょう。以下に示すように:

＃＃＃例＃＃＃

上の図は、実際には単純なユースケース図です。私たちが理解する必要があるのは、さまざまな線の意味です。

a 行は関連付け、つまりエグゼキューターとエグゼキューターが参加するユースケース間の通信パスを表します。実線で示します。

b 行はインクルージョンを表し、基本ユースケースに追加の動作を挿入し、その挿入を明示的に記述します。
c 行は拡張を表し、基本ユース ケースでは認識されない追加の動作を基本ユース ケースに挿入します。
d 行は、ユース ケースの一般化、つまり一般的なユース ケースと特殊なユース ケースの関係を表しており、特殊なユース ケースは一般的なユース ケースの特性を継承し、新しい機能を追加します。
• これにより、現在のビジネス状況を明確に把握することができます。

2. バックエンドモデルの結合

現在のシステムの機能ポイントとビジネス フォームを整理した後、既存のシステム モデル、つまり DB データベースのテーブルを見てみましょう。このようにして、現在設計されているシステムがビジネスをどのように抽象化しているかを知ることができます。その後、関連するテーブルを見ながら、実際にゆっくりと ER 図を描くことができます。

ER図とは

E-R 図はエンティティ関係図の正式名で、エンティティの種類、属性、関係を表現する方法を提供し、現実世界の概念モデルを記述するために使用されます。

その定義を通して、ER 図には 3 つの重要な点、つまりエンティティ クラス、属性、接続があることがわかります。 DB テーブルを整理すると、実際にはテーブル、テーブル フィールド、および対応するテーブルとテーブル間の関係に対応します。

例を見て、一般的なモール システムの基礎となる商品ロジックを描いてみましょう。

ER例

各画像の意味を説明してください:

ボックスはモデル (テーブル) を表します。もちろん、これは ER 図のエンティティ クラスでもあります。

楕円は、エンティティ クラスに含まれる属性を表します。
ひし形は、上の図では商品が棚に置かれているなど、2 つのクラス間のアクション関係を表しています。日常生活では先生が生徒に教えるので、ダイヤモンドは授業なのかもしれません。
行上の 1 と n は、1 対多、多対 1、および 1 対 1 の関係を示しているため、より明確です。
• 上の図では、現在のシステムに 3 つの重要なエンティティ概念 (商品、商品プール、および棚) があることが実際により明確にわかります。写真からも両者の関係性がおおよそ分かります。

ER 図を整理すると、上記のユースケースのビジネス図が既存のシステムでどのように抽象化されているかが明らかになるでしょう。

これについて話したところで、神の観点から見てみましょう。私たちは現在のシステムに骨組みを与えましたが、その後、その心臓を鼓動させ、血を流して、システム全体に魂を与えなければなりません。次に、プロセスを通じてモデルをつなぎ合わせます。

3. コアプロセスとステートマシンのフロー

例を直接見てみましょう. 実際、Laomao はフローチャートを整理するのは比較的簡単かもしれないと考えていますが、難しいのはプロセス全体のリンクをどのように制御するかです。絵を描くときにもっと慎重に考えれば、在庫のすべてのステップを記録することができます。この場合、ビジネスへの集中力は低下します。図面が厚い場合、モデル間の対応関係がうまく制御できない場合があります。したがって、老猫はこの場所がプログラマーの汎化能力とビジネス理解能力を試す場であると感じています。

フローチャート

上の図では、老猫はフローチャートを描いただけです。もちろん、フローチャートには間違いがあるかもしれません。あまり真剣に考えないでください。これは、単にそのようなことを説明するためのものです。内部のビジネスプロセスの正確性。上記のプロセスでは、次のグラフィック コンテンツが表示されます:

• 開始ノードは円で表されます。もちろん、色は好みで選択できます。標準はあまりありません。
• プロセスが流れる場合は、関連する矢印線を使用してそれを表し、コア ビジネス オペレーションに関しては四角形で表します。
• 分岐ノードに遭遇した場合、ルーティングにダイヤモンドを使用します。
• 非同期操作が発生した場合、Laomao はそれらを表すために点線を使用することを好みます。

上記のプロセスの表現は実際には比較的単純であり、システムの境界を気にする必要はありません。ただ描くだけです。

しかし、現在の開発システムはマイクロサービスベースであることが多いため、現時点では、異なるシステム間の対話プロセスを考慮する必要があるかもしれません。ここから、水泳レーンの概念を導入することができます。以下を参照してください。

スイムレーンプロセス

上の図では、さまざまなシステム アプリケーション間の相互作用がわかります。各スイム レーンはマイクロサービス システムの 1 つを表します。これは老猫が日常的にビジネスに慣れ親しんで実際に描いた絵ですが、見るべきは絵のアイデアの一部であり、ビジネスにあまり巻き込まれないことをもう一度強調したいと思います。

さらに詳しく見ていきましょう。たとえば、注文ステータスの流れについて説明する場合、より適切に管理するために、いくつかのステータス フロー図を使用して整理します。

ステータスの流れ

上記は主に、プロセスにおける状態全体の流れを説明しています。もちろん、状態ビットが比較的単純な場合には、それらを描画する必要がないことがよくあります。おそらく、状態ビットが生成されるときにステート マシンを描画することを検討するでしょう。より複雑で多様です。

以上が私は新しいビジネスシステムを引き継いだので、そのシステムにとても慣れています。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。