はじめに
ソフトウェアアーキテクチャは、アーキテクチャの構築に少し似ています。 建物にはフラクタル構造もあります。建物はコンパートメントで構成され、コンパートメントは部屋で構成され、部屋は壁で構成され、壁はレンガで作られています。 一方、プログラムは、モジュールで構成され、モジュールで構成され、パッケージで構成され、モジュールで構成され、クラスで構成され、関数で構成されます。 しかし、プログラム構造の多様性は建物の多様性よりもはるかに広いため、ボブおじさんはソフトウェアアーキテクチャを建物のアーキテクチャよりも「より建築的」であると考えています。
さらに、毎日のように建物が表示され、プログラムのアーキテクチャはソースコード内に隠されているため、建物のアーキテクチャはソフトウェアよりも頭で視覚化する方が簡単です。 ソフトウェアアーキテクチャは、どのようなものでもありません。
一方、プログラムはパフォーマンス、メモリ、ネットワーク帯域幅などが制限された実際のハードウェアで実行されるため、ソフトウェアアーキテクチャは物理的な制限も覚えておく必要があります。
良いアーキテクチャとは何ですか？ これは、現在だけでなく、長期にわたって 、ユーザー、ビジネスオーナー、プログラマのニーズを満たすアーキテクチャです。
「良いアーキテクチャは高価だと思うなら、悪いものを試してください。」
「速く行く唯一の方法はうまくいくことです。」
まえがき
ボブおじさんは50年以上にわたってコードを書いてきました。 彼は、さまざまなプログラムを作成しました。大規模、小規模、GUI、コンソール、Webなどです。 そして、建築のルールはどこでも同じだという結論に達しました！ そして、鉄の生産性が大幅に向上したにもかかわらず、50年以上も変わっていません。
プログラミング言語も大幅に改善されましたが、基本的な構造は同じままです：if、代入、ループなど。 前世紀の中頃のプログラマーを最新のMacBookの背後に置くと、最初はおかしくなりますが、JavaコードをIdeaに記述するのは普通のことです。
しかし、半世紀以上も多くの経験を積んでおり、それはまだ50年前ではありませんでした。 規則は定式化されており、この本はこれに専念しています。
はじめに
作業プログラムの作成は簡単です。 プログラムを正しく書くのは難しいです。 これには知識、経験、スキルが必要であり、その開発には多くの時間と規律が必要です。
プログラムが正しく完了すると、プログラムの保守と変更が簡単になります。 欠陥の割合は非常に低いです。 大勢のプログラマー、要件のある大量のドキュメント、洗練されたトラッカーは必要ありません。
ユートピアに聞こえますが、ボブおじさんはなんとかそのようなプロジェクトに取り組むことができました。 しかし、残念なことに、ほとんどの場合、ひどい設計で作業する必要があります。
デザインとアーキテクチャとは何ですか？
設計とアーキテクチャが同一であると仮定しましょう。
アーキテクチャは上位レベルであるだけでなく、全体として上位レベルと下位レベルの詳細です。 もう一方のないものは存在しません。
ソフトウェアアーキテクチャの目標は、必要なシステムの構築と維持に必要な人的資源を最小限に抑えることです。
努力が小さく、 生涯にわたってそうであれば、設計は良好です。 リリースごとに労力が増えると、設計が悪くなります。
一例として、ボブおじさんは実際のプロジェクトのグラフを表示します。従業員の数は50倍増えましたが、コードの行数は2.3倍しか増えませんでした（3M-> 7M）。 より恐ろしいグラフは、1行のコードのコストが最大40倍増加することです。 つまり 生産性は100％からほぼゼロに低下しました。 プログラマは最善を尽くしますが、基本的には何もできません。 そして今最悪の事態：最初のリリースで従業員に月に数十万ドルを支払わなければならなかった場合、最終的にこの数字は月に2000万ドルになりました！
次に、ボブおじさんはウサギとカメのたとえを思い出します。 その中で、ウミガメは自信がありすぎて寝て、レース全体を通して寝ていたので、カメはレースに勝ちました。
開発に関しても同じことが言えます。プログラマーは、製品を迅速に展開し、後で秩序を取り戻すことができると自信を持って楽しんでいます。 ただし、問題は、リリース後に次の機能を実行する必要があることです。そうしないと、市場の競合他社に遅れをとることになります。 結局、数ヶ月で彼の生産性は単純にゼロに低下し、彼は失います。
次に、あるジェイソンゴーマンが行った実験の例を示します。そこでは、単純なプログラムを数回書いています。 そして、TDDを使用すると、TDDを使用しない場合は、初回の方が3回目よりも速いことがわかります。 つまり、正しく記述すれば、結果は速くなります。
開発者は、プロジェクトに導入する混乱について責任を負わなければなりません。 アーキテクチャの品質を真剣に考えなければなりません。 しかし、このためには、優れたアーキテクチャとは何かを知る必要があります。
2つの価値に関する物語
ふるまいとアーキテクチャの2つの値があります。
行動とは、プログラムが機能要件を満たしているため、ビジネスオーナーにお金をもたらすことを意味します。 問題は、多くのプログラマーがこれが彼らの仕事だと信じていることです。
2番目の値は、プログラムが維持された状態を維持する品質です。 つまり、変更は簡単です。 変更の複雑さは、それらの形式ではなく、これらの変更の規模に比例する必要があります。 アーキテクチャは、他のフォームよりもいくつかのフォームを優先するべきではありません。そうしないと、所有者のリクエストを毎回実装することがますます難しくなります。
より重要なのは、動作またはアーキテクチャですか？ 管理者は、システムが機能することがより重要であると考えています。 しかし、プログラマーは反対を考慮する必要があります。そのアーキテクチャはより重要です。
アイゼンハワーのマトリックスは、重要かつ非緊急の方が緊急かつ重要でないよりも優先度が高いと述べています。 また、アーキテクチャは動作とは対照的に常に重要であるため、より優先されます。
プログラマは、アーキテクチャのために戦わなければなりません。 プログラマーもビジネスのメンバーです。 建築は彼の責任です。
継続するには...