泥の大きな塊

こんにちは、Habr！ ブライアン・フットとジョセフ・ヨーダーの記事「 泥の大玉 」の翻訳を紹介します。



翻訳者から：1999年の夏にブライアン・フットとジョセフ・ヨーダーが「泥の大玉」の記事を書いた。 彼女は、ソフトウェア開発の最も一般的なアンチパターン、それらの発生と開発の理由について話しています。 刊行から18年以上が経過しているにもかかわらず、記載されている問題は消えていないため、執筆の大部分は今日に関連しています。 これは3つの記事の最初の部分であり、残りは近い将来に投稿したいと考えています。

はじめに

近年、数人の著者が一度に[Garlan and Shaw、1993] [Shaw、1996] [Buschmann and others、1996] [Meszaros、1997]により、PIPELINE（パイプライン）やLAYERED ARCHITECTURE（マルチレベルアーキテクチャ）。



理想的な世界では、すべてのシステムが1つ以上の同様の高レベルパターンの例になります。 ただし、実際にはそうではありません。 現在支配的なアーキテクチャはまだ議論されていません。 これは、泥の大きなボールまたは大きな汚れです。



LARGE DIRT LOCKは不注意に設計された構造をしており、むち打ちで生であり、まるでホイップテープとワイヤー、ジャングルに絡まっているスパゲッティコードのようです。 私たちは皆、そのようなコードを見ました。 これらのシステムでは、無秩序な成長と継続的なやり直しの兆候を簡単に見つけることができます。 情報はシステムのリモート要素間で無差別に配信され、多くの場合、重要な情報はすべてグローバルまたは複製されます。 システム全体の構造が正確に決定されたことはありません。 存在する場合、オリジナルが認識できなくなるほど破壊されました。 アーキテクチャを少し理解しているプログラマは、この沼地を迂回します。 そして、彼女があまり気にかけていない人、そしておそらく、毎日システムに穴を埋めたい人だけが、そのようなシステムの仕事に満足しています。



それがそうであっても、このアプローチは生き続け、繁栄します。 このアーキテクチャはなぜそんなに人気があるのですか？ 彼女は彼女のように悪いですか？ または、より信頼性の高いエレガントな代替品への道の中間駅として機能できますか？ 優れたプログラマーがこのようないシステムを作成する理由は何ですか？ これを回避できますか？ そしてそれは必要ですか？ これらのシステムをどのように改善できますか？



この記事では、次の7つのパターンを示します。

• BIG BALL OF MUD（汚れの大きな塊）
• スローアウェイコード（1つのコード）
• 粒成長
• KEEP IT WORKING（LET WORKS）
• せん断層
• 敷物の下で掃除する
• 再建

システムがなぜダートの大きな塊に変わるのですか？ ワンタイムコード（THROWAWAY CODE）の作成により、大きくて恐ろしいシステムが現れることがあります。 ワンタイムコードは、コードのドラフトバージョンであり、一度だけ使用してから破棄する必要があります。 ただし、そのようなコードは、未開発の構造、不十分な設計のドキュメント、または不在にもかかわらず、独自の生活を送り始めることがあります。 それは動作します、なぜ何かを修復するのですか？ 問題が発生した場合、それを解決する最速の方法は、作業コードを変更することです。 これにより、プログラムを最初から作成する必要がなくなりますが、時間の経過とともに、単純な1回限りのプログラムで大規模なダートが発生します。



明確に定義されたアーキテクチャを備えたシステムでさえ、崩壊のリスクを抱えています。 成功するシステムは、常に変化する要件の影響下にあり、その構造が徐々に損なわれます。 クリーンなシステムは、構造の段階的な成長（PIECEMEAL GROWTH）により大きくなり、システム要素は制御不能に成長し始めます。

