優れたソフトウェアアーキテクチャとは何ですか？

Question

私の質問はあまりにも正確ではありませんが、いくつかの背景情報を教えてください。

去年、私はうまくいくと思ったソフトウェアマネージャーとして新しい仕事を得ました。私はGUI、Web、RIA、ネットワークアプリケーションのような多くの異なるプログラミングドメインで経験しています。私は良い問題解決者です。一般的に私はコードをきれいに整理する方法を知っています。そして、私はいつも努力しています。

しかし、ほぼ1年後、私の上司は本当に自分の仕事について動揺していることを認めなければなりません。最も重要な理由は、私の製品のソフトウェアソリューションが十分に進んでいないと感じているということです。 私は精巧にシステムを分解したと思う、私は各コ​​ンポーネントのための最も一般的なプラットフォームを選択し、コードのほとんどは堅牢できれいです。

私の上司はそうは思わない。彼は本当に私たちがもっとうまくいくと感じています。彼は良いだけでなく優秀なものを求めています。ほぼ究極のスケーラビリティを備えたもの、拡張が非常に非常に簡単なもの、素晴らしいコンセプトとアイデアがあります。

これは私が一度も会ったことのないチャレンジです。私の上司に現行のシステムを十分に示す方法を知らない。私は彼に "私たちはxxx、yyyを使う"と言ったが、彼らは何であるか分からない。私は彼に、私たちが何をしたのかを説明するためにUMLを示しましたが、彼はCの超楽しさであり、OOとUMLに懐疑的です。

あなたは素晴らしい、優れていると非常に簡単に感じるいくつかのソフトウェアアーキテクトを見たことがありますか？優れたソフトウェア・アーキテクチャーが何を意味するのかを実際に見ておく必要があると思います。

まだ存在しないいくつかの要件に備えるためにアーキテクチャを構築する価値があるのか​​どうか本当に疑問ですが、私の上司は自分の仕事を幸せにしなければなりません。

Answer 1

これは技術的な問題ではないと思われます。あなたのマネージャーはソフトウェアアーキテクチャーを本当に理解していないと思うかもしれません。

あなたの仕事はあなたの上司にあなたのアーキテクチャを販売し、彼（または彼ら）の期待を管理することです。あなたの上司があなたのソリューションがセクシーではない、または十分なスケーラビリティを持っていないと懸念している場合、あなたはその関係を十分に管理していない可能性があります。

あなたは何が起こっていない可能性がありますかのために構築しないことはかなり正しいと思います。あなたはそれをして狂って行くことができます。すべてを予期することはできません。

Answer 2

あなたの上司がOOの懐疑的な人であることを考慮すると、私はレゴでアプリケーションを再構築することをお勧めします。彼はそれが「優秀」とみなすと確信しています。

Answer 3

完璧なアーキテクチャは漸近的です。あなたはそれを目指すことはできますが、決してそれには到達できませんあなたのソフトウェアに適していて、あなたが今必要としていることを行い、将来のニーズに対応するのに十分な弾力性を持たせることができれば、あなたにとっては完璧です。

Answer 4

あなたの上司のSchlossnagleの本はScalable Internet Architecturesで購入してください。それで、あなたは "私たちの製品は"とは言えません。

あなたは上司が「上級者」とは何を意味するのかを知る必要があります。あなたの上司が望むこの「高度な」ものをもっと提供するために何かをしてください。あなたの上司が求めるすべてのことをやってはいけませんが、がのように見えるようにしてください。それが意味するものは何でも。

Answer 5

"優れた"アーキテクチャは非常に主観的なことです。アーキテクチャは優れているか、プロジェクトの目標に基づいていません。

各プロジェクトは、要件に応じて、異なる理想的なアーキテクチャを持つ可能性があります。これには多くのことがありますが、ほとんど常に有効な基本的なソフトウェアアーキテクチャの概念（懸念の分離など）がありますが、すべてのアプリケーションに適した「究極の」アーキテクチャはありません。

アプリケーションの機能は何ですか？
ビジネスと技術の両方の制約は何ですか？
どの程度の規模ですか？
このアプリケーションの予想寿命はどのくらいですか？

これらは、特定のアーキテクチャがアプリケーションに最適かどうかを判断するために必要な質問です。

---

私の提案はこれを回すことです。あなたの上司に、あなたのプロジェクトのアーキテクチャの目標は何ですか？あなたの現在のアーキテクチャーがどのようにそれらを満たしているか、またはそれを働かせるように適応させる。

Answer 6

デザインが「美しい」ということについては、決して何も同意しません。

事実と数字に議論を減らすためにベター：

• 不良率、平均欠陥までの時間解決、およびその他のさまざまな統計情報が提供された機能を測定する
• メトリックに（例えば行をコードの品質を検出しますCOCOMOのような広く受け入れられている業界モデルとの比較
• 一般的なモデルとの比較で、プロジェクトの市場投入時期を測定するための指標。

事実があなたの仕事をうまくやっているとすれば、あなたの上司は議論の余地がありません。あなたの上司が議論を主張しているなら、あなたはより良い上司が必要です（彼はおそらく、あなたが給料やそのようなものを得るのを妨害しようとしています）。

Answer 7

これまで、マイクロソフトは無料のポケットリファレンスといくつかのポケットリファレンスのためのApplication Architecture Guideをリリースしました。私はあなたとあなたの上司が一緒にそれらを読むべきだと思います。

• App Arch Guide
• Pocket Guides

Answer 8

私はGUI、ウェブ、 RIA、ネットワークアプリケーションのように、多くの異なる プログラミングドメインで経験しています。私は良い 問題ソルバーです。一般的に私は、きれいな方法でコードを整理する方法を知っています 。そして私は いつも頑張っています。

それは私にさえ疑いがあり、私はあなたの上司ではありません。本当に、あなたはあなたがそうであると思うようにGUIからアーキテクチャに至るまで、まったく異なる分野に熟達しているわけではありません。その意味は、あなたが設計したアーキテクチャーも、あなたが思うほど良くないということです。

は解決策になるかもしれないいくつかの不明確な卓越性を達成することではありませんが、

Answer 9

良いアーキテクチャを無視することを気づくか選んなかったいくつかの特定の障害を特定し、固定することは、ビジネスのニーズを満たすものです。

使用する良い原則の1つはYAGNIです。あなたはそれを必要としません。あなたが実際にそれを必要とするまで何かを構築しないでください。

Answer 10

優れたアーキテクチャは、問題のニーズに合ったアーキテクチャです。もしあなたがそれをしたら、あなたは良い仕事をしてきました。

Answer 11

あなたはソフトウェアマネージャーとして雇われていましたが、あなたはソフトウェアアーキテクチャーについて話しました。これは通常2つの異なるものです。ソフトウェア管理はプロセスと計画に関するもので、ソフトウェアアーキテクチャは設計に関するものです。同じ人の中には2つの異なるスキルがありますが、あなたの仕事の任務はそのプロフィールについて明確です。

Answer 12

「優秀な」アーキテクチャは、プロジェクトの種類と詳細に依存するため、可変です。

• 保守
• 拡張
• 可用性
• 効果
• スケーラビリティ
• 信頼
• テスト容易
• ユーザビリティ
：しかし、良いアーキテクチャは、主に、少なくともルール以下の適合すべきです210