アプリケーションアーキテクトはコードを書くべきですか？
これはよくある質問であり、双方の意見があります。賛成者は次のように主張します。
- コーダー向けのシステムを設計するには、コーディング方法を理解する必要があります（そしてコーディングする必要があります）
- 地上で何が起こっているのかを意識せずにシステムを設計することはできません
- アーキテクチャとは、幅広いストロークの設計だけでなく、コードレベルで変化するニーズに適応することでもあります。
一方、
- アーキテクチャは高レベルの役割であり、実装の詳細について心配する必要はありません
- コーディングは詳細志向のヘッドダウン機能であり、リスク管理、アーキテクチャの広い視野の性質と対立しています。
- アーキテクチャは技術的なリスク管理に関するものであり、実装ではありません
- アーキテクチャはリーダーシップに関するものです。後ろからリードするのは難しい
私の経験では、アーキテクトはコーディングに多くの時間を費やすべきではありませんが、主にリード開発者とのコミュニケーション、レビュー、スタンドアップを通じてコードベースと連絡を取り合う必要があります。コーディングに多くの時間を費やすと、高レベルの問題を見失い、技術的リスクの管理に効果がなくなります。
コーディングに対するあなたの議論が有効であるとしても、開発チームがあなたとあなたの設計上の決定を尊重することは重要だと思います。アーキテクチャの決定がそれらと一緒に「結果に苦しむ」場合、それらははるかにそれらに疑問を呈する可能性が低くなります。
常に、コーディング側と連絡が取れておらず、開発チームがそれを知っているアーキテクトを目にします。彼らはあまり尊敬されていません。
Ab-so-frickin-lutely
現実との接触を失った建築家ほど悪いことはありません。
足を地面に置き、頭を雲の中に置くのは仕事の一部です。
私の2セント（そして「建築家」の私のビジョン）を与えるためだけに
アーキテクトにはいくつかのタイプがあり、それぞれが独自のドメインにあると思います。
ビジネスアーキテクトと機能アーキテクト：彼らはビジネスオペレーションと機能ワークフローに関心があり、実際には、コーディングするべきではありません。なぜなら、それらはあらゆる種類の実装から自分自身を抽象化できなければならず、機能仕様を生成する必要があるからですテクニカルソリューションを開いたままにします。
アプリケーションアーキテクト：機能ドメイン（「損益分析」など）をアプリケーション（「ポートフォリオプロセッサ」、「ランチャー」、「ディスパッチャ」など）に分割します。 "、" gui "）。 コーディングする必要はありませんが、明確なアイデアを得るには、元のコーダーである必要があります彼らのアーキテクチャが対処しなければならない技術的課題の。彼らの主なスキルはコーディングではなく、適切なソリューションを選択するために技術的な同僚の話を聞くことです。次に、実装（コーディング）する必要のある技術的実装を生成します。
テクニカルアーキテクト：テクニカルフレームワーク（KPI、ロギング、例外管理などの機能プロジェクトに一般的なもの）の選択および/または実装を担当します）、そしてそれらは絶対にコード化する必要があります（そしてうまくコード化する）、なぜならそれらのコンポーネントはによって使用されるからです他のすべての機能チーム。
開発アーキテクト（ねえ、 それは私です ;））：開発ツールとプロセス、および技術調査を担当します、彼らはコーディングし、コーディングを愛する必要があります。
したがって、答えは1つだけではないと思います。それは、アーキテクチャの分野と専門知識によって異なります。「アプリケーションアーキテクト」に関しては、後者の3つのカテゴリでコーディングの経験が異なる可能性があると思います...
建築の役割は変わりつつあると思います。ウォーターフォールプロセスで実装する低プログラマー向けのシステム全体を設計するアイボリータワーアーキテクトはますます少なくなっています。
反復的なプロジェクトを行う場合、アーキテクトとプログラマーの間のコミュニケーションがより重要になります。アーキテクトはチームの一員であり、プログラマーと一緒に変化する要件や新しいアイデアを処理できる必要があります。このような状況では、建築家とプログラマーの仕事はより密接に関連しています。開発リーダーがアーキテクトの役割を引き受けたチームが、非常に複雑なソリューションのためによく考えられたアーキテクチャを提供するのを見てきました。
編集コメントへの返信
アプリケーション、ソリューション、エンタープライズアーキテクトの違いは少し人工的であり、多くの場合実際には適合しないと思います。セキュリティアーキテクト、データアーキテクトなどの役割は、責任をはるかに明確に区別します。詳細については、こちらをご覧ください http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm
ちなみに、あなたの質問をもう一度読んでみると、コーディングアーキテクトに対する議論の多くは、アーキテクトの強力な管理/リーダーシップの役割を示しているように見えることに気づきました。管理とアーキテクチャの役割を分離することは良い考えだと思います。管理とアーキテクチャの間よりも、技術担当者にコーディングとアーキテクチャの間で時間を分けてもらう方がよいでしょう。
はい。何年もコードを書いていなかったソフトウェアアーキテクトは、製品を構築する現実に触れることができなくなります。彼らは、これまで以上に高いレベルの抽象化を備えた壮大なデザインの制作を開始し、出荷日を遅らせ続けているようです。
私が取り組んできたすべてのプロジェクトには、コードを実際に操作するのにかなりの時間を費やさなかったアーキテクトが含まれており、実践的な知識がないために問題が発生しました。
それは私がその建築家だったプロジェクトを含みます:-)
今では個人的な大きな赤い旗になっています。
私は、コーディングするアーキテクトを支持するすべての議論に同意します。反対の議論は私にとってうまく結びついていない。
コードは、アプリケーションの低レベルだけでなく高レベルの概念も抽象化する必要があります。設計とコードがすべてのレベルで統合されていない限り、ソリューションは最適とは言えません。
「コーディングは、リスク管理、アーキテクチャの広い視野の性質と対立する詳細志向のヘッドダウン機能です」-私の経験では、広い視野-そして特にリスク管理-は、より良いコーダーを悪化させません:-)
「アーキテクチャは技術的なリスク管理に関するものであり、実装ではありません」-そうではありません。それはリスク管理についてですそして実装（そして他のたくさんのもの）。
「アーキテクチャはリーダーシップに関するものです。後ろからリードするのは難しいです」-なぜコーディングがあなたを後ろに置くのですか？個人的には、リードするのに最適な場所は、一緒に仕事をしている人々と一緒だと思います。
私（私は）は建築家です。コーディングはこの仕事を楽しくするものです。
次に、アイデアが実現し、デザインが機能していること、デザインのエラーを確認できます（とにかく遅すぎますが、次回は...）
はい、コーディング経験を維持するためです。
アーキテクトとITストラテジストがいます。複数の部門にまたがる500人が関与する統合プロジェクトを主導している場合は、いいえ、邪魔になります。開発プロジェクトで最大数十人の設計と実装を主導しているのであれば、そうです。そうしないと、アーキテクチャを操作する際の日常の現実について適切な洞察を得る可能性がはるかに低くなります。
アプリケーションのすべてをコーディングする必要はないと思います。しかし、彼らはいくつかのタスクを与えられるべきです。一部の「アーキテクト」は、基本的に技術的な経験のないハックであり、「伝説的なコーダー」として名を馳せ、アーキテクチャがなかった場合に必要だった作業量に数週間または数か月を追加するシステムを設計します。コードを記述できない場合、その役割を担うビジネスはありません...アイデアはアーキテクチャであるため、アプリケーションの開発と保守が容易になるはずです。しかし、建築家が開発できない場合、彼または彼女はどのようにして建築を作る方法を知っているでしょうか？
また、最高の建築家でさえ悪い決断をします。ホワイトボード上で何かが見栄えがする場合もありますが、実際には、アーキテクチャ上の決定により、物事が本来よりもはるかに困難になります。アーキテクトが自分のドッグフードを食べなければならない（そしてアーキテクチャを使用しなければならない）場合、彼らは悪い決定を修正したり、それらを回避する方法を設計したりする傾向があります。また、コードに触れることで、彼らは少なくとも少しはそれに精通しています。したがって、開発者がコーディングの問題で彼らに来た場合、アーキテクトは開発者を解雇し、開発者が間違っていると言っても、それを行う正しい方法についての洞察を提供しないので、アーキテクトの目は釉薬をかけません。
アーキテクトは、コードベース内で大きなプロジェクトを行う必要はありません。ただし、少なくとも、コードベース内で独自のアーキテクチャを使用するように強制する小さなタスクを実行する必要があります。また、小さなタスクでは、他の多くの人のコードを読んで、人々がアーキテクチャをどのように使用しているか、そしてアーキテクチャを改善するために何かできるかどうかを理解する必要があります。
Vlionが述べたように、開発者が圧倒的に多いコミュニティでこの質問をすることは、答えが「はい」に偏ることを意味します。
役職に「建築家」がいるが、最近「Distinguished Engineer」のバッジも授与された人として、私の忠誠心は破れています。一般的に、コーディングは建築家の時間を有効に活用することではないと思います。だから私は何をすべきですか？
- ビジネスを理解する。
- ビジネスを可能にするために使用されるシステムを理解する。
- IT戦略と戦術についてビジネスと協力する。
- 現在のプロジェクトが長期的な視点で行われていることを確認します。プロジェクトマネージャーは短期的な視点に集中します。
では、建築家はどのように現実と連絡を取り合うべきでしょうか？定期的な会議やウォークアラウンドで、あらゆるレベルの人々と話し、コミュニケーションの輪に油を注ぐだけだと思います。
多くの場合、「実装の詳細」は詳細ではないと信じるようになりました（特定の実装の問題を、「アーキテクチャ」の観点から細目として無視できる単なる詳細と見なすと、多くの問題が発生するという意味で） ）
アプリケーションアーキテクトは、アプリケーションアーキテクチャを定義し、アプリケーションを設計し、パターンを実装し、他のコードを指導できる必要があります。あなたがそれらのことをすることができないならば、あなたはアプリケーションアーキテクトではありません。
インターフェイスを書くだけでコードとしてカウントされますか？もしそうなら、これは私がアーキテクトに期待する最小のものですが、他の場合には、メソッドのスタブを持つクラスなど、アーキテクトからのコードがはるかに多い可能性があります。
アーキテクチャは、ソフトウェア開発者にとってコアスキルです。アーキテクトがコーディングしないことが理にかなっているというまれな機会がいくつかあるかもしれませんが、私自身の経験でそのような機会に遭遇したことは思い出せません。
アーキテクトは、プロジェクトでコーディングするか、最低限、プロジェクトで完全にコーディングできる必要があります。これの2番目の部分は、チームの他のメンバーが使用しているツールと手法を使用してコーディングできる必要があることを意味します。 （コーディングを継続しないと、これらのスキルを維持することは非常に困難になるはずです。）
最後に、アーキテクトが他の人が使用するツールや手法を選択する責任がある場合、提案されたツールを実際に使用しないと、そのような選択をうまく行うことはできません。このシナリオでは、ノンコーディングアーキテクトは、机の上にパンフレットの山を持った先のとがった髪のボスに急速に退化します。
時々、彼らはコーディングしなければなりません。たとえば、チームが1人だけの場合です。
私の意見では、彼らは必要に応じてコーディングできますが、全体像を失ってはなりません。設計された構造を毎日変更することはできません。
あなたはコーディングサイトでこれを求めています。基本的に、全員が「はい」の側に倒れることになります。
私の見解は、はい、しかし変化するニーズに追いつくのに十分であり、それ以上ではありません
アーキテクチャは高レベルの役割であり、実装について心配する必要はありません>詳細
コードはデザインです。かわいらしい建物を設計しているが、合流地点、配管、電気、エレベーター、建物の法的な問題をどこに置くかなど、実装の詳細に立ち入ることを拒否している建築家を想像してみてください。
* Coding is a detailed oriented, heads-down funtion which is at oddsリスク管理、アーキテクチャの広い視野の性質
コーディングするときは、最初に詳細に焦点を合わせます。次に、より広い焦点でリファクタリングします。
アーキテクチャはリーダーシップに関するものです。後ろからリードするのは難しい
ソフトウェア開発の最前線はコーディングです。プロダクトマネージャーであるか、プロジェクトマネージャーがコーディングしていない可能性があります。しかし、建築家はそれをする必要があります。彼はコードがどれほど優れているかを示すためにリファクタリングにもっと時間を費やすべきかもしれません。このように彼は模範を示します。
コーディングに取って代わることができるコードレビューやペアプログラミングについて誰も言及していないのはなぜだろうか。
私はコーディングよりも、コードを読んだり、同僚との問題を解決したりすることに多くの時間を費やしています。これにより、コード、その構造、および複雑さについて、自分で作成するのとほぼ同じように理解でき、時間も大幅に短縮されます。私がコーディングするとき、私は楽しみのために、または新しいテクノロジーを探求するためにそれを行います（これは私がコーディングが役立つと思った唯一の場所です）。
この標準的な開発者の答えは、アーキテクトもコーディングする必要があるというものです。しかし、それはテクノロジーを最優先する一種の開発者です。しかし、私は反対する傾向があります。はい、コードをレビューできるようにするために、いくつかのコーディングスキルを持っていることは有益です。
しかし、アーキテクトが行う唯一のことは、ビジネス要件と実装をまとめることです。そして私たちの場合、コード。非常に複雑なシステムを使用している場合、アーキテクチャのコーディングと実行を同時に行うことはできません。これは、非常に多くの異なる抽象化レベルで操作しているためです。
代わりに、開発者に頼ることができるはずです。彼らは、実装の側面と、それがあなたが彼らに指摘したビジネス要件にどのように適合するかを説明できるはずです。選択されるテクノロジーはアーキテクトの決定ですが、その決定に至るには、彼は調査を行うか、過去の経験を使用する必要があります。それは、彼が開発者と話をしたり、特定のテクノロジーを調査してアーキテクチャが実際に機能するかどうかを確認したりしないという意味ではありません。
トピックから逸脱するリスクに...
大規模なアプリケーションでは、アーキテクトが記述されているコードを最新の状態に保つことができない場合があります。また、他の重要な責任があるため、彼がコードを書くことはできません。そうは言っても、アーキテクトは開発中のコードベースの全体像を失うべきではないことをお勧めします。これは、コードカバレッジ、コード品質に関するメトリック、静的コード分析などについてコードベースを監視することで実現できます。彼は、前述の基準を使用してコード品質を定期的に評価する必要があります。 「継続的インテグレーション」の実践はここで役立ちます。
ここの誰もがコーダーなので、お気に入りは地獄でなければなりません-ええ答え-そしてあなたは私から意見の相違を得ることができません。
しかし、 きめ細かい答え は、ドメインの専門知識を適切に評価しているため、私の意見ではより正確です。ちょっとした試合のソフトウェアを知っているが、それを使うだけの人はとても価値があります。
アーキテクチャの役割がどのように分割されるかは、組織の規模と性質に依存しているようです。
もし私がそれを自分のやり方で持っていれば、クライアントが優れた、有用で、詳細なストーリーとユースケースを書いたら、ストーリーアーキテクトの役割をクライアントに与えるでしょう。