この成長が止まらない場合、システムの構造は、放棄しなければならないほど乱れています。 減少している都市のエリアの場合のように、この状況は増加することにより悪化します。 システムの理解が難しくなるにつれて、そのサポートはより複雑になり、より高価になります。 優れたプログラマーは、そのような構造での作業を拒否します。 投資家は資本を引き出します。 さらにもう1つ、都市部と比較することができます。この低下を回避し、さらには逆転させる方法があります。 私たちの世界のあらゆるものと同様に、反対のエントロピー力にはエネルギー入力が必要です。 ソフトウェアのジェントリフィケーションも例外ではありません。 ソフトウェアでエントロピーを停止する1つの方法は、再設計することです（屈折器）。 定期的なリファクタリングへの取り組みにより、システムが大規模なダートに陥るのを防ぐことができます。



深刻な洪水、火災、または敵対行為により、住民の避難と都市のゼロからの再建が必要になる場合があります。 多くの場合、変更は個々の建物または地区に影響し、都市自体が機能し続けます。 一度確立されたKEEPING IT WORKING戦略は、都市の成長と再開発の間、都市の生活を守ります。



システムとその構成要素はさまざまな速度で進化します。 より速く変化したシステムと要素は、ゆっくりと変化しているシステムと要素とは異なります。 それらの間に形成されるシフトされた層（せん断層）は、障害の境界または線に似ており、長期間持続する抽象的なシステム構造の出現に貢献します。



衰退を制御し始める簡単な方法は、スラム街を囲み、その周りに美しいファサードを設置することです。 この戦略を「敷物の下で掃く」と呼びます。 より深刻なケースでは、代替案を見つけるのが難しいため、全員が解体し、ゼロから新規に建設を開始します。 完全な再構築が必要な場合（RECONSTRUCTION）、保存されるのは基礎となるパターンのみです。



一見、これらはアンチパターン[Brown and others、1998]または偽パターンのように見えるかもしれませんが、少なくとも通常の意味ではそうではありません。 実際、これらのアプローチは、私たちが説教することと実践することの間のギャップを埋めます。 それでも、これらのパターンを疑う読者もいます。 したがって、すべてのカードをテーブルに置き、自分の位置を宣言するのが賢明です。 私たちは優れた建築を目指しています。



私たちの主な仕事は、これらの沼地の排水を支援することです。 可能であれば、建築の衰退を防止、停止、または逆転させなければなりません。 これを行う方法を示します。 最も高度なケースでは、いくつかのアーキテクチャの倒錯を削除する必要があります。



同時に、この泥沼に引き込まれた人々を非難するつもりはありません。 そのような人々に対する私たちの態度は、「私たちは罪に反対していますが、罪人ではありません。 問題はさらに深い。 すべての裏庭に大理石の柱を立てる必要はありません。 団結してアーキテクチャをバックグラウンドに引き込み、機能的なタスクのみを実行できる強力な力があります。 特にソフトウェア開発の初期段階。 アーキテクチャを開発する機会と理解は、ほとんどの場合、ソフトウェアライフサイクルの後の段階ですでに現れています。



制御されたカオスは、合理的な範囲で、建設中の自然なプロセスであり、すべてが後で修正されれば、これに同意することができます。 ただし、複雑なシステムは、問題を未熟に理解していることの信頼できる反映であることに注意してください。 原則として構築できるシステムのクラスは、少なくとも最初の段階で優雅に構築できるシステムのクラスよりもはるかに大きいです。 老朽化した複雑なアーキテクチャは、あまり理解されていないドメイン（知識のドメイン）の芸術作品になる可能性があります。 しかし、話はそこで終わりではありません。 そのようなドメインでの作業の経験を積むと、より多くのエネルギーを導き、部分的に正しいアーキテクチャの抽象化を収集できるようになります。



ここで説明するパターンは、互いに別個に考慮されることはありません。 それらを単一のコンテキストに結合しました。このコンテキストには、私たちや他の著者によって記述された他のパターンもあります。 特に、[Foote and Opdyke、1995]および[Coplien、1995]で説明されているライフサイクルパターン、プロトタイピングフェーズ（プロトタイプフェーズ）、拡張フェーズ（拡張フェーズ）、および統合フェーズ（統合フェーズ）と比較します。 また、ソフトウェアテクトニクスパターン（SOFTWARE TECTONICS）[Foote and Yoder、1996]および構造設計パターン[Roberts and Johnson、1998]と比較してください。



