ソフトウェアアーキテクト
アーキテクトとして、多くの異なるコンポーネントと概念を念頭に置き、
それらがどのように機能するかについて基本的な知識を持っている必要がある
アプリケーション全体を高いレベルで把握
- 変更が及ぼす影響範囲は？
- パフォーマンスの変化は？
- 別のコンポーネントの動作は異なるか？
- パフォーマンスの変更によるバグの発生はあるか？
- 変更を加える場合、十分な時間はあるか、サポートが必要か？
開発者からアーキテクトに移行すると、
責任の範囲が単一のコンポーネントから多数のコンポーネントの相互接続に拡大する
- 複数のコンポーネント、システム間の相互作用に焦点を当てる
- 異なるレベルの抽象化で操作し、問題を異なる方法で考えることが期待される
- 問題を解決し、ソリューションを共有する
- 単に問題に対する答えを提示するだけでなく、開発者が正しい決定を下す支援をする
- 開発者を教育する
「最高のアーキテクトは、チーム全体の経験とスキルを活用する」
レビュワーとしてのアーキテクト
システム全体の品質に大きな影響を与えるため、品質のゲートキーパーとしての役割も担う - 変更は全体的な技術的負債を増減させるか？ - ビジネスニーズを満たしているか？ - 設計が品質向上に貢献しているか？
アプリケーションのパフォーマンス、可用性、
機能がどのように向上するか、他のコンポーネントにどのように影響するか等を評価
アーキテクトがやっていること
常に学び、チームにどう貢献できるかを考えている - 自己学習 - 新しいツールを試す - アルゴリズム - ベストプラクティス - アーキテクトのネットワークを広げる、メンターを探す - 新しいテクノロジーをチームに教育・コーチする
最新のテクノロジー、アーキクテクチャの情報を仕入れて、どのように役に立つかを理解するための行動をとる - チームへのトレーニングの責任 - チームのパフォーマンスの評価に深く関わっている
スケーラビリティ等、アプリケーション全体に責任を持つ
=> 本番環境で適切に動作しているか？
例えるなら、「オーケストラの指揮者」
これからアーキテクトを目指すには
- 1.自分の責任の範囲を超えて、仕事を引き受ける
- 2.アプリケーションの課題を見つけて、その問題の修正に貢献する
責任を持ち、問題を提起し、改善のアイデアを出す（修正する）動きをしよう