ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ - こまぶろ

あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2本目の更新です。 ky-yk-d.hatenablog.com さて、本題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。 スパゲッティコードを想起させる装丁 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon scrapbox.io どんな本？ 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも

[yarumato]

“小さいクラスをたくさん作ることに否定的。利用者にとってはshallowなモジュール（インタフェース（メソッド）が多く、機能が少ない）に繋がりやすい。シンプルな実装よりも、シンプルなインタフェースを”

[mkusunok]

面白そうだけど、自分が抱えている問題は運営主体と更新時期が異なり相互依存している多数のシステム群をどう解していくかなので、何かしらヒントになるのだろうか？

[turanukimaru]

例えばJavaにありがちなのがパッケージ内のどのクラスで何ができるか分からないということ。エントリポイントと言うかそれ単品で動くクラスが分からない、若しくは無い。それなら単品で動くクラス一つのがマシよねと

[yasu-osu]

『Googleのソフトウェアエンジニアリング』も含めて手に取ってみたい。

[nakamura-kenichi]

日本の現場って個々人の概念がガッチガチに拘ってる割りに共有化が蔑ろ過ぎて初っぱなから実装が破綻してたりするからなｗ。結果FWしか勝たんし金太郎飴みたいなクソが量産される。

[ch1248]

大変興味深い話だった。細かく分けるにしても、それらの統括のための複雑さも厄介だからなあ……。

[karahiyo]

とても興味深い話だった “シンプルな実装よりも、シンプルなインタフェースを/インクリメントは機能ではなく抽象であるべき/コードよりも詳細を説明するコメントか、コードよりも抽象的なことを説明するコメントか

[nilab]

ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ - こまぶろ

[honma200]

何かにつけて読んでみたい・・・寝ちゃうだろうけど

[r-west]

deepって、read/write等が理想例なら、素敵な抽象って事?。そんな抽象は作るのは発明レベルに大変で利用者も新しい抽象に慣れるのも大変と思うけど、、インターフェイスの安定はそんなことよりずっと大事って事かな?

[morita_non]

あとで読む

[mitswku]

“e34.fm”

[tune]

面白そう、読んでみたい

[wdoomer]

いろんな考え方に触れる事は良さそう

[daaaaaai]

気になる

[nhayato]

２版出てたのか

[magnoliak]

とりあえず注文した