ソフトウェアアーキテクトとして何をテーブルに持ち込むべきですか？[閉まっている]

StackOverflowおよびProgrammers SEでのソフトウェアアーキテクト（SA）の役割について、多くの質問があり、適切な回答があります。私はそれらよりも少し焦点を絞った質問をしようとしています。SAの定義は非常に広いため、この質問のためにSAを次のように定義します。

ソフトウェアアーキテクトは、プロジェクトの全体的な設計をガイドし、コーディング作業に関与し、コードレビューを実施し、使用するテクノロジを選択します。

言い換えれば、私は管理上の休息と、頂上（さらに押韻された言葉は省略された）タイプのSAについては話していない。何らかのSAポジションを追求する場合、コーディングから離れたくありません。クライアントやビジネスアナリストなどとのやり取りに時間を割くかもしれませんが、私はまだ技術的に関わっており、ミーティングで何が起こっているのかだけを知っているわけではありません。

これらの点を念頭に置いて、SAはテーブルに何をもたらすべきですか？彼らは「法を定める」（いわば）「特定のツール」の使用を「彼らのやり方」、つまりコーディングガイドライン、ソース管理、パターン、UML文書などに強制するという考え方で入るべきですか？または、彼らは最初の方向と戦略を指定してから、船の方向を修正するために必要に応じて元に戻して飛び込むべきですか？

組織によっては、これが機能しない場合があります。すべてを実施するためにTFSに依存するSAは、StarTeamのみを使用する雇用主で計画を実施するのに苦労する場合があります。同様に、SAはプロジェクトの段階に応じて柔軟である必要があります。新しいプロジェクトの場合は選択肢が多くなりますが、既存のプロジェクトでは選択肢が少なくなる可能性があります。

私の質問への回答がこれらの問題にいくらかの光を当てることを期待して、いくつかの背景を共有する方法として私が経験したいくつかのSAの物語があります：

• 私は、チームのすべてのコード行を文字通りコードレビューするSAと協力しました。SAは、プロジェクトだけでなく、組織内の他のプロジェクトに対してもこれを行います（これに費やされる時間を想像してください）。最初は特定の標準を実施することが有用でしたが、後にそれは不自由になりました。FxCopは、SAが問題を見つける方法でした。誤解しないでください。ジュニア開発者に教えて、選択したアプローチの結果を考えさせることは良い方法でしたが、上級開発者にとってはやや厳しいと見なされていました。

• ある特定のSAは、特定のライブラリの使用に反対し、遅いと主張しました。これは、他のライブラリが多くの時間を節約するであろう一方で、物事を異なる方法で達成するために大量のコードを書くことを強制しました。プロジェクトの最終月に早送りすると、クライアントはパフォーマンスについて不満を言っていました。唯一の解決策は、開発者からの早期警告にもかかわらず、当初無視されていたアプローチを使用するように特定の機能を変更することでした。その時点までに、多くのコードが破棄され、再利用できなくなり、残業とストレスにつながりました。悲しいことに、このプロジェクトに使用された推定値は、私のプロジェクトが使用することを禁じていた古いアプローチに基づいていたため、推定の適切な指標ではありませんでした。首相が「これをやったことがある」と言うのを聞くでしょう

• すべてのプロジェクトでDTO、DO、BO、サービスレイヤーなどの使用を強制するSA。新しい開発者はこのアーキテクチャを学習する必要があり、SAは使用ガイドラインを徹底的に実施しました。ガイドラインに従うことが絶対に困難である場合、使用ガイドラインの例外が作成されました。SAはそのアプローチに基づいていました。DTOのクラスおよびすべてのCRUD操作はCodeSmithを介して生成され、データベーススキーマも同様のワックスボールでした。ただし、このセットアップをあらゆる場所で使用したため、SAはLINQ to SQLやEntity Frameworkなどの新しいテクノロジーに対してオープンではありませんでした。

私はこの記事を通気用のプラットフォームとして使用していません。上記のSAストーリーに関する私の経験には、プラス面とマイナス面がありました。私の質問は次のように要約されます：

1. SAはテーブルに何をもたらすべきですか？
2. 彼らは意思決定においてどのようにバランスを取ることができますか？
3. 特定の基本ルールを実施しなければならないという考え方で、SAジョブ（前に定義したとおり）にアプローチする必要がありますか？
4. 他に考慮すべきことはありますか？

ありがとう！これらの仕事のタスクは、上級開発者や技術リーダーである人々に簡単に拡張できると思いますので、その能力についてもお気軽にお答えください。

システムアーキテクトは以下を行う必要があります。

1. 高レベルのアーキテクチャを指定する
2. コードレビューに参加する
3. 使用した技術を承認する
4. 開発者のコ​​ーディング作業を支援する
5. 開発スケジュールを維持および監視する
6. UMLダイアグラム、ガントチャートなどのSAアーティファクトを作成します。

SAはコーディングの方法を知っている必要があり、コーディング作業の一部に参加し、いわば手を濡らさなければなりません。これにより、開発努力のゲシュタルトと連絡を取り合うことができます。ボブ・マーティンおじさんがかつて言ったように、建築家は自分でコーディングの一部を行うべきです。

SAは、すべての設計、技術、コーディングスタイルの決定について最後の言葉を持っている必要があります。しかし、すべてのマネージャーと同様に、SAの仕事は、従業員の生産性を高めるために従業員の道を切り開くことです。それは、ほとんどの場合、開発者がレベルで問題を解決する方法を決定することを意味します。これは、SAが開発者のキュービクルから先のとがった髪のボスを締め出すことを意味します。また、必要に応じて、SAが支援を提供することを意味します。

すべての人間と同様に、SAは間違いを犯す可能性があります。良いものはそれらの間違いから学び、より良いSAになります。

