テクノロジー
システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers

気に入った記事をブックマーク

気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
記事を読んだ感想やメモを書き残せます
非公開でブックマークすることもできます

システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers

テクノロジーカテゴリーの変更を依頼記事元:

tech.uzabase.com

適切な情報に変更

エントリーの編集

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます

コメントを非表示にできますコメント表示の設定

ブックマークしました

ここにツイート内容が記載されますhttps://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

次回からTwitterへ自動リダイレクト

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

582usersがブックマークコメント

コメントするにはログインが必要ですブックマークを追加

ブックマークを追加

よく使うタグ

システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers

582 users

tech.uzabase.com

よく使うタグ

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページへ

記事へのコメント33件

注目コメント
新着コメント

turanukimaruDDDは"対象領域をドメインと呼ぶ"と良く誤解されてるが、"必須の物だけ境界に含め領域を作る"ほうが本質。自然に国境が無いように境界もない。必ず意図を持って作る。呼び方だけ"ドメイン"にして満足してる人多すぎ。

2021/05/20リンク

その他

circled自分だけが使うプログラムを作るのは簡単なんだけど、それを多くの人に使って貰おうとする時には「電子レンジで猫を乾かそうとしてはいけません」みたいな注意書きを考える必要が発生するのが地獄だと思う。

2021/05/20リンク

その他

nunulk"このように、状態からロジックを抽出していくと、なんとなく状態として扱ってしまっていたものが、実は状態ではなく、ロジックだということがわかってきます。年齢も、現在地も、状態ではなくロジックなのです。"

設計

2021/05/20リンク

その他

non_117何をやっても減らない条件分岐が必須な複雑さだよ / ソフトウェアが複雑なのではなく社会が複雑なんですよ / この手の設計論は初学者に伝わらないのだがどうしたもんかな

2021/05/21リンク

その他

yojik“この論文は2006年のものですから、Clean Architectureとかもまだありません” 本としてのクリーンアーキテクチャ自体はボブが昔から言ってることをまとめなおしただけだから、微妙に引っかかる表現かもしれない

2021/05/20リンク

その他

bayashi_netシステムの難しさは、複雑さより暗黙なものだなあ。近年のプログラム言語の進化は暗黙なものを簡潔に明示的に書く方向だと思ってる。

2021/05/21リンク

その他

dexia2最初は抽象的な話で難しいなと思いましたが、Clojureの言語仕様やライブラリの経験などを思い出すと、理解できました。Clojureは原理に忠実でわかりやすいですね。

2021/05/21リンク

その他

dltltユーザ側が、多数の条件分岐で繋がったステイタス群を「必須」指定してきたらどうするのだろう。

意図しない加速

2021/05/21リンク

その他

quanon「必須な複雑さ」と「付随的な複雑さ」を区別する。なるほど。プログラミング言語がパワフルでなんでもできるがゆえに複雑は生まれるので、領域ごとに専用の DSL を用意し、やれることを制限するってのもおもしろい。

2021/05/20リンク

その他

rti7743この場合は除くの例外的処理からくるものだと思うよ。赤は停止、青は進めだけならいいけど、ただし矢印が出ている側に曲がる場合は除くって条件がつくだけでも複雑さは増すわけだし。そういうのがたくさんあるわけで

2021/05/21リンク

その他

daaaaaai複雑さの原因4つのうちの状態にフォーカスして複雑さに対峙しようとするのおもしろい

2021/08/22リンク

その他

masa8aurum必須の(Essential)複雑さ、付随的な(Accidental)複雑さ

2021/08/01リンク

その他

igrep本当に必要なのは「ユーザーの入力」だけでそこから要件上計算しないといけないものが「必須のロジック」で、それで求めた結果を保存したり表示したりするのは付随的な複雑さ。センサーの入力もユーザーの入力の内？

2021/06/13リンク

その他

yuki_2021設計とかクリーンアーキテクチャについて。

2021/06/01リンク

その他

motchang"Simplicity is HARD"

2021/05/31リンク

その他

