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

Question

ソフトウェアアーキテクト（SA）の役割について良い答えを得て多くの質問がありました スタックオーバーフロー と プログラマーSE. 。私はそれらよりも少し集中した質問をしようとしています。 SAの定義そのものが広いので、この質問のために、SAを次のように定義しましょう。

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

言い換えれば、私は経営陣の休息について話していません。あらゆる種類のSAポジションを追求する場合、コーディングから離れたくありません。私はクライアントやビジネスアナリストなどとのインターフェースに時間を犠牲にするかもしれませんが、私はまだ技術的に関与しており、会議を通して何が起こっているのかを知っているだけではありません。

これらのポイントを念頭に置いて、SAはテーブルに何をもたらすべきですか？彼らは「法律を定めた」（いわば）（いわば）、特定のツールの使用法を「彼らのやり方」に合わせて実施するという考え方を持って来るべきですか？または、最初の方向と戦略を指定する必要があります。その後、船の方向を修正するために必要に応じてジャンプしてジャンプしますか？

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

ここに、私の質問への答えがこれらの問題に光を当てることを期待して、いくつかの背景を共有する方法として私が経験したいくつかのSAストーリーを紹介します。

• 私は、チームのコードのすべての行を文字通りレビューしたSAと仕事をしました。 SAは、私たちのプロジェクトだけでなく、組織内の他のプロジェクトのためにこれを行います（これに費やした時間を想像してください）。最初は特定の基準を実施することは有用でしたが、後で不自由になりました。 FXCOPは、SAが問題を見つける方法でした。誤解しないでください、それはジュニア開発者に彼らに選ばれたアプローチの結果を考えるように強制する良い方法でしたが、シニア開発者にとってはやや厳しいと見られていました。

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

• すべてのプロジェクトでDTO、DOS、BOS、サービスレイヤーなどの使用を実施するSA。新しい開発者は、このアーキテクチャとSAが断固として実施された使用ガイドラインを学ばなければなりませんでした。ガイドラインに従うことが絶対に困難であった場合、ガイドラインを使用する例外が行われました。 SAは彼らのアプローチに基づいていました。 DTOおよびすべてのCRUD操作のクラスは、コードスミスとデータベーススキーマを介して生成されました。ただし、このセットアップをどこでも使用していたため、SAはLINQからSQLまたはEntity Frameworkなどの新しいテクノロジーに開かれていませんでした。

私はこの投稿を通気のためのプラットフォームとして使用していません。上記のSAストーリーでの私の経験には、前向きな側面と否定的な側面がありました。私の質問は次のとおりです。

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

ありがとう！これらのジョブタスクは、シニアデヴァや技術的なリードである人々に簡単に拡張されると確信しているので、その能力にも気軽に答えてください。

Answer 1

システムアーキテクトは次のようにする必要があります。

1. 高レベルのアーキテクチャを指定します
2. コードレビューに参加します
3. 使用されるテクノロジーを承認します
4. 開発者がコーディングの取り組みを支援します
5. 開発スケジュールを維持および監視します
6. UML図、ガントチャートなどのSAアーティファクトを作成します。

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

SAには、すべてのデザイン、テクノロジー、コーディングスタイルの決定に関する最後の単語が必要です。しかし、すべてのマネージャーと同様に、SAの仕事は、彼らが生産的になるように彼の人々の道をクリアすることです。つまり、ほとんどの場合、開発者は自分のレベルで、問題をどのように解決するかを決定することを意味します。それは、SAが開発者のキュービクルから尖った髪のボスを締め出すことを意味します。そして、それは、必要に応じてSAが支援するためにピッチングすることを意味します。

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

Answer 2

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

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

2彼らはどのようにして意思決定にバランスをとることができますか？

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

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

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

もっとたくさんありますが、これには本当に良い答えが来ると思います。

Answer 3

主に実用的ではなかったため、私は役に立つ建築家に出くわしたことはありません。

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

• プロセスのためにプロセスを盲目的に順守します
• 問題を知る前に、技術に対する盲目的なバイアス
• 正当化なしにルールの作成と執行
• rewrite from scratch メンタリティ

私がテーブルに持ってきた最高の「建築家」：

• 問題と潜在的な解決策をよりよく理解するようになった質問。
• 設計オプション/テクノロジーとそのトレードオフ。
• デザインとテクノロジーの非難と支持の両方について明確かつ合理的な説明。

私にとっての問題は、私が仕事をしていなかった最高の「建築家」です。彼らのタイトルには「建築家」です。彼らはほとんどの場合、特定の問題とプロジェクトに基づいているソフトウェアエンジニアでした。作業コードベースをゼロから書き換えるのは実用的です。デザインの決定を下したり、オプションとその理由や正当化を提供したりします。彼らは、コードベースを時間の経過とともに新しいアーキテクチャに反復する方法をマップし、それでもすべてを機能させます。何でも dejour またはおなじみ。彼らは、物事がどのように機能するか、そしてその理由についてのまとまりのあるビジョンを伝えるでしょう、 しかし さらに重要なことは、彼らがそこに到達する方法とコストをマップすることです。

Answer 4

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

「彼らは「法律を定めた」という考え方を持って来るべきか...または彼らは最初の方向と戦略を指定してから、船の方向を修正するために必要に応じてゆっくりとジャンプする必要がありますか？」

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

テクノロジーに関しては、あなたが持っているものと連携して、会社がstarteamを使用している場合、それがあなたが使用するものです。特定の製品/テクノロジー/プロセスと自分自身と結婚することは、あなたのために何もするつもりはありません。

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

チームの話を聞いて、いつ彼らが正しいかを知る と 間違っていることが重要であり、コジョンに彼らが間違っていることを伝え、あなたの決定に固執することを彼らに伝えることができます。聞いていないことは、あなたの決定を揺るがすように、尊敬の欠如をもたらします。

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

いつも。そうでない場合、囚人は亡命を明白に、または秘密に走らせることになります。ただし、これらの基本規則を決定することは、チームとの話を通して行うことができます。チームは常に同じメンバーを持っているとは限らない可能性があるため、彼らの小さなグループのために譲歩することは、将来、チームが去った後、チームを妨げる可能性があることを忘れないでください。それにはSAが含まれます。

4.他のものを考慮するものはありますか？

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