ソフトウェアアーキテクトとして何を提案する必要がありますか？
StackOverflow と Programmers SE でのソフトウェアアーキテクト（SA）の役割について、多くの質問がありました。私はそれらよりも少し焦点を絞った質問をしようとしています。 SAの定義自体は広いので、この質問のために、SAを次のように定義します。
ソフトウェアアーキテクトは、プロジェクトの全体的な設計をガイドし、コーディング作業に関与し、コードレビューを実施し、使用するテクノロジーを選択します。
言い換えれば、私は管理上の休息とSAの種類（さらに韻を踏んだ言葉は省略されます）の頂上でのベストについて話しているのではありません。あらゆるタイプのSAポジションを追求する場合、コーディングから離れたくありません。クライアントやビジネスアナリストなどとやり取りするために少し時間を犠牲にするかもしれませんが、技術的にはまだです。関与し、私は会議で何が起こっているのかを知っているだけではありません。
これらの点を念頭に置いて、SAをテーブルに持ち込む必要がありますか？彼らは（いわば）法律を定める）精神を持ち、特定のツールの使用を強制する必要があります「その方法」、つまり、コーディングガイドライン、ソース管理、パターン、UMLドキュメントなどに適合させるか？または、初期方向と戦略を指定してから、必要に応じて配置し、船の方向を修正する必要がありますか？
組織によっては、これが機能しない場合があります。 SAすべてを実施するためにTFSに依存する人は、StarTeamのみを使用する雇用主で計画を実装するのに苦労するかもしれません。同様に、SAプロジェクトの段階では、新しいプロジェクトであれば選択肢が増えますが、既存のプロジェクトでは選択肢が少なくなる可能性があります。
ここにいくつかのSAストーリーがあります。私の質問への回答がこれらの問題にいくつかの光を当てるかもしれないと期待していくつかの背景を共有する方法として私が経験した物語：
私はSAコードをチームのコードのすべての行で文字どおりレビューした人と協力してきました。SAは私たちのプロジェクトだけでなく他の人にもこれを行います組織内のプロジェクト（これに費やされる時間を想像してください）。最初は特定の標準を適用することは有用でしたが、後でそれは不自由になりました。FxCopはSAが問題を見つける方法でした。私を誤解して、ジュニア開発者に教えて、彼らに彼らが選んだアプローチの結果を考えるように強制することは良い方法でした、しかし上級開発者にとってそれは幾分厳格であると見られました。
ある特定のSAは、特定のライブラリの使用に反対しており、遅いと主張していました。これにより、他のライブラリが私たちに多くの節約をしてくれる一方で、異なることを達成するために大量のコードを書くことを余儀なくされました時間。プロジェクトの最後の月に早送りし、クライアントはパフォーマンスについて不満を言っていました。唯一の解決策は、開発者からの早期の警告にもかかわらず、最初は無視されていたアプローチを使用するように特定の機能を変更することでした。その時点で多くのコードがスローされました残念ながら、このプロジェクトに使用された見積もりは、私のプロジェクトで使用が禁止されていた古いアプローチに基づいていたため、見積もりの適切な指標ではありませんでした。PM「以前にこれを行った」と言いますが、実際には新しいライブラリを使用していたのでそうではなく、そのライブラリで作業している開発者は古いプロジェクトで使用していた開発者と同じではありませんでした。
SAすべてのプロジェクトでDTO、DO、BO、サービスレイヤーなどの使用を強制する人。新しい開発者はこのアーキテクチャとSA =厳格に施行された使用ガイドライン。ガイドラインに従うことが非常に困難な場合は、使用ガイドラインの例外が作成されました。SAは、そのアプローチに基づいています。DTOのクラスとすべてのCRUD操作は、CodeSmithを介して生成されましたとデータベーススキーマも同様のワックスの塊でしたが、SAはLINQ to SQLやEntity Frameworkなどの新しいテクノロジーには対応していませんでした。
私はこの投稿を通気用のプラットフォームとして使用していません。上記のSAストーリー）の経験には、プラス面とマイナス面がありました。私の質問は次のように要約されます。
- SAはテーブルに何を持っていくべきですか？
- どのようにして意思決定のバランスをとることができますか？
- SAジョブ（前に定義したとおり））は、特定の基本ルールを適用する必要があるという考え方でアプローチする必要がありますか？
- 他に考慮すべきことはありますか？
ありがとう！これらの仕事は、上級開発者やテクニカルリードにも簡単に適用できると思いますので、その能力についてもお気軽に回答してください。
システムアーキテクトは次のことを行う必要があります。
- 高レベルのアーキテクチャを指定する
- コードレビューに参加する
- 使用するテクノロジーを承認する
- 開発者のコーディング作業を支援する
- 開発スケジュールを維持および監視する
- SAアーティファクト（UML図、ガントチャートなど）を生成します。
SAはコーディングの方法を知っている必要があり、コーディング作業の一部に参加し、いわば手を濡らす必要があります。これにより、彼らは開発努力のゲシュタルトと連絡を取り合うことができます。ボブマーティンおじさん かつて言った のように、アーキテクトは自分でコーディングの一部を行う必要があります。そうすることで、彼は自分のデザインで他の人に与えている痛みを見ることができます。
SAは、すべてのデザイン、テクノロジー、コーディングスタイルの決定について最後の言葉を持っている必要があります。しかし、すべてのマネージャーと同様に、SAの仕事は、彼らが生産的になることができるように彼の人々のためのパス。それは、ほとんどの場合、開発者が彼らのレベルで問題がどのように解決されるかを決定することを意味します。それはSA先のとがった髪のボスを開発者のキュービクルから遠ざけます。これは、SAが必要に応じて役立つようにピッチすることを意味します。
すべての人間と同様に、SAは間違いを犯す可能性があります。良いものはそれらの過ちから学び、より良いSAになります。
主に実用的ではなかったという理由で、私は有用なアーキテクトに出会ったことがありません。
私にとって、私が目にした最大の問題は次のとおりです。
- プロセスのためにプロセスを盲目的に順守する
- 問題を知る前のテクノロジーへの盲目的な偏見
- 正当な根拠のないルールの作成と施行
rewrite from scratch考え方
私が一緒に働いた中で最高の「建築家」がテーブルに持ち込まれました：
- 問題と潜在的な解決策をよりよく理解するための質問。
- 設計オプション/技術とそのトレードオフ。
- デザインとテクノロジーの非難と推奨の両方に対する明確で合理的な説明。
私にとっての問題は、私が一緒に仕事をした中で最も優れた「アーキテクト」でした。タイトルに「アーキテクト」はありませんでした。彼らは、ほとんどの場合、特定の問題とプロジェクトに基づいたソフトウェアエンジニアでした。ほとんどのビジネスでは、機能するコードベースを最初から書き直すのが現実的です。設計上の決定を行ったり、オプションとその理由や正当性を提供したりします。コードベースを新しいアーキテクチャに繰り返し適用して、すべての機能を維持する方法を示します。推奨するのではなく、保守的な推奨を行います。 dejourまたはなじみのあるものは何でも、それらは物事がどのように機能するか、そしてその理由についてのまとまりのあるビジョンを伝えます[〜＃〜] but [〜 ＃〜]より重要なことは、そこに到達する方法とコストを明確にすることです。
1 SAはテーブルに何をもたらす必要がありますか？
- 厚い肌
- 優れた交渉力
- さまざまなソフトウェア層をよく理解している（whizzy AJAX goodness to low level networking I/O）。あなたは必ずしも専門家である必要はありませんが、どのソフトウェアをどのレイヤーで実行するかに関する重要な決定。
- コードで手を汚そうとする意欲、ホワイトペーパーデザインはそれをカットしません。
- ソフトウェアの職人技の奨励-可能な場合は常に正しい方法で、他のケースでは制限が与えられた場合に最善の方法を実行するためのチアリーダーになります。ソース管理、TDD、ビルドとCI、DOJOのコーディング、コードレビュー、優れた問題追跡システムなど
2彼らはどのようにして意思決定のバランスをとることができますか？
- その多くは、チームとその能力に依存します。
- 環境（たとえば、特定のベンダーの製品を使用するように強制される場合があります）
- 全体として、象牙の塔の建築家ではなく、実際に行動し、チームの一員になることが最善です。人々はあなたの決定をそのように理解します。
3 SA仕事（前に定義したとおり））は、特定の基本ルールを適用する必要があるという考え方でアプローチする必要がありますか？
- はい、バージョン管理やビルドシステムなどは非常に重要であり、開発者はこれらを使用する必要があります。ただし、それらをソリューションの一部にすることは最善の方法です。
まだまだたくさんありますが、これについては本当に良い答えが出てくると思います。
1。SAはテーブルに何をもたらす必要がありますか？
「彼らは「法を定める」という考え方を持っていなければなりませんか...それとも、彼らは最初の方向と戦略を指定し、その後、船の方向を修正するために必要に応じて横になってジャンプしますか？」
両方の組み合わせだと思います。テクノロジーとプロセスを決定する際、意見や提案にオープンであることは、決定に関する貴重なフィードバック/インプットを提供し、他の人から学ぶようにさせることができます。あなたのチームは（うまくいけば）賢いです。それを利用してください。しかし、決定（あなたの決定）がなされると、法律が制定されました。自分の選択ではなかったものについて不満を言う人と、何でも選択して気にしない人を特定して、無視します。
テクノロジーに関しては、手元にあるものを使用してください。会社がStarTeamを使用している場合は、それを使用します。特定の製品/テクノロジー/プロセスと結婚しても、何もしません。
2.意思決定においてどのようにバランスをとることができますか？
チームに耳を傾け、彼らが正しいことを知るand間違っていること、そしてコジョーンに彼らが間違っていることを伝え、あなたの決断に固執することは重要です。耳を傾けないことは、あなたの決定に行き着くので、尊敬の欠如をもたらします。
3. SAジョブ（前に定義したとおり））が特定の基本ルールを適用する必要があるという考え方でアプローチする必要がありますか？
常に。そうでない場合、受刑者は、あからさまにまたはひそかに亡命を実行することになります。ただし、これらの基本ルールの決定は、チームとの話し合いを通じて行うことができます。どのチームも現在のメンバーと同じメンバーを常に持つとは限らない場合があるため、少人数のグループに譲歩を与えると、チームが去った後の将来のチームの妨げになる可能性があります。これにはSAが含まれます。
4.他に考慮すべきことはありますか？
- 2番目の例を参照してください。プロジェクトチームは、社内のサブシステムに密結合の依存関係を形成しているようです。疎結合のファサードは、サードパーティのコードだけのものではありません。そのサブシステムの抽象化を作成すると、社内ソリューションが失敗した場合に、そのライブラリの使用への移行が容易になります。これは、ソフトウェアアーキテクトだけの論理的なソリューションですが、チーム式の懸念を持つプロジェクトマネージャーの一形態でもあるため、明白なソリューションであるはずです。
- 3番目の例を参照してください。ソフトウェアを作成するための既知のアーキテクチャまたはプロセスがあることは悪い考えではありません（確かに、「すべてのプロジェクト」と言っていましたが）。これは機能するものにこだわっています。そうは言っても、新しい技術が追加の価値をもたらすかどうかを確認するために試みることができる機会が必要です。社内限定のソフトウェア、またはこれらのテクノロジーを試すことができる小規模プロジェクトは理想的な場所です。ただし、テクノロジーを採用するための研究された説得力のあるデモンストレーション/議論を提供する責任は開発者にもあることを覚えておいてください。そして、SAは、競合するすべてのORMと、他と比較したその長所と短所を知ることは期待できません。