「大きな泥だんご」の版間の差分
読み仮名、リンク、カテゴリ |
|||
| 24行目: | 24行目: | ||
しかし、これらのコードは、このコードを書いた開発者自身か、もしくは、非常に[[再帰]]的なコードのレイヤーを理解するために時間を快く費やすことができる他の開発者のみが理解可能なものになる。 |
しかし、これらのコードは、このコードを書いた開発者自身か、もしくは、非常に[[再帰]]的なコードのレイヤーを理解するために時間を快く費やすことができる他の開発者のみが理解可能なものになる。 |
||
[[ジョエル・モーゼス]] は、1970年代に、以下のような独創的な書き方で名前が挙がった:<ref>{{Cite journal|author=[[Richard P. Gabriel]] and [[ガイ・スティール・ジュニア|Guy L. Steele]]|year=1996|title=The Evolution of Lisp|url=http://portal.acm.org/citation.cfm?id=154766.155373|journal=ACM History of programming languages—II|volume=28|issue=3|pages=233–330| |
[[ジョエル・モーゼス]] は、1970年代に、以下のような独創的な書き方で名前が挙がった:<ref>{{Cite journal|author=[[Richard P. Gabriel]] and [[ガイ・スティール・ジュニア|Guy L. Steele]]|year=1996|title=The Evolution of Lisp|url=http://portal.acm.org/citation.cfm?id=154766.155373|journal=ACM History of programming languages—II|volume=28|issue=3|pages=233–330|doi=10.1145/155360.155373}}</ref><blockquote class="">[[APL]] は美しいダイヤモンドのようなものだ - 欠けているところがなく、シンメトリーで構成されている。 しかし、あなたはこれに何も付けくわえることができない。あなたが、他のダイヤモンドをくっつけようとしたとしたとしても、より大きなダイアモンドは得られない。[[LISP|Lisp]] は大きな泥だんごのようなものだ。他の泥だんごを付け加えても、それは依然、泥だんごのままだ。</blockquote>Mose はこれを強く否定しており、常に元の形に戻ろうとする性質を指して、Lisp を [[ビーンバッグ]] と代わりに呼ぶことを主張している。<ref>{{Cite journal|author=Thomas J. Bergin and Richard J. Gibson|year=1996|title=Supplemental material from HOPL II|url=http://portal.acm.org/citation.cfm?id=1198155|journal=ACM SIGPLAN Notices|pages=9–20|doi=10.1145/240964.1198155}}</ref> |
||
== 参照 == |
== 参照 == |
||
2020年1月25日 (土) 16:06時点における版
大きな泥だんご (おおきなどろだんご、英: Big ball of mud) は理解可能なアーキテクチャが欠けている ソフトウェアシステム のことを指す。 ソフトウェア工学の視点から望ましくない状態にも関わらず、このようなシステムは事業の圧力、開発者の 刷新 や コードエントロピー などの理由によって当たり前に発生している、アンチパターン の1つである。
コンピュータプログラムにおいて
この用語は Brian Foote, Joseph Yoder らによって、1997年に同名の論文によって普及したもので、論文では以下のように定義された。
"大きな泥だんご" システムは、通常、長期間開発されたものであり、多様な部品から異なる個々人が開発して構成されたものである。 体型立てられた アーキテクチャ や プログラミング 研修を学んでいない人々によって構築されたシステムは、しばしばこのようなシステムになる。[献]
"大きな泥だんご" ソフトウェアを生むその他の原因は、マネージャが開発者に圧力をかけ、問題の解決のための明確な説明をする代わりに、増加分の部分的要求に基づいて、システムのコードの一部を書くように指示するような場合である。[献]
Foote と Yoder は、"大きな泥だんご" プログラムを一般的に非難しているわけではなく、少なくとも、それが開発された時に動作しているのであれば、このパターンは最も普及しているものであると指摘している。 しかし、そのようなプログラムはメンテナンスが非常に難しくなっていくものである。[献]
"大きな泥だんご" プロジェクトに置かれたプログラマーは、そのシステムについて学習したり、何が行われているのかを理解したり、このシステムを、形式的な要件を持ったルーズな基盤として、より良く設計された代替可能なシステムのために使ったり、という対応を強く求められることになる。クライアント-サーバーから Web ベースへの移行、ファイルからデータベースといった技術変化などが、スクラッチからのスタートのための良い理由を与える。
プログラミング言語において
Lisp での議論において、大きな泥だんご は異なる意味で使われており、この場合では Lisp における展性を示すために利用される。 Lispでは、以下のようなことを一般的に可能にすることを示す。
- 問題のドメインにより近く見える表記のために、言語の文法をコントロールするような マクロ を気楽に書くこと
- データ指向プログラミング スタイルを利用すること
- プログラムの部品をランタイムではなくコンパイル時に実行すること
- 将来の利用のため、変更された Lisp 実装を システムイメージ として保存すること
これらの機能を合わせた結果、Lispは、ランタイム時に、言語実装自身が完全に書き直されうるような、異常な柔軟性を持つこととなった（例：リフレクションメタプログラミング)。それらが簡単な使用を通じて拡張されて、発展できる流動性と容易に起因することで、それが Lisp を "泥だらけ" にすることとなった。Lisp の突出した特徴である、Metalinguistic abstraction もまた、プログラマーに対して、完全に新しいおよび特異な概念・語彙を開発することを許すものである。
これらの概念・語彙は、処理や関数を説明するために、問題ドメインに取り組む時に、貧しいソフトウェアドキュメンテーションと結合でき、それらのプログラムが実行される結果、Lisp はデザインの観点からすれば、非常によく構成されているものになる。
しかし、これらのコードは、このコードを書いた開発者自身か、もしくは、非常に再帰的なコードのレイヤーを理解するために時間を快く費やすことができる他の開発者のみが理解可能なものになる。
ジョエル・モーゼス は、1970年代に、以下のような独創的な書き方で名前が挙がった:[1]
APL は美しいダイヤモンドのようなものだ - 欠けているところがなく、シンメトリーで構成されている。 しかし、あなたはこれに何も付けくわえることができない。あなたが、他のダイヤモンドをくっつけようとしたとしたとしても、より大きなダイアモンドは得られない。Lisp は大きな泥だんごのようなものだ。他の泥だんごを付け加えても、それは依然、泥だんごのままだ。
Mose はこれを強く否定しており、常に元の形に戻ろうとする性質を指して、Lisp を ビーンバッグ と代わりに呼ぶことを主張している。[2]
参照
注記
- ^ Richard P. Gabriel and Guy L. Steele (1996). “The Evolution of Lisp”. ACM History of programming languages—II 28 (3): 233–330. doi:10.1145/155360.155373.
- ^ Thomas J. Bergin and Richard J. Gibson (1996). “Supplemental material from HOPL II”. ACM SIGPLAN Notices: 9–20. doi:10.1145/240964.1198155.
参考文献
- Guy L. Steele, Jr. & Richard P. Gabriel The Evolution of Lisp [1], note on reference 128
- Brian Foote and Joseph Yoder, Big Ball of Mud Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997