良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方

著者 : 仙塲大也

• 技術評論社 (2022年4月30日発売)

作品紹介・あらすじ

本書は、より成長させやすいコードの書き方と設計を学ぶ入門書です。

システム開発では、ソフトウェアの変更が難しくなる事態が頻発します。
コードの可読性が低く調査に時間がかかる、
コードの影響範囲が不明で変更すると動かなくなる、
新機能を追加したいがどこに実装すればいいかわからない……。

変更しづらいコードは、成長できないコードです。
ビジネスの進化への追随や、機能の改善が難しくなります。

成長できないコードの問題を、設計で解決します。

感想・レビュー・書評

[無名太郎さんの感想 · 2024年4月26日]

可読性の高く、変更が容易なコードを書くための方法をかなりわかりやすく書いてくれています。
読む価値ありです。
ただ量が多いので一度読んだだけでは全て把握することは難しいかもしれないです。
コードを書いて、読み直して、それを元にまた書いてを繰り返していくのがよさそうです。

[豊橋技術科学大学図書館さんの感想 · 2024年3月5日]

選書企画2023 「図書館に置いて欲しい本　書いて！貼って！」　購入図書

【配架場所】　図・3F開架
【請求記号】 007.63||SE
【OPACへのリンク】
　https://opac.lib.tut.ac.jp/opac/volume/462317

[こんすたさんの感想 · 2024年1月3日]

コーディングや設計のアンチパターンには身に覚えのあるものがとても多く、学びになった
また、最後の章の設計関連の参考書籍も大変参考になるものも多く、次の学びにつなげようと思えた

本書で学んだことを展開して、レガシーコードに少しでも苦しめられないようにしていきたいと思えた

[akiさんの感想 · 2023年12月3日]

具体的な小さいコードを用いて設計的にまずいコードをどのように改善していけばよいのかがそれぞれステップバイステップで学べる本
ジュニアなソフトウェアエンジニアを対象にしているのでどのレベルの人が読んでも学ぶことがあると思う
実践する中でリファレンス的にも使えそう

[amano225さんの感想 · 2023年11月4日]

昨年のITエンジニア本大賞受賞作ということで気になっていたので、読んでみた。
悪いコード例が、見おぼえあるし、なんなら自分のコードのようだった…。

クラスの中のメソッドの返却値が、それ自身のクラスのインスタンスというやり方に驚いた。パフォーマンス的に問題ありそうと思ったけど、今時気にする必要はほぼないとのこと(組込みソフトウェアは別)
メンバ変数を書き換えるのは問題あるのか…。メンバ変数はできるかぎり不変にしたほうがいいらしい。
まあでも、確かに関数内以外で宣言された変数の変更は副作用になるだろうしね。一種のグローバル変数みたいなもんだし。

ファクトリメソッドの概念も面白い。コンストラクタをprivateにする発想はなかったけど、メンバ変数に入れる値が限られているなら、それもありか。

できるかぎり、プリミティブ型の変数を使わないという話もなるほどと思った。ただ、こうするとかなりクラスの数が多くなりそう…。まあ、今後の保守を考えるとそのほうがいいのかな。

switch文重複問題の解決に、interfaceを使う話、例に示された二つのクラスに、全く同じ名前のメンバ変数があって、それなら継承でいいのでは？と思ったら、継承はやめたほうがいいらしい。
オーバーライドで書き換えることが、不具合の原因になりかねないのだとか。今はそういう考えなのか…。
継承を使いたい場合は、委譲する(スーパークラスをインスタンス変数にしておく)という方法のほうがいいのだとか。普通に今の仕事のプロジェクトで、継承で実装してしまってるなぁ…。

本題ではないけど、nullを発明した、アントニー・ホーアという方が、10億ドルにのぼる損害をだしてしまったことで、謝罪したという話が面白かった。いわゆる、ヌルポというのは、例外エラーの代表格だしね。やっぱり、null安全の言語を使うのがいいのだろうなと思う。

関心事にふさわしい命名をするのがいいというのは分かるけど、なかなか難しそう。自分なら、普通に商品クラスを作ってしまうなぁ。予約品や発送品というクラスにしたほうがいいと。でも、連携はどうすればいいのだろう…。

モデリング設計については、テーブル設計についてもあてはまるのかな。それとも、データベースだと商品テーブルというのを作るのもありなのかな。

TDDの、テストを成功させる最低限のコードを書く理由がよく分かってない。エラーのままコードを書いて実装を進めるのはやめたほうがいいのだろうか…。

途中、「筆者はリファクタリング専門のエンジニアとして仕事をしています」と書いてあって驚いた。リファクタリング専門の仕事なんてあるのか…。
どおりで、これだけいろいろな視点からコード設計術について書けるわけだ…。

「木こりのジレンマ」の話は聞いたことがあるけど、本当そうだよなと思う。昨年から関わってるプロジェクトがまさにそうだけど、設計もろくにせずに、がむしゃらに頑張っていると、不具合だらけになる…。こないだ数か月遅れでリリースはしたけど、うまく動くのかと不安だ…。

レガシーコードに人は引きずられやすいという話は、本当、自分も反省しないといけないことだなと思う。
今年入った新人は、自分の書いたコードの改修をメインにやってくれているけど、テストコードもない分かりづらいコードでごめんと思う。

最後に、おすすめの設計本の紹介をされていたけど、気になった読んだことない本をまた読んでみようかなと思う。「Clean Code」とか「セキュア・バイ・デザイン」とか。この本より後に発売された本だけおｄ、今年の初めに発売された「Good Code, Bad Code」も気になってる。

本当、もっと設計を意識した開発をできるようになっていきたい。

[Yohei Satoさんの感想 · 2023年10月29日]

本書は名著の再構築で初学者向けだが、内容に誤りがあり批判的な読み方が必要。参考文献の良書を読む方が良いかも。実装課題は納得できるが解決案は説得力に欠け、設計のノウハウは学べない。悪いコードの例示は著者の偏見が色濃く、SNSでの評価は信じがたい。"わかりやすい"が人気の理由だが、質は低く誤解を招く可能性あり。

[ぷらんくさんの感想 · 2023年9月13日]

今までオブジェクト指向プログラミングのこと舐めてました

[ゆぺこさんの感想 · 2023年9月11日]

ITエンジニア本大賞より (https://www.shoeisha.co.jp/campaign/award)

[sou (08thse)さんの感想 · 2023年8月27日]

全体的にドメイン駆動設計が前提になる話が多め。
実例は分かりやすいと思います。

[tattyammさんの感想 · 2023年7月9日]

各種のテクニック集になっている。巻末にあるような有名な本を読んでから入り、それがテクニックとしてはどうなるかさわりが読めると思う。
一部用語が多分オリジナルなのと、サンプルコードはあくまで説明箇所に限定した説明用コードなので意識した方が良い。その意味では初心者向けという訳ではなさそう。

著者プロフィール

青森県出身。大手電機メーカーなどを経て、現在はREADYFOR株式会社にてアプリケーションアーキテクトを務める。リファクタリングや設計全般を推進。

悪しきコードとの戦いの中で設計の魅力に気付く。暇さえあれば脳内でリファクタリングしている。

Twitterではプログラミングの風刺動画を不定期で投稿。

Developers Summit 2021 Summerベストスピーカー賞3位。その他登壇多数。

Twitter : ミノ駆動（@MinoDriven）

「2022年 『良いコード／悪いコードで学ぶ設計入門』 で使われていた紹介文から引用しています。」