【続】ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog

はじめに 本記事は前回の記事である「ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog」の続編です。 前回の記事の内容がベースとなっていますので、「APoSD って何だっけ？」という場合はぜひ前回の記事をご覧になってから、以下にお進みください。 ということで、後編の対話パートにさっそく入っていきましょう！ Pull Complexity Downwards iwashi: APoSD では、複雑性を下に追いやる(Pull Complexity Downwards)という話が出てきます。何らかの処理が複雑になる場合、それを隠蔽してインターフェースを極力シンプルに保つ、というのがAPoSDの主張です。 こちらに関しても、社内勉強会中で

[Nyoho]

「New Jersey派のほうが生き残りやすいだろうという算段があるためです」のくだりとかおもしろいな

[kagehiens]

C言語やUnixコマンドの一貫性の弱さが嫌だから自分の設計ではなるべく一貫性を持って作れるようにするが大抵どこかで妥協せざるを得なくなる。何より悲しいのは「どういう流儀で統一したいか」が数年で変わること……

[Soraneko]

👀

[Akech_ergo]

twada氏の説明が的確でおもしろい。

[yarumato]

“2つの設計の流派：MIT/Stanfordアプローチ（APIを単純に。単純さより一貫性->プロプライエタリ製品？）とNew Jerseyアプローチ（実装を単純に。設計は正しさより単純さ。一貫性より単純さ->他人が参加しやすい->Linux、git）”

[ysirman]

“「コードがいくら複雑になろうとも、正しいことをせよ」と言っている本ではないということは強調しておきます。複雑性を廃して、どう破綻なくソフトウェアを設計するかの本です。”

[snowcrush]

Nnw Jerseyスタイルの要約の「ユーザーの負担が増えたとしても」ってそれは違うだろ。Worse is betterはユーザー負担の話はしてないし、シンプルな方が楽だと感じる人もいるはず。

[maninthemiddle]

インタフェースの一貫性vs設計のシンプルさでも他の項目でもトレードオフがあることと正解はないことを自覚した上で議論できるかどうかは大事よね

[t-wada]

書籍『A Philosophy of Software Design』をきっかけに社内でソフトウェア設計について雑談した内容の文字起こし後編です。今回はWorse is Betterの話、MIT/StanfordアプローチとNew Jerseyアプローチの話をしました

[surume000]

Gitのコマンドややこしいもんねえ。両方とも極端だよね。多くの人が両者の中間くらいを目指していると思う

[iwashi86]

後編を書きました