あらすじ
※PDF版をご希望の方は Gihyo Digital Publishing (https://gihyo.jp/dp/ebook/2022/978-4-297-12784-8)も合わせてご覧ください。
本書は，より成長させやすいコードの書き方と設計を学ぶ入門書です。
システム開発では，ソフトウェアの変更が難しくなる事態が頻発します。コードの可読性が低く調査に時間がかかる，コードの影響範囲が不明で変更すると動かなくなる，新機能を追加したいがどこに実装すればいいかわからない……。
変更しづらいコードは，成長できないコードです。ビジネスの進化への追随や，機能の改善が難しくなります。
成長できないコードの問題を，設計で解決します。
感情タグBEST3
Posted by ブクログ
繰り返し読み返すことで、良くないコードのパターンと整頓されたコードのパターンを感覚的に見極めることができるようになるだろうと思う。
どういうときに、どんな問題のあるコードを書きがちか？説明されていてよい。
技術不足と断ずるのではなく、チームやプロセスなどソフト的な問題にも触れていて、とても納得感がある。
次に読むべき本や学習のコツなど、本気で人を育てる意志を感じる良書であった。
Posted by ブクログ
名付けやモデリングが上手くできている気がせず、他の著書など読んでもピンと来なかったが、この本ではっきり答えが書かれており腹落ちした。
オブジェクト指向の解説本としてかなり分かりやすいと思った。今後、改めて低凝集にならないように心がけて開発していきたい。
Posted by ブクログ
コーディングや設計のアンチパターンには身に覚えのあるものがとても多く、学びになった
また、最後の章の設計関連の参考書籍も大変参考になるものも多く、次の学びにつなげようと思えた
本書で学んだことを展開して、レガシーコードに少しでも苦しめられないようにしていきたいと思えた
Posted by ブクログ
具体的な小さいコードを用いて設計的にまずいコードをどのように改善していけばよいのかがそれぞれステップバイステップで学べる本
ジュニアなソフトウェアエンジニアを対象にしているのでどのレベルの人が読んでも学ぶことがあると思う
実践する中でリファレンス的にも使えそう
Posted by ブクログ
Javaのサンプルソースを見せながらの説明が具体的だったのでわかりやすくてよかった。
他のお作法本は説明が抽象的だったり、考え方の理論だけの説明だけだったりして、じゃあ実際にはどういうふうに書くの？どんな場面で使うの？って疑問に残って腑に落ちないことが多いのに対して、この本はそういうこともなかった。
Posted by ブクログ
リータブルコードよりも進んだ内容で、設計パターンなどがちらほら紹介されつつ、アンチパターンとその解決策を示している。基本的に自分としては上司に鍛えられたお陰でできている方だとおもったが、アンチパターンに陥っていないか時々振返りして自律する本だとおもう。一部staticについては凝集度の件で違和感があるが概ね納得いく。
入門とあるが、実際に一年くらい小規模でも書いていて上司やら誰かからフィードバックを受けて設計に多少なれておかない理解して実践は進みづらいと思う。
そしてなにより、これが最も必要な人は自信満々にアンチパターンをゴリゴリ書いてしまう自己肥大おっさんプログラマーだと思うが、自信が肥大化しているためこういった本を読もうと思わないという残念な矛盾がありそう。もったいない。
Posted by ブクログ
著者の開発系経験の中で出会った悪いコードを例に、どういった点が悪く、どうすべきなのかが記載された書籍。
スラスラと読みやすいため、良いコードを書きたいと思う人は一度読んで自身のレベルを把握した上で本書を熟読するのか、より上級の書籍にステップアップをするのか判断するのに適していると感じた。
Posted by ブクログ
ある程度経験を積んだ(辛酸を嘗めた)エンジニアであれば「こういうのあるよね」とリアリティを伴った共感をせずにはいられない養殖コードたちと、よりよくするためのTipsがわかりやすくまとめられている。
Tipsについては「他の方法がいいんじゃないの?」というものもあるが、そういった議論の余地があることにこそ価値がある。たとえば会社で本書を読み合わせてみる。すると多角的な視点から意見が集まってきて、その対話で学びが練り上がっていく。
「こんな初歩的な書き方しないだろう」「こんなの勉強してたらとっくに知ってるよ」そう思うシニアエンジニアが、その境地に達していないジュニアなエンジニアと本書を読み合わせてる。そんな形での読み方がしっくりくるような一冊。
Posted by ブクログ
プログラミング初心者です。コードを書く際に知っておくべきことを知れてよかったです。コードレビューの仕方も書いてあり、ちょうど知りたいと思っていたことをたくさん知れました。基礎基本がちゃんと書かれている良い入門書だと思います
Posted by ブクログ
今まで読んできたコード設計の総集編のような書籍だった。
ドメイン駆動設計の文脈では「境界付けられたコンテキスト」という用語が出るが、本書ではそれが「達成目的」や「関心事」といった形で表されていると(個人的に)解釈し、頭の整理がつけられたように思う。
Posted by ブクログ
# 中級者向けのクラス・システム設計の参考書
## 面白かったところ
- GetterやSetterが悪と呼ばれる所以をサンプルコードを通じて知ることができる
- クラス設計でミスをする理由、改善方法がわかりやすく提示してある点
_ ほんとうの意味でのカプセル化が完全に理解できる
## 微妙だったところ
- 特になし
## 感想
「ソフトウェアエンジニアリング難すぎんか？」と、いつも思い耽りながら仕事をこなし、銀の弾丸を求めて技術書を読み漁るような人間にとっては、かなり刺激的な書籍だった。
良い設計指南書は抽象的すぎて実際にクラス配置はできるが、クラスの中のプロパティやメソッドが業務とは程遠かったりすることは稀によくある。
だからこそ、丁度いい温度感だったのが当書である。
2から3年程度、業務を真面目にこなしてきた人間には通じる話ばかりだし、参考としている書籍も業界的には名著と呼ばれるものばかりが並んでいる。
この本を読んだからといって明日のシステム開発が変わるかはわからないが、長い目で見るとソフトウェア業界に大きく貢献しそうな本だと確信した。
また読みたい。
Posted by ブクログ
１０章以降（個人的には「名前設計」と「設計の意義と設計への向き合い方」が）とても良かった。
何もわからず「コードを書く」というところから始まった新人当時、名前付けに対してとても注意されたことを思い出した。当時の技術書を読むというのは、自分の持つスキル（手段）を強化するようなイメージがあったが、この本はさらにその先の「業務を理解する」や「ビジネスを理解する」ということの手助けをしてくれると思う。
この本を読んだあとにエンプラ系の技術者は『現場で役立つシステム設計の原則』を読むと理解しやすいかもしれないなとも思う。
Posted by ブクログ
2日かけて一気読み。
内容はミノさんのQiitaや登壇資料など今までのアウトプット+αといった具合でまさに集大成。
長大なif文のネストに困っていたので、Policyパターンで解決できるか実験してみたい。
また、シンタックスハイライトも変えてみようと思う。
Posted by ブクログ
・デフォルトでは変数はイミュータブルとする
・高凝集とはデータとロジックが結びついている状態
・概念的に異なるものはクラス化しプリミティブ型執着を避ける
・インターフェースを使ったストラテジーパターンでSwitch文クローン問題を回避する
・共通処理があっても概念的に異なるものは独立してクラス化して疎結合にする
・フールプルーフの観点から継承は使わず移譲（メンバーにスーパークラスを持つ）を使うコンポジション設計にする
・コレクションに性質がある場合はクラス化する（ファーストクラスコレクション）
・肥大化したデータクラスはグローバル変数と似た性質を持つため避ける
・フォルダ構成は技術駆動ではなくビジネス概念で分ける
・ユビキタス言語や利用規約を活用し、存在ベースではなく目的ベースで名前設計する
・モデリングではシステム内での登場人物の目的で分解して設計する
・レビューでは敬意を示す
ストラテジーパターンが具体的にイメージしづらかったため、アウトプットしたい。
Posted by ブクログ
可読性の高く、変更が容易なコードを書くための方法をかなりわかりやすく書いてくれています。
読む価値ありです。
ただ量が多いので一度読んだだけでは全て把握することは難しいかもしれないです。
コードを書いて、読み直して、それを元にまた書いてを繰り返していくのがよさそうです。
Posted by ブクログ
やりがちな悪いコード例があってからの改善方法、理論、デザインパターンという流れで説明されていて、スッと入ってくるように読み込めた。
筆者の経験ベースなので題材に偏りはあるが、未経験から業務でコードを書き始めた人に読んで欲しい本だと思う。
Posted by ブクログ
自分のコードが長くなって読みづらくなってきたので可読性上げたくて読んだ。結構良かった印象。
オブジェクト指向について学びたかったが、それについてもそれなりに良い。
Posted by ブクログ
各種のテクニック集になっている。巻末にあるような有名な本を読んでから入り、それがテクニックとしてはどうなるかさわりが読めると思う。
一部用語が多分オリジナルなのと、サンプルコードはあくまで説明箇所に限定した説明用コードなので意識した方が良い。その意味では初心者向けという訳ではなさそう。
Posted by ブクログ
流し読み。解説文は概ね合意できるが、例示部分はチームやドメインによって話が違うので評価しにくいと思った。著者の考えと、文献に示されて社会的に受け入れられている概念を、区別して書いていないと感じる部分があったので、そこの線引きが明確だと良かったかなと思うし、文献に示されて社会的に受け入れられている概念のみでミニマムに構成したもっと薄い本の方が、より初学者向けにできたのではないかと思う。あと、いきなり設計じゃなくて、フレームワーク使ったり、既存OSSを弄ったり、良い設計で自由度を制限されたとこから始めるのが普通だと思うのだけど、カタの話で言うと、この本は、突きの肘の使い方とか、蹴る時の視線、みたいな話題の集合になってるきらいがあって、演舞の一連の流れから様々な意味を見い出す、という構成になってないのかなと感じた。
オブジェクト指向の良さを推す本
クラスの細分化（１クラス１責務）や低結合、高凝集の徹底などオブジェクト指向をベースに、変更容易性や見通しの良さ、バグを生みにくい構造になっているものを良いコードと定義し解説している本です。
色々と分かりやすくテクニックを学べるので、オブジェクト指向的な構造の徹底を目指していたり、やり方を知りたい人。あるいはそういう構造が好きという方には良いと思います。
私は徹底しすぎると融通が効かなくなる点が苦手なのと、社内のプログラマの理解度の差や好みの差を埋めるのが大変すぎる点があるので（高齢プログラマであればあるほど嫌がる）、ここまで徹底はしないだろうと思いますが、色々と考え方を変えるきっかけにはなりそうです。
１つ気になったのは、値を変更や計算をする際に直に値を変更せず、変更や計算後の値を持つクラスをnewして返す仕組みです。筆者はクラス作成時のコストが気になる場合について言及されていましたが、もう１つの弊害として、unityとかだとnewすることで発生するゴミデータによってＧＣが発生してしまいスパイクになる問題があります。
低スペスマホでアプリを動かすとスパイクは非常に気になるので気軽にnewを多様する形は避けるべきだと思っています。
