要求分析入門 アーキテクチャを語る (5) アーキテクトの成長軌跡

私は数年間研究開発にも従事しており、この期間中に C# モノマーの Java マイクロサービスへの変換や Python モノマーの Java マイクロサービスへの変換など、いくつかのアーキテクチャ設計作業を行ってきました。私自身の経験の観点からこれらの
知識のポイントを説明し、同時に資格のあるソフトウェア アーキテクトに成長する方法について説明します。参考までに、私との議論を歓迎します。

1. 建築家の定義

アーキテクトとはその名の通り、企業・チーム内でシステム構築の仕事に携わる人を指します。
まず、この記事で言う建築家とは、立場ではなく役割、つまり建築の仕事に従事する人であることを明確にしておく必要があります。

• 各企業、さらには企業内の異なるチームによって、アーキテクトに対する認識が異なり、アーキテクトの定義や責任も異なります。
• どのチームにも多かれ少なかれ、チームのメイン プログラムや上級開発者など、アーキテクチャの仕事に携わる人々がいます。

つまり、あなたの立場が建築家であり、建築家の水準に達しているという意味ではなく、同様に、あなたの立場は建築家ではないが、このチームが認める建築家である可能性もあります。
アーキテクトとして注意すべき点：
アーキテクトは既存の開発環境、プロジェクトの現状、会社のリソース投資などから切り離されることはできず、空中の城に座ってチームを指揮して戦うことはできません。 。

建築家の分類

さまざまな分野の細分化に従って、建築家はいくつかの細分化定義も持っています。一般的には次のとおりです。

• ソフトウェア アーキテクト: ソフトウェア システムの全体的なアーキテクチャの設計と計画を担当し、要件分析、テクノロジの選択、ドメイン分割、アプリケーションの展開などをカバーします。
• データ アーキテクト: データ ウェアハウス、データ収集、ガバナンスなどを含むデータ システムの設計と計画を担当します。
• ネットワーク アーキテクト: インターネット アクセス、ルーティングとスイッチング、VPN とネットワーク セキュリティなどを含む、システムのネットワーク全体の設計と計画を担当します。
• クラウド アーキテクト: 現在、クラウド コンピューティングが普及しており、クラウド プラットフォームの選択、コンテナ管理機能、仮想化、自動化などを含むクラウド コンピューティングの導入と計画を担当します。
• セキュリティ アーキテクト: グローバル セキュリティ ポリシー、アクセス制御、脆弱性管理、監査ポリシーなどを含む、ソフトウェア システムのセキュリティ アーキテクチャ計画を担当します。
• フロントエンド アーキテクト: 一般にブラウザ アプリケーション アーキテクトを指し、フロントエンド フレームワーク、テクノロジ スタック、ブラウザ間の互換性と統合機能のパッケージ化、パフォーマンスの最適化など、フロントエンド アプリケーションの全体的なアーキテクチャ設計を担当します。 ;
• モバイル アプリケーション アーキテクト: 一般に、モバイル セキュリティ、テクノロジー スタック、クロスプラットフォーム互換性、テスト プログラム設計、パフォーマンスの最適化など、モバイル アプリケーションの全体的なアーキテクチャ設計を担当する Android/iOS アプリケーション アーキテクトを指します。
• バックエンド アーキテクト: データベース設計、API 設計、パフォーマンスの最適化、データ セキュリティなど、アプリケーションのバックエンド アーキテクチャ設計を主に担当します。

上記の下位区分は必ずしも包括的ではなく、次のような多くの分野の境界は実際には十分に明確ではありません。

• ソフトウェア アーキテクトは通常、ソフトウェア システム全体をカバーし、さまざまな分野について一定の理解を持ち、特定の焦点 (主にバックエンド) を持っている必要があります。
• フロントエンド アーキテクトとバックエンド アーキテクトの両方が API を標準化し、レビューする必要があります。
• たとえば、ソフトウェア アーキテクトとデータ アーキテクトは、データ セキュリティとシステム間メッセージ送信プロトコルに注意を払う必要があります。

ソフトウェアアーキテクトの責任