この章では、主に病気について説明しましたが、上記のパターンはすべて、この病気の治療法になると考えています。 つまり、フィードバックを備えた柔軟で適応性のある開発プロセス。設計およびリファクタリングは、アプリケーション内およびそれ以降の各アーティファクト、コンポーネント、および構造のライフサイクルに適用されます。

力

多くの力が、きちんとしたアーキテクチャを持つ組織でさえ大規模な泥の塊を作り始めるという事実に貢献しています。 これらの遍在する「グローバル」な力は、前述のすべてのパターンに影響します。 これらの力の中で、以下を区別します。



時間 ：特定の設計または決定の長期的なアーキテクチャの結果をすべて分析するのに十分な時間はありません。 システムの構造が優れていても、アーキテクチャの問題はより実用的な側面に取って代わります。



ソフトウェアアーキテクチャが平凡であることが多い理由の1つは、コスト、アイデアから実装までの時間、プログラマのスキルなど、現在の問題に取って代わることです。 多くの場合、建築は贅沢品や無駄なものと見なされます。 建築はしばしば無視され、無視されさえします。 もちろん、建築に対するそのような態度が発達したのは悪いことですが、これは理解できます。 アーキテクチャは、継続的な注意が必要な領域です。 開発中の製品が成功し、有望であることを望む場合、まず第一に、上で書いたより差し迫った問題に対処する必要があります。 また、優れたアーキテクチャの利点は、製品がすでに完全に形成され、再利用可能なコンポーネントが出現するライフサイクルの後期に現れます[Foot and Opdyke、1995]。



アーキテクチャは、市場の要件を満たすことを目的としたリソースを消費するリスクと見なすことができます。 または、さらに有利な基盤を築く機会として。



未熟なアーキテクチャは、進化するシステムの利点になります。データと機能は、人為的なアーキテクチャの制約を受けないシステムで自然な位置を占めることができるからです。 未熟な、性急なアーキテクチャは、アーキテクチャの欠如よりも大きな危険を伴います。なぜなら、実証されていないアーキテクチャの仮説は、アーキテクチャのさらなる発展を妨げる足etterに変わるからです。



コスト ：特に新しいエリアを探索する場合、アーキテクチャは高価です。 システムが既に機能している場合、適切なアーキテクチャを設計することは無意味な贅沢のようです。 開発への投資は通常、すぐには正当化されません。 さらに、製品を市場に出すまでに長い遅延が生じる可能性があります。 建築への投資から利益を得るのは誰ですか？また、いつ投資収益率を期待できますか？ すぐに市場に投入できる迅速で「生の」プロジェクトの資金は、より簡単に使用されます。 複雑なアーキテクチャの開発と分析のための資金は、あまり望みなく投資されます。 すでに倒産した場合、建築資産の費用を回収することは困難です。



自分で高品質のアーキテクチャを理解し、開発できるプログラマは、高価なスペシャリストとしての評判があります。 プログラマの作業のコストは、高価なシステムが時期尚早に衰退して道徳的に陳腐化した場合に発生するコストと比較して推定する必要があります。 良いアーキテクチャが高価だと思うなら、悪いアーキテクチャを試してください。



経験 ：人が時間とアーキテクチャの問題に取り組む意欲がある場合でも、特定の分野での彼の経験または経験の欠如は、特にシステム開発の初期段階でシステムに導入される可能性のあるアーキテクチャ上の困難を制限できます。 一部のプログラマーは、新しい抽象概念を発見して開発できる環境で成功しますが、他のプログラマーは、より限られた環境（Smalltalk対Visual Basicなど）で快適な作業を好みます。 多くの場合、システムの初期バージョンは、特定の問題を解決するためにプログラマーがさまざまな要素を導入しようとする一種の実験ツールです。 そして、問題とその解決策が見つかった場合にのみ、これらの埋め込み要素間にアーキテクチャの境界が現れ始めます。 経験不足にはさまざまな形があります。 卒業生の絶対的な未経験があります。 優れたアーキテクトは、特定の分野での経験がなくても、コードを完全に知っている特定の分野の専門家でなくても、アーキテクチャの開発経験がない場合があります。



