「現場で役立つシステム設計の原則」はプログラミング設計の普遍的な教科書 - ビープラウド社長のブログ

日本のDDD（ドメイン駆動設計）界の父ともいえる増田亨さんが著した「現場で役立つシステム設計の原則」を頂いたので、早速拝読させていただきました。 本書をおすすめしたい人 本書は、システム開発で以下のような問題を抱えている人におすすめです。 既存システムのソースコードの可読性が低く、理解に時間がかかる 機能追加・改修時の影響範囲調査に時間がかかる 機能追加・改修時の工数が予想以上にかかる テストコードが書きにくいソースコードになりがち 機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいる デグレの確認に気を使い、多くの時間をかけている 不具合が発生したときに、調査・解決に時間がかかってしまう 新しいメンバーがプロジェクトに参画した時に、業務知識を伝えるのに多くの手間がかかる これらの問題のために、生み出す価値以上に、仕事時間が増えている このような問題を解消し、変更に強い

[craftone]

読んだけど、ドメイン駆動はすごいからすごいんだ的な雰囲気で、実践までが遠い感じ。読み手(自分)の問題かなぁ。

[w1234567]

これやってくと実際にはオブジェクト指向やプログラミング以前の業務分析自体が重要なんだってところに行き着く

[from_kyushu]

手続き型大好きで俺が書いたコードを手続き型に逐一書き直していた元上司たちにプレゼントしたい。

[indication]

最近思うのは「誰が何の親なのか」。これが綺麗に設計できれば、比較的綺麗になる。ただし、親は少なくしないといけないという命題は難しい。

[s99e209]

「テストコードが書きやすいプログラム設計」を模索している人はオブジェクト指向プログラミングを学ぶとよい。

[yh1126]

“機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいる ”

[cl-gaku]

ひどい手続き型一万行クラスなんてそこら中にある

[perl-o-pal]

なんとなく寝ぼけてポチッたけど目次見て後悔している。今の時代、手続き型オンリーでやっててこれからOOPやりたいって人どの位いるんだろ。DDDやりたければDDDの本買えば？って気分。

[ghostbass]

アジャイルは顧客がサイクルの中に入ってくれないと回らないんだけどその辺足りない感じ、あとnullable拒否は良いんだけどね…

[hdampty7]

すごい興味あるな。と思いつつも、仕様決定の構造が不明確な今の体制下で役に立つかなぁ。基本的には素直で誠実で真面目な姿勢よりもよい武器がない。

[Cat_Of_STELLA]

現場は甘くないですが、読んでみたいと思います。

[nunux]

DDD ドメイン駆動設計 システム設計 オブジェクト指向 手続き型プログラミング

[yug1224]

すごく読ませたい

[aquos12345]

シンプルなモデルのうちはいいけど、複雑になるとどんな動きをするか分からんよ。いきなり空に向かって走り出して崖から落ちる

[justsize]

読ませたい相手がいる

[smartstyle]

買おう。

[bobbyjam99]

まだ読めてない 読みたい

[pokuwagata]

DDDやOOPについて

[EF-0512]

“現場で役立つシステム設計の原則”

[psfactory]

「現場で役立つシステム設計の原則」はプログラミング設計の普遍的な教科書 - ビープラウド社長のブログ

[iwasiman]

最近本屋で見てずっと気になってた本。よさそうだし後で読もう。

[hiroomi]

9784774190877

[hirokiky]

コレなんだよなぁ。実際普遍的な技術にいかに昇華するか。とはいえこういう本って抽象的で難しくて避けちゃうんだよね。読もうかな