• 1. ビジネス要件の包括的な理解
  アーキテクトとして最も重要なことは、ビジネスに熟達することであり、さらにはドメインの専門家になることが求められる シリーズの最初の講義で、「問題を解決することよりも、問題を見つけることが重要である
  」と述べました。ビジネスを理解していなければ、設計されたアーキテクチャは役に立ちません。

• 2. 問題を単純化および抽象化する能力
  これは、アーキテクトが高品質のソフトウェア システムを設計および開発するための重要な能力であり、チームがビジネス要件をよりよく理解し、複雑な環境で設計および開発するのに役立ちます。
  ユーザー ログイン システムを例に挙げます。

  • ログインの問題は、ユーザーが送信したログイン タイプを受信し、ユーザーが送信した資格情報を受信し、ユーザーの資格情報が有効かどうかを確認するというように単純化できます。
  • これはインターフェイスとして抽象化され、次の 3 つのメソッドを提供します。
    matchLoginType(HttpServletRequest request)現在のクラスによって処理されるログイン タイプが
    readCredential(HttpServletRequest request)ログイン タイプに従ってログイン資格情報を読み取るかどう
    validCredential(UserCredential info)か ログイン資格情報を検証する
  • アカウント パスワード ログイン実装、WeChat ログイン実装、LDAP ログイン実装、トークン ログイン実装などのさまざまな実装を追加します。
  • フロントエンドの表示とユーザーの対話方法に関しては、これらは比較的重要ではない詳細であるため、標準的なフロントエンドとバックエンドのインターフェイス対話ルールに同意するだけで十分です。

• 3. 限られたリソースの中で適切かつ実現可能なソリューションを提案する
  ソフトウェア/ハードウェア/人材/時間などのリソースは有限であり、アーキテクトは限られたリソースの中で最適なソリューションを模索するためにこれらの制約を承認する必要があります。例: 工期が限られている場合、建築家は実際のビジネス状況を評価し、モジュール/機能を分解し、優先設計と実装
  のニーズを満たす最小限の機能の組み合わせを選択できなければなりません。
  状況に応じて、事業への影響を最小限に抑えたスムーズな移行と人員配置能力を測定する必要があります。

• 4. ビジネス要件を満たし、システムの品質を確保するには、
  アーキテクトがビジネス要件を正しく理解し、信頼性、パフォーマンス、耐障害性など、システムに必要な非機能要件を出力し、適切な技術ソリューションを設計し、継続的に追跡する必要があります
  。品質を確保するためのプロセス。

• 5. 予測可能な期間内のスケーラビリティ
  これは一般に 2 つの側面に分けられます。

  • アーキテクトは要件を深く理解し、一定期間内の要件の変化を見積もることができる必要があります。
    たとえば、ユーザー ログイン システムは、アカウントとパスワードのログインを設計するだけでなく、WeChat スキャン コード ログイン、Google ID ログイン、ユーザーグループの特性に応じてなど。
  • アーキテクトは、コストを考慮し過剰設計を避けながら、水平方向の拡張と垂直方向の拡張を含むシステムのスケーラビリティを考慮する必要があります。
    • 水平方向の拡張: システムは、アクセス数が増加したときにノードの容量を迅速に拡張し、古いノードの負荷容量を分散できます。
    • 垂直拡張: システムの 1 つのノードで、CPU の強化、メモリの増加、ネットワーク帯域幅の増加など、十分な拡張機能を備えています。

• 6. システムのライフサイクル内での継続的な進化
  アーキテクトは、ビジネスの成長に応じてシステムを継続的に監視、評価し、反復的に改善します。
  最終的な目標は、ビジネスの成長に影響を与えることなく、システムの信頼性とスループットを継続的に向上させることです。

ソフトウェアアーキテクトの能力要件

適切なソフトウェア アーキテクトとしては、通常、次の能力が必要です。