Nnwwwいかに外部へ必須でないステートとロジックを払い出していくかという設計手法(手順)の一例。何気に昨今のイケイケシステムが生じた理由の一般化された説明として便利そうで興味深い。

architecture

2021/05/31リンク

その他

rgfxいい話

2021/05/24リンク

その他

efcl複雑さを - 必須の(Essential)複雑さ - 付随的な(Accidental)複雑さにわけて、computedとして表現できるステートは必須ではないので、切り離す。キャッシュ/メモ化などで表現することで複雑さを分離する

architecture

2021/05/21リンク

その他

toenobu“Fなどの分岐が、ユーザーの直接の要求であるケースもあるのでは？ゴールド会員はポイント２倍とか。でも、世の”

2021/05/21リンク

その他

h_taiji保存

2021/05/21リンク

その他

2021/05/21リンク

その他

sawat現在地を「状態」ではなく「ロジックとキャッシュ」にすることで本当に複雑さが減るのだろうか？キャッシュにはキャッシュの複雑性がある（いつクリアするのとか）。複雑さが見えにくくなっただけではないだろうか？

2021/05/21リンク

その他

dotシステムは業務の写像だから業務が複雑ならなるべくしてシステムは複雑化する。業務の枝葉をできるだけ払ってシンプルな業務を保つのがシステムが複雑化しないための秘訣だと思ってる。

2021/05/21リンク

その他

NOV1975汎用プログラミングは敵だみたいな話？／要件が複雑なシステムをシンプルに作ろうとすると外部のどこかが複雑になる、というだけな気がしているけど。

2021/05/21リンク

その他

ko-ya-ma関数型言語への招待…とも読める

2021/05/21リンク

その他

2021/05/21リンク

その他

kaiton例外が増える、前提が変わるかな？

2021/05/21リンク

その他

kagehiens一理あるけど、それがメインじゃないよね……、業務系の場合だけど。

2021/05/21リンク

その他

bayashi_netシステムの難しさは、複雑さより暗黙なものだなあ。近年のプログラム言語の進化は暗黙なものを簡潔に明示的に書く方向だと思ってる。

2021/05/21リンク

その他

Magicantいかにも関数型畑の人が考へさうな話 / 複雑さの定義を狭めることで複雑さは少なくなるのだといふ主張といふか欺瞞

2021/05/21リンク

その他

dltltユーザ側が、多数の条件分岐で繋がったステイタス群を「必須」指定してきたらどうするのだろう。

意図しない加速

2021/05/21リンク

その他

2021/05/21リンク

その他

iwtn毎回無限の計算はできないから、むしろデータというか状態を持ち続けたほうが良い？FRPは面白そう。

2021/05/21リンク

その他

sugawara1991計算で導出できるものを状態として扱わないのはレイテンシとかでむしろ性能上有利になる可能性すら。リスト構造を直ポインタでなくインデックスで実装する件とか。状態不整合バグも避けるし

その他

その他

その他

その他

その他

otihateten3510仕様

2021/05/20リンク

その他

buhoho"「複雑なシステムから複雑さを取り除く」のと「シンプルさを重視してデザインされた遅いシステムのパフォーマンスを改善する」のとであれば、後者の方がきっとマシ" せやな。好きな考え方

2021/05/20リンク

その他

コメントするにはログインが必要ですログインしてコメント

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー

はてなブックマークボタンを作成して埋め込むこともできます

規約違反を報告

いまの話題をアプリでチェック！

バナー広告なし
ミュート機能あり
ダークモード搭載

アプリをダウンロード

usersに達しました！

さんが1番目にブックマークした記事「システムの複雑さ...」が注目されています。

気持ちをシェアしよう

ツイートする

システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers

Uzabase Saas Product Divisionフェローの矢野です。この記事は、Rich Hickey（プログラミング言語Cloj...Uzabase Saas Product Divisionフェローの矢野です。この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。ソフトウェア危機ソフトウェアは本質的に複雑ソフトウェアの複雑さはどこから来るのか？複雑さは、別の複雑さを産む複雑さを分類する本当に必要な複雑さと、そうでないものがあるどうやって複雑さを扱うのか