スタッフの離職は組織の組織の記憶を損なう可能性があり、疑わしい妥協策として、組織に「新鮮な血」を注ぐ必要があります。 ボスを変更すると、それぞれが好みに合わせて材料を追加するため、皿全体が台無しになります。



スキル ：プログラマーは、異なるレベルのスキル、異なる専門能力、気質、気質を持っています。 優れた抽象化を熱心に検索するプログラマーもいれば、前任者が残した複雑なコードの世界に精通しているプログラマーもいます。 彼らは、知識のさまざまな分野への精通度と、新しい技術を学ぶ能力が大きく異なります。 さらに、言語とツールの使用に関して異なる設定があります。



可視性：建物は具体的な物理構造です。 建物自体を見ることができます。 建物の建設を観察できます。 あなたは中に入り、デザインを賞賛または批判することができます。



プログラムのユーザーインターフェイスは、そのアーキテクチャが建物の外部に組み込まれているように、プログラムのパブリックイメージです。 ただし、建物とは異なり、プログラムを作成した人だけがプログラムの内部を見ることができます。



プログラムは個々の要素で構成されています。 プログラムに対する私たちの認識は、これらの要素がどのように提示されるかに依存します。 一部のデザイナーは、モデリング言語またはPowerPointイメージを使用することを好みます。 通常の説明のような他の人。 また、コードを見たい人もいます。 アーキテクチャを提示する方法は、このアーキテクチャの認識に影響を与えます。それが良いか悪いか、明確か複雑か、エレガントか汚いかなどです。



実際、アーキテクチャを無視する理由の1つは、そのほとんどがmost索好きな目から隠されていることです。 システムが機能し、インストールできる場合、誰が内部からの外観を気にしますか？



複雑さ ：ダーティアーキテクチャが出現する理由の1つは、アプリケーションが実行される領域の複雑さがソフトウェアに反映されることが多いことです。 ブルックスは、この現象の用語「固有の複雑さ」を作り出しました[Brooks、1995]。 言い換えれば、問題自体も理解されていないか、少なくとも完全には理解されていないため、ソフトウェアは複雑で理解不能になります。 多くの場合、システムの組織は、このシステムを作成した組織の歴史を反映しています（CONVEY LAW [Coplien、1995]に準拠）。 システムの要素間で基本的な境界が既に確立されているため、既存の関係を再考することはしばしば困難です。 これらの関係は、実際の都市で見られる「地区」境界の特徴を帯びることがあります[Brand、1994]。 アプリケーションがこれらの境界を超えた自由な対話を必要とする場合、大きな問題が発生します。 システムはもつれたボールに変わり、最初にあった構造の残骸でさえ、ますます劣化し始めます。



変更 ：アーキテクチャは、その後の変更はアーキテクチャがまたがるプロジェクト空間の一部に限定されるという、未来に関する仮説です。 もちろん、宇宙はそのような仮定と予測をしようとする私たちの試みに笑いかけ、完全に予想外の何かを投げかけます。 私たちが知ることができる問題は私たちの注意から完全に除外されましたが、突然、それは私たちが一緒に働くとは思わなかった新しいクライアントにとって非常に重要であることが判明しました。 そのような変更は、そのような新しい不測の事態が決して起こらないという完全な確信に照らして採用された基本的なアーキテクチャ上の決定とは正反対になります。 「正しい」決定は、システムの完全な再設計かもしれません。 しかし、最も可能性の高い結果は、新しい要件を満たすためにシステムのアーキテクチャが適切に違反されることです。



規模 ：大規模プロジェクトの管理は、小規模プロジェクトでの作業とは異なり、質的に異なる問題です。 これは歩兵部隊全体を戦闘に導き、特殊部隊の小さな分隊を指揮する方法です。 「分割して征服する」-これは、本質的に、規模によって引き起こされる問題に対する必要かつ不十分な解決策です。 OOPSLA '86でのスピーチでアランケイは、「良いアイデアは必ずしも拡大縮小するとは限りません」と述べました。 この観察は、ヘンリーリーバーマンからの反応を引き起こしました。彼は「つまり、悪いアイデアを拡大する必要があるのか​​」と尋ねました。

大口径

彼は

スラム街

スパゲッティコード