主に実用的ではなかったため、私は有用な建築家に出会ったことがありません。

私にとって最大の問題は次のとおりです。

• プロセスのためのプロセスへの盲目的な順守
• 問題を知る前の技術に対する盲目的な偏見
• 正当な理由のないルールの作成と施行
• rewrite from scratch メンタリティ

私が一緒に仕事をした中で最高の「アーキテクツ」がテーブルに持ち込まれました。

• 問題と潜在的な解決策をよりよく理解するために駆り立てられた質問。
• 設計オプション/技術とそのトレードオフ。
• 設計と技術の非難と承認の両方に対する明確で合理的な説明。

私にとっての問題は、「Architect」を持たない最高の「アーキテクツ」です。彼らはほとんどの場合、特定の問題とプロジェクトに根ざしたソフトウェアエンジニアでした。実用的なコードベースをゼロから書き直すことは実用的です。設計決定を行い、オプションとその理由または正当化を提供します。コードベースを時間とともに新しいアーキテクチャに反復する方法をマップし、すべてを機能的に維持します。あるものは何でもdejourや身近な。彼らは物事が動作すると、なぜべきかの凝集ビジョンを伝えるだろう、しかしもっと重要なのは、彼らはそこでコストを取得する方法をマップします。

1 SAはテーブルに何をもたらすべきですか？

• 厚い肌
• 優れた交渉スキル
• さまざまなソフトウェア層についての十分な理解（奇抜なAJAXの良さから低レベルのネットワークI / Oまで）。必ずしも専門家である必要はありませんが、どのソフトウェアをどのレイヤーで実行するかについて、重要な決定を下すことになります。
• コードで手を汚そうとする意欲はありますが、ホワイトペーパーのデザインはそれをカットしません。
• ソフトウェアのクラフツマンシップの奨励-可能な限り正しい方法で物事を行うためのチアリーダーになり、他の場合の制限を考慮して最良の方法になります。ソース管理、TDD、ビルドとCI、DOJOのコーディング、コードレビュー、優れた問題追跡システムなどのようなもの

2意思決定においてどのようにバランスを取ることができますか？

• その多くは、チームとその能力に依存します。
• 環境（たとえば、特定のベンダーの製品を使用せざるを得ない場合があります）
• 全体として、象牙の塔の建築家ではなく、実践的であり、チームの一員であることが最善です。人々はあなたの決定をそのように理解します。

3特定の基本ルールを実施しなければならないという考え方で、SAジョブ（以前に定義したとおり）にアプローチする必要がありますか？

• はい、バージョン管理やビルドシステムなどは非常に重要であり、開発者はこれらを使用する必要があります。ただし、それらをソリューションの一部にすることをお勧めします。

まだまだたくさんありますが、この点については本当に良い答えが出てくると思います。

1.SAはテーブルに何をもたらすべきですか？

「彼らは「法律を制定する」という考え方で入るべきでしょうか、それとも、船の方向を修正するために、必要に応じて最初の方向と戦略を指定し、飛び降りる必要がありますか？」

私が言う両方の組み合わせ。テクノロジーとプロセスを決定する際、意見や提案にオープンであることは、決定に関する貴重なフィードバック/入力を提供し、他の人から学ぶようにします。あなたのチームは（うまくいけば）賢いです。それを利用してください。しかし、決定（あなたの決定）が行われると、法律が制定されました。自分の選択ではなかったものについて不平を言う人と、何でも選択して気にしない人を特定し、それらを無視します。

技術に関しては、あなたが持っているものと連携し、会社がStarTeamを使用している場合、それがあなたが使用しているものです。特定の製品/技術/プロセスと結婚しても、何の効果もありません。

2.意思決定においてどのようにバランスを取ることができますか？

チームを聞くと、彼らは右のときを知ると間違っが重要であり、それらを伝えるためにcojonesを持っているあなたの決定に彼らしている間違ったスティック。耳を傾けないことは、あなたの決定をあざ笑うように、敬意の欠如をもたらします。

3.特定の基本ルールを実施しなければならないという考え方で、SAジョブ（以前に定義したとおり）にアプローチする必要がありますか？

常に。そうでない場合、受刑者は、あからさまに、または密かに、亡命を実行することになります。ただし、これらの基本ルールを決定することは、チームと話し合うことによって行うことができます。どのチームも常に現在と同じメンバーを持っているとは限らないため、少数のグループに譲歩することは、チームが去った後に将来チームを妨げる可能性があることに注意してください。これにはSAが含まれます。

4.他に考慮すべきことはありますか？

• 2番目の例を参照してください。プロジェクトチームは、社内のサブシステムに密接に依存しているようです。疎結合のファサードは、サードパーティのコード専用ではありません。社内ソリューションが失敗した場合、そのサブシステムの抽象化を作成することで、そのライブラリの使用に簡単に移行できます。これはソフトウェアアーキテクトだけの論理的なソリューションですが、チームの表現に関する懸念を持つプロジェクトマネージャーのフォームでもあり、二重の明らかなソリューションであるはずです。
• 3番目の例を参照してください。ソフトウェアを製造するための既知のアーキテクチャまたはプロセスを持つことは悪い考えではありません（ただし、確かに、「すべてのプロジェクト」と言いました）。これは何が機能するかにこだわっています。そうは言っても、新しい技術が付加価値をもたらすかどうかを確認するために、新しい技術を試す機会が必要です。社内専用のソフトウェア、またはこれらの技術を試すことができる小規模なプロジェクトは理想的な場所です。ただし、技術を採用するための調査済みの説得力のあるデモンストレーション/引数を提供する責任は開発者にもあります。また、SAは、競合するすべてのORMと、他のORMと比較したその長所と短所を知ることは期待できません。