• 1. 技術力
  アーキテクトは、まず優れた技術者であることが必要であり、サブデータベースサブテーブルを経験していないアーキテクトには本当に資格がないと言えます。
  • 上級プログラマー:
    アーキテクトは、どのようなデザイン パターン、HashMap 原則、B+ ツリーなどであっても、プログラム開発における豊富な経験を持っている必要があります。
    一部のコア システムや一般的なフレームワーク設計では、通常、アーキテクトがコードを記述してガイドする必要があります。
  • 複数の技術分野の知識:
    アーキテクトは、フロントエンド ブラウザーのレンダリング プロセス、クライアント開発テクノロジー スタック、Kafka の送受信原理、分散関連理論と一部の製品実装、コンテナーなど、さまざまな技術分野の知識を理解するのに十分な技術的幅を持っている必要があります。 K8S、負荷分散テクノロジーなどは、特定の問題に直面した場合に、適切なテクノロジーの選択、展開スキーム、および実装を提案できます。
  • 問題解決の専門家と消防士:
    建築家は豊富な問題解決の経験を持ち、通常の技術者では解決できない多くの困難で多様な疾患を解決できなければならず、
    生産事故の復旧を優先するなど、完璧な問題解決プロセスの経験を持っていなければなりません。障害位置の特定を実行する 解決すべきソリューションの完全なセット。
  • 適切な運用および保守エンジニア:
    一部の緊急または特殊な問題には、アーキテクトによるオンライン診断が必要です。オフラインで再発した場合は、対応するサービスを展開する必要があります。アーキテクトには、
    Centos などの一部の一般的なサービスの展開/運用および保守/監視の経験も必要です。 Windows、スーパーバイザ、crontab、redis、mysql、kafka など、
    さらに、一部の中小規模のチームでは、通常、フルタイムの運用保守担当者が存在せず、アーキテクトが運用保守の責任も負っています。
• 2. ビジネス分析と抽象化能力
  アーキテクトは業界知識を深く理解し、その分野の専門家となることでのみ、ユーザーのニーズをより正確かつ明確に技術要件に変換することができます
  。つまり、技術的要件をスケーラビリティに優れた抽象的かつ具体的なアーキテクチャに変換し、
  たとえばモール システムは、
  ログイン -> ショッピング カート -> 注文 -> 支払い -> 配送および
  一般的な認証サービス、注文サービスとして抽象化できます。決済サービス、在庫管理サービス、サービス間のメッセージ送信プロトコルなどを同時に抽象化でき、
  同時に製品を見ると、分類テーブル、SPU データテーブルを設計する必要があることがわかります。と SKU データ テーブルを統合し、製品の評価を独立したレビュー サービスに分離する必要があります。
  注: 6 つの設計原則はソフトウェア アーキテクチャの設計にも適用され、ドメイン境界とモジュール分割の際には、単一責任、オープンとクローズの原則、インターフェイスの分離なども考慮する必要があります。
• 3. マネジメント能力
  この点は比較的大きなポイントですが、一般的にアーキテクトには、高いコミュニケーション力と理解力、プロジェクトの進捗管理とリソース配分能力、チームのコラボレーション能力と雰囲気を動機づける能力などのチームマネジメント能力も求められますが、最も重要なのはコミュニケーションとコミュニケーション能力です
  。理解力、他の人が提起した質問を理解できなければ、自分の考えを明確に表現することができず、問題を明確に見つけて定義することさえできず、ましてやフォローアップアクションについて話すことさえできません。
  もう一つのポイントは率直さだと思います。チームメンバーは毎日コミュニケーションをとります。率直さが足りないと、メンバーはそれをすぐに察知し、嫌悪感を抱き、不誠実になります。多くの問題が表面化せず、最終的にプロジェクトにつながる可能性があります。」失敗。
• 4. 学習能力
  アーキテクトは、比較的優れた学習能力と適応力、そして強い先見性を備えている必要があり、絶えず変化するテクノロジーと業界の発展トレンドを理解し、遅れないようにするために、さまざまなオンラインおよびオフラインのトレーニングや交流に頻繁に参加する必要があります。
  同時に、アーキテクトは、技術経験の要約、技術仕様の照合と出力、運用および保守の運用手順書の作成、トレーニング文書の出力など、優れた要約能力と理解能力も備えている必要があります。

これらの能力は基本的に継続的な学習と訓練を必要とし、例えば長期的な需要分析、ドメイン境界の分割、類似プロジェクト設計との比較を意味する抽象化能力など、自身の設計の欠点を見つけて学習と再構築を実行します。
テクノロジーがすべてではないことを覚えておく必要があります。多くのシナリオは、複雑な技術的ソリューションではなく、需要の最適化によって解決できます。記事の後半でいくつかの例を示します。

