harryのブログ

ロードバイクとか模型とかゲームについて何か書いてあるかもしれません

プログラミングにおける"complex"と"complicated"の違い

前書き

  • よくまとまってる記事か資料があった気がするが失念した
    • が、この記事を書いてる途中で見つけた?
    • scrapbox.io
  • 本記事では、それぞれ「複雑」と「煩雑」という訳語をあてる
    • どちらも「複雑」と訳せるが、区別がつかなくなるため
  • コンテキスト(文脈)は、プログラミング

本題

英語/日本語 weblio国語辞典
complex
複雑
物事の事情や関係がこみいっていること。入り組んでいて、簡単に理解・説明できないこと。一面的ではないこと。
complicated
煩雑
物事がこみいっていて第三者に理解しにくくなっているという意味

en.wikipedia.org

Complicated(煩雑)とは

順序が逆になるが、煩雑から。

Complicated implies being difficult to understand, but ultimately knowable.

  • 込み入っていて理解が難しいが、時間さえかければ分かるもの
  • いわゆる「スパゲッティコード」のようなもの

Complex(複雑)とは

Complex, by contrast, describes the interactions between entities. As the number of entities increases, the number of interactions between them increases exponentially, making it impossible to know and understand them all.

  • 実体の数が増えるにつれ、それらの相互作用の数が指数関数的に増加し、すべてを把握/理解することが不可能となるもの
  • ある種の組み合わせ爆発

例えば金融系サービスは、法令遵守などの要請も含め、ジョブやバッチが 200 種程度になることも珍しくありませんが、これらの実行パターン (順列/同時実行/成否) の組み合わせ網羅は現実的に不可能です。

「複雑さ」の分類

Problem complexity can be divided into two categories:[2]

  1. Accidental complexity relates to difficulties a programmer faces due to the software engineering tools. Selecting a better tool set or a higher-level programming language may reduce it. Accidental complexity often results from not using the domain to frame the form of the solution.[citation needed (September 2015)] Domain-driven design can help minimize accidental complexity.
  2. Essential complexity is caused by the characteristics of the problem to be solved and cannot be reduced.
  • "Accidental complexity" と "Essential complexity" に分類される
  • 一般的に以下の訳語があてられてることが多い
    • "Accidental complexity":「偶有的複雑さ」
    • "Essential complexity":「本質的複雑さ」
  • 出典は、Frederick P. Brooks,Jr. 氏の「人月の神話」の「銀の弾などない」だと思われる

No Silver Bullet - Wikipedia

Brooks distinguishes between two different types of complexity: accidental complexity and essential complexity.

偶有的複雑さ

Accidental complexity relates to problems that engineers create and can fix. For example, modern programming languages have abstracted away the details of writing and optimizing assembly language source code and eliminated the delays caused by batch processing, though other sources of accidental complexity remain.

  • エンジニアが作り込んだり直したりできる複雑さ
  • 機能やサービスを実現するための How や非機能要件などに付随するものと言える(?)
  • おそらく、完全で完璧な無限のリソースを有するコンピューティングがあれば、存在しない類のもの
    • 残念ながら現実はお金も含めリソースは有限であり、光は光速を越えない

本質的複雑さ

Essential complexity is caused by the problem to be solved, and nothing can remove it; if users want a program to do 30 different things, then those 30 things are essential and the program must do those 30 different things.

  • 解決すべき問題そのものの複雑さ
  • ユーザーへ提供する機能やサービスに付随するもの
  • 機能要件的な複雑さとも言えそう(?) *1

参考書籍

第16章 銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項

参考リンク

scrapbox.io

銀の弾丸はないでは、複雑さだけに言及したものではないが、後続研究『Out of the Tar Pit』では、複雑さが最も重要だとして、本質的複雑さと偶有的複雑さに分類して言及している。


*1:詳細設計より前から存在する複雑さ