一般的なアーキテクチャの原則とコンポーネントの関係を理解することは正しい方向への一歩ですが、私がお勧めすることはさらに一歩です。 多くの場合、実装の詳細によって、システムの動作が高レベルのアーキテクチャ以上に決まります。 実際、日常的な低レベルの操作は、遅かれ早かれ、コンポーネントとサブシステムの高レベルの接続が明るい線で表示されるパズルに発展します。 「しかし、それはそのサブシステムで行われたと思った...」または「早く/後で完了する必要があることを知らなかったため、ここでこの操作を実行しました」という状況には決して陥りません。 サブシステムの相互作用の詳細や将来の機能を実装する可能性のある方法について同僚やマネージャーと話し合うことができる「啓発」のレベルにいることに気付くでしょう。
システムのコード全体を読んだ後、新しい関数を開発するタスクの見通しがどのように変化するかがわかります。
- システムのどの部分が新しい機能の影響を受けるかをすぐに理解できます。 新しい機能を開発するための複雑さと時間をよりよく評価できます。 システムの一般的なビューでは、個々のコンポーネントの開発者に、それらを一緒にドッキングする方が良いかどうかについての推奨事項を作成することさえできます
- システム全体の動作を理解しているため、個々のサブシステムの開発者が注意を払わなかったいくつかの状況で問題を予測できます。
- あなたのマネージャーは、問題の複雑さを評価するという点であなたに頼ることができ、最小の労力で最高の結果で現時点で解決できるものを選択することができます。 原則として、マネージャーは特定のサブシステムの開発者にこのような評価を依頼することができますが、これは非常に小さなチーム（5人まで）でのみ有効です。 ただし、バランスを保つようにする必要があります。同僚に忘れられないように気をつけないでください。 システムの深い知識と理解は、他のチームメンバーがあなたに気付いた場合には役に立ちません。
- 個々のサブシステムを担当する同僚は、アドバイスを求め始めます（そして感謝します）。 アドバイスを求められたとき、これは誰かの仕事のミクロ管理に従事し始めているというサイン（良いことではありません）、または特定のチーム/プロジェクトで状況的リーダーシップの段階を経ているというサインです（まだ公式のチームリーダーではありませんが、すでにオピニオンリーダーの1人）。
新しい機能を開発するという文脈から、さらにいくつかのことに気付くかもしれません。
- プロジェクトの技術専門家に正式に任命され、完全に新しい視野が開かれます
- より多くのプール要求を表示する必要があります。 高品質の処理には時間がかかります。
- より戦略的な会議に招待されます。
- より頻繁にアーキテクチャ設計に関与します
- 長期的な目標を達成するために、システム全体がどこに移動するべきかについて、独自のビジョンがあります。
- 外部クライアントに助言する必要があります
- マネージャーとの連絡が頻繁になり、判断がますます信頼されるようになります。
- 自分でコードを書く時間を見つけることはめったにありません
- 彼らは自分の考えを表現し、評価を求めるようになるでしょう。
- 給料が上がります
- 投稿のタイトルに「シニア」という単語が表示されます
- 人々はあなたを彼らのリーダーとして見始めます。
- 同僚は、問題やボトルネックを予測する能力に感銘を受けます。 一般に、それらは、そのような洞察まで手を伸ばした距離と同じ距離にあります（製品のコード全体を取得して読み取る必要があります）
- 各新機能は、チェスゲームの動きとみなされます（非常に多くのポジション、脅威、機会があります）。
- 完了したすべての作業が、ある時点でのシステムの状態に関する知識のワンショットスナップショットのみを提供したことを理解します。 コードに関するあなたのアイデアは、プールのリクエストごとに時代遅れになり、知識の陳腐化と日々戦わなければなりません。 まあ、あなたは知っている、「ちょうどその場所にとどまるために速く走る」。
だから、あなたは知っている...より良いあなたはこのすべてのコードを読んでいない。 人生はそれなしではるかに簡単です:)