これは Geek Time Architect のスキル マップです。参照できます:
この画像は常に CSDN によって画像の違反として報告されます。自分で検索できます:
Geek Time Architect のスキル マップ

https://roadmap.sh/からさらに 2 つを共有します: フロント
エンド機能ロードマップとバックエンド機能ロードマップ —

2. 育て方

写真を共有する:

上の写真は、 Wu Jun 氏の「Pattern」からのものです。よく読んでください。

• ベースライン: 習得するエンジニアリングの知識は人によって異なります。たとえば、専門家は高いベースラインを持ち、初心者は低いベースラインを持ちます。最初に行う必要があるのは、自分自身の立場を確立し、独自のベースラインを見つけ、学習を続けることです
  。ベースラインを改善します。
  民間の科学者が生涯に行った発明の多くは、そのベースラインがこの時代のベースラインよりも低く、学習する代わりに古い知識を直接使用するため、認められません。
• 限界: 物理学、環境、さらには個人の認識によって制限される、光の速度、単一マシンの最大接続数、単一マシンの最大スループットなどの達成可能な限界。改善するには、
  非効率的なトスを避けるために、この方向の限界を明確にする必要があります
• ラダー：限界までの道や方法は、知識を得たり、自分に合った方法を模索したりする必要があります。
  注: 各人の個人的な認識、さまざまなリソース、および探索方法が効果的かどうかによって制限されるため、限界に到達できる人はますます少なくなり、はしごは収束します。

要約すると、自分自身を成長させ続ける方法に近道はありません。

• 学び続けてベースラインを改善する
  多くの場合、あなたが思っているひらめきは、他の人の基本的なスキルに過ぎません。投稿者: リウ・ラン
• 練習、継続練習、導入、要約、理解
  時間がないと思わないでください。5 分間のビジネス スクールの推奨書籍には、時間管理を教える特別セクションがあります。5 分間聞いてください。

理論と実践を組み合わせると、知識には 2 種類あることがわかります:
1. 他人の教えや本で学んだことは理論です;
2. 自分自身が経験することは実践です;
理論だけが忘れられやすい; 実践だけです; あなた自身何を宣伝すればいいのか分かりません。

私の経験:
1. 自分が踏んだ穴については、ゲームを見直して問題が発生した理由と本質的な理由を理解する必要がある
2. 他の人が踏んだ穴については、自分が踏んでみるテスト環境で印象を深め、本質を探る

最後に、私が Zhihu で見た学習の問題を共有したいと思います。これは非常に興味深いものです。Zhihu
の誰かが質問しました。古代人には良い政策、中程度の政策、および低政策があったのに、なぜ多くの人は低政策を選択したのでしょうか。 ?
学習を例に挙げると、次の 3 つの戦略があります。

• 最善の策は、厳密な学習計画を立て、梁にぶら下がり、ニワトリの鳴き声とともに踊ることだが、
  明らかにそれは難しすぎて、それができる人はほとんどいない。
• 中戦略: 緩やかな学習計画、週/月に本を読む、
  この中戦略は悪くありません、多くの人がこれを選択し、時間計画も立てますが、実行プロセスは中断されやすいです、携帯電話が私にとってとても恋しいです、Douyinを見て、友達と飲みましょう、1〜2か月は続きません
• 悪い方針: ランダムな学習、思いついたときにすぐに学習する
  私を含むほとんどの人がこれを選択します、知識の断片化が非常に深刻で、忘れがちです

3. おすすめの本

技術分野

この 3 冊は本当に読むのが退屈ですが、一度読んで印象を掴み、しばらく練習して、戻ってきたときにもう一度読むことができます。

非技術分野

同時に、技術分野に焦点を当てるだけでなく、技術分野以外の知識にも注意を払う必要があります。
特に、音声シリーズである Liu Run の 5 分間のビジネス スクールを強くお勧めします。各音声は約 5 分です。ビジネス知識、製品イノベーション、自己管理、チーム管理、パフォーマンス向上などの知識を網羅しており、
Zhihu について彼のことを高く評価していない人もいますが、技術分野の私にとっては、多くの知識がほとんど啓発的です。そして当然のことながら、それは私にとっても同様です。それは私の成長と仕事に大きな助けとなったので、学ぶことを強くお勧めします。

4. 拡張情報