スラム街は不気味で乱雑で貧しい地域です。 おそらく誰もが彼らには良いものがないことに同意するでしょうが、スラムの出現に寄与する客観的な理由があります。 彼らは何に関連していますか？



スラム住宅は、通常、最も単純なツールを使用して、シンプルで安価な材料から構築されます。 スラムは、比較的未熟な労働力を使用して構築できます。 また、通常の意味では労働力は「未熟」ですが、スラム街の建物の建設と維持は労働集約的なプロセスになります。 専門化は実際には必要ありません。 家は主に居住者自身によって建てられ、改修されています。 インフラストラクチャーは、アクション、資本、特別なリソース、特別な機器、スキルの調整を調整する必要があるため、スラム街はインフラストラクチャーを気にしません。 スラムの成長を計画または制御することも事実上存在しません。 スラム街は、住宅の必要性、未熟練労働者の過剰供給、および設備投資の不足がある場所に現れます。 彼らは住宅の差し迫った地元のニーズを満たし、問題を解決するために利用可能な資源を集めています。 より洗練されたアーキテクチャのアプローチは、待つことができる贅沢です。



スラムを労働条件に維持することは労働集約的なプロセスであり、多くのスキルが必要です。 即席の修理を行うことができ、即席の素材のみが利用可能でなければなりません。 屋根を修理し、衛生状態を提供できる必要があります。 ただし、成熟した経済で観察できる資格は実質的にありません。

アーキテクチャの観点から見ると、今日のソフトウェアシステムは多すぎて、このようなスラムに似ています。 多くの場合、ツールとインフラストラクチャへの投資では不十分です。 ツールは通常原始的であり、ライブラリや環境などのインフラストラクチャは未開発です。 システムの個々の部分は検証なしで開発され、インフラストラクチャとアーキテクチャの欠如により、システムの一部の問題が悪化し、システムの隣接する部分に感染します。 システムの完成期限は近づいているため、建築の優雅さを達成することは不可能に思えます。



システムの開発が近づいているとき、実際のユーザーは初めてこのシステムで作業を開始できます。 , , , . , Brooks [Brooks, 1995], , / , - .



. Stewart Brand [Brand, 1994] , , , , . , , . , , . .



, , , . , , , , . , .



.



: — . , , , , , ; . . , . , , , . , , , .



: (Ralph Johnson) , « , ». , , -.



: , , , , , .



, — “ ”, — , . , , .



, , .



(Gabriel) « , » [Gabriel, 1991]. , ? « » ? ?



, ? . . .



, [Buschman, 1996], , , . , , , .



. , . . . . . . , , , , . ? ?



-, , , , . , . , . , , , . , , .



, — , « ». , , . , , .



(Kent Beck) : . . . [Beck, 1997]. « » , , . « » , , , , . « » , , , , . , , .



, , . «» «» . , , , .



— . , , . , — , .



. , , .



, . , , , . , . , , , . [Coplien, 1995], , , . [Foote Yoder, 1998a] , , . , . .



, , , , . , , , . , , . , , .



, . , . . . , .

, , . , . , . . . , .



, , . . . .



« » , , .



, , , — , , , . , , , . , , [Foote Opdyke, 1995]. (PROTOTYPE) (EXPANSION) . , , , “ ”. , , , , .



(Brian Marick) BIG BALL OF MUD ( ) . , , , , . , . 1970- (Lisp).

(THROWAWAY CODE), , ( « »).



(PIECEMEAL GROWTH) . , — « » (KEEP IT WORKING). (SHEARING LAYERS), , , (BIG BALL OF MUD).



[Foote Opdyke, 1995] , , .



, , (CONSOLIDATION PHASES) [Foote Opdyke, 1995], . (Extreme Programming) [Beck, 2000] .



[Brand, 1994] , , , , . , . (FREEDOM FROM CHOICE) [Foote, 1988] — , .



— . , , . — , , .



— [Beck, 2000]. , , . , . , .



, : . , , . . , , , , .



, . , , .



, , , . -. , .



. — . . . — . (RECONSTRUCTION) , . — .



[Vitruvius, 20 ..], : firmitas ( ), utilitas (), venustas (). . , . , , , .



2



オリジナル記事