• はてなブックマーク
  • テクノロジー
  • システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
  • Twitterでシェア
  • Facebookでシェア

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

テクノロジー カテゴリーの変更を依頼 記事元:tech.uzabase.com
適切な情報に変更
581 usersがブックマーク コメント33

    記事へのコメント33件

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

    2021/05/20 リンク

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

    2021/05/20 リンク

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

    2021/05/20 リンク

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

    2021/05/21 リンク

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

    2021/05/20 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/20 リンク

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

    2021/05/21 リンク

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

    2021/08/22 リンク

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

    2021/08/01 リンク

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

    2021/06/13 リンク

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

    2021/06/01 リンク

    その他
    motchang
    motchang "Simplicity is HARD"

    2021/05/31 リンク

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

    2021/05/31 リンク

    その他
    rgfx
    rgfx いい話

    2021/05/24 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

    その他
    h_taiji
    h_taiji 保存

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/21 リンク

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

    2021/05/20 リンク

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

    2021/05/20 リンク

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

    2021/05/20 リンク

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

    2021/05/20 リンク

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

    2021/05/20 リンク

    その他
    otihateten3510
    otihateten3510 仕様

    2021/05/20 リンク

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

    2021/05/20 リンク

    その他

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

    アプリのスクリーンショット
    いまの話題をアプリでチェック！
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

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

    Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Cloj...

    ブックマークしたユーザー

    • buzzbuzzo2024/05/07 buzzbuzzo
    • hono3bono32024/04/13 hono3bono3
    • akishin9992024/01/11 akishin999
    • hitotakuchan2024/01/10 hitotakuchan
    • enemyoffreedom2024/01/10 enemyoffreedom
    • kiwofusi2023/12/02 kiwofusi
    • endo_55012023/11/15 endo_5501
    • marutaku01312023/11/14 marutaku0131
    • koma22023/11/13 koma2
    • wata882023/11/13 wata88
    • t-kohno2252023/11/13 t-kohno225
    • techtech05212023/09/10 techtech0521
    • lanius2023/06/17 lanius
    • harry00002023/06/15 harry0000
    • cowai52023/04/24 cowai5
    • takenoko-str2023/04/11 takenoko-str
    • teppey2023/03/01 teppey
    • adwd1182022/12/23 adwd118
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    同時期にブックマークされた記事

    はてなブックマーク

    公式Twitter

    はてなのサービス

    • App Storeからダウンロード
    • Google Playで手に入れよう
    Copyright © 2005-2024 Hatena. All Rights Reserved.