建築士向けの資格試験を2つ紹介します 建築の能力向上に興味のある学生は挑戦してみてはいかがでしょうか
資格の内容は比較的網羅的であり、個人の能力全体の向上につながるので、受験せずに勉強しても全然OKです試験のため、あるいは試験なしで勉強するだけでも構いません。

TOGAF認証

TOGAF は、The Open Group Architecture Framework の略称で、非営利のテクノロジー業界連合である The Open Group によって開発され、継続的に更新されています。
Open Group は、TOGAF を「エンタープライズ アーキテクチャの世界標準」と定義し、一連の方法論とベスト管理プラクティスを提供します。
TOGAF は Forbes 50 企業の 80% で使用されており、HP、IBM、Kingdee、Oracle、SAP などの主要な国際 IT 企業によって高く評価され、積極的に推進されています。中国の企業アーキテクチャの実践において、TOGAF の承認率は 50% を超えています。
TOGAF 公式紹介: https://www.opengroup.org/togaf
百度百科事典紹介: https://baike.baidu.com/item/TOGAF/9832356

TOGAF 認定のコンピテンシー モデルの概要は次のとおりです。

• 1. 一般的なスキル：リーダーシップ、チームワーク、対人コミュニケーション、雄弁、文章力、論理分析、ステークホルダー管理、リスク管理。

• 2. ビジネススキルと手法：ビジネスケース、ビジネスシナリオ、組織構造、ビジネスプロセス、戦略計画、予算管理、戦略的ビジョン、ビジネス指標、ビジネス文化、レガシー投資、ビジネス機能。

• 3. エンタープライズ アーキテクチャ スキル: ビジネス プロセス設計、役割設計、組織構造設計、データ設計、アプリケーション設計、システム統合、IT 業界標準、サービス設計、アーキテクチャ原理設計、ビューとパースペクティブ設計、ビルディング ブロック設計、ソリューション モデリング、利点分析、ビジネス対話、システム動作、プロジェクト管理。

• 4. プログラムおよびプロジェクト管理スキル: プログラム管理、プロジェクト管理、ビジネス変更の管理、変更管理、価値管理。

• 5. 一般的な IT の知識とスキル: IT アプリケーションの開発方法とツール、プログラミング言語、エージェント アプリケーション、情報消費アプリケーション、情報提供アプリケーション、ストレージ管理、ネットワーク、Web ベースのサービス、IT インフラストラクチャ、資産管理、サービス レベル アグリーメント、システム、商用既製、エンタープライズ継続体、移行計画、管理ツール、インフラストラクチャ。

• 6. IT スキル: ソフトウェア エンジニアリング、セキュリティ、システムおよびネットワーク管理、トランザクション処理、場所とディレクトリ、ユーザー インターフェイス、国際業務、データ交換、データ管理、グラフィックスおよび画像、オペレーティング システム サービス、ネットワーク サービス、通信インフラストラクチャ。

• 7. 法的環境: 契約法、データ保護法、調達法、詐欺、商法

ソフト試験用システムアーキテクチャデザイナー

システム アーキテクトは、コンピュータ テクノロジおよびソフトウェアの専門技術資格の高度な認定です。公式の紹介を参照してください: https://www.ruankao.org.cn/platform/details?code=03_03

試験要件は、
(1) コンピュータのハードウェア、ソフトウェア、およびネットワークに関する基本的な知識を習得していること、
(2) 情報システム開発プロセスに精通していること、
(3) 情報システム開発標準および共通の情報技術標準を理解していること、
(4) 精通していることである。 (5)ソフトウェア
システムモデリングとシステムアーキテクチャ設計の基礎技術を習得する
(6) 情報セキュリティ技術、セキュリティ戦略、セキュリティ管理知識に精通する
(7) 法律や法律の基礎を理解する(8) 情報化・IT関連法規制 (8)
利用者の業界特性を理解し、業界特性に応じた適切なシステム設計を構築
(9) 応用数学の基礎知識を修得
(10) 英語文献を読み正しく理解する能力関連分野で

まだまだ知るべきことがたくさんあることがわかります。

エピローグ

Architecture Talk の 5 章はここで終わります。
次の記事では、私が経験した需要分析のいくつかの事例と、当社が採用している技術設計ソリューションをリストします。