投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
わかりやすいコード整理の方法や設計の本。
後半の立ち回りなどなどは臨場感あってよかった!
だいぶ途中開いたのでまたじわじわ読み直したい。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
自分のコードが長くなって読みづらくなってきたので可読性上げたくて読んだ。結構良かった印象。
オブジェクト指向について学びたかったが、それについてもそれなりに良い。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
リータブルコードよりも進んだ内容で、設計パターンなどがちらほら紹介されつつ、アンチパターンとその解決策を示している。基本的に自分としては上司に鍛えられたお陰でできている方だとおもったが、アンチパターンに陥っていないか時々振返りして自律する本だとおもう。一部staticについては凝集度の件で違和感があるが概ね納得いく。
入門とあるが、実際に一年くらい小規模でも書いていて上司やら誰かからフィードバックを受けて設計に多少なれておかない理解して実践は進みづらいと思う。
そしてなにより、これが最も必要な人は自信満々にアンチパターンをゴリゴリ書いてしまう自己肥大おっさんプログラマーだと思うが、自信が肥大化しているためこういった本を読もうと思わないという残念な矛盾がありそう。もったいない。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
感想は以下
https://blog.masterka.net/archives/3930
https://blog.masterka.net/archives/3939
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
やりがちな悪いコード例があってからの改善方法、理論、デザインパターンという流れで説明されていて、スッと入ってくるように読み込めた。
筆者の経験ベースなので題材に偏りはあるが、未経験から業務でコードを書き始めた人に読んで欲しい本だと思う。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
Javaのサンプルソースを見せながらの説明が具体的だったのでわかりやすくてよかった。
他のお作法本は説明が抽象的だったり、考え方の理論だけの説明だけだったりして、じゃあ実際にはどういうふうに書くの?どんな場面で使うの?って疑問に残って腑に落ちないことが多いのに対して、この本はそういうこともなかった。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
各種のテクニック集になっている。巻末にあるような有名な本を読んでから入り、それがテクニックとしてはどうなるかさわりが読めると思う。
一部用語が多分オリジナルなのと、サンプルコードはあくまで説明箇所に限定した説明用コードなので意識した方が良い。その意味では初心者向けという訳ではなさそう。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
内容は、参考文献(本やURLなど)から著者が抜粋したものに説明やコードを加えてまとめたもの。
参考文献は著名なものが多くそれを取り上げているのだから、参考になる部分が多くあるのは当然。
私は参考文献の5分の1ぐらいしか読んでいないが、本書の内容はほぼ見たことがある内容ばかりで、特に新たに学習になった点は無かった。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
本書は名著の再構築で初学者向けだが、内容に誤りがあり批判的な読み方が必要。参考文献の良書を読む方が良いかも。実装課題は納得できるが解決案は説得力に欠け、設計のノウハウは学べない。悪いコードの例示は著者の偏見が色濃く、SNSでの評価は信じがたい。"わかりやすい"が人気の理由だが、質は低く誤解を招く可能性あり。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
昨年のITエンジニア本大賞受賞作ということで気になっていたので、読んでみた。
悪いコード例が、見おぼえあるし、なんなら自分のコードのようだった…。
クラスの中のメソッドの返却値が、それ自身のクラスのインスタンスというやり方に驚いた。パフォーマンス的に問題ありそうと思ったけど、今時気にする必要はほぼないとのこと(組込みソフトウェアは別)
メンバ変数を書き換えるのは問題あるのか…。メンバ変数はできるかぎり不変にしたほうがいいらしい。
まあでも、確かに関数内以外で宣言された変数の変更は副作用になるだろうしね。一種のグローバル変数みたいなもんだし。
ファクトリメソッドの概念も面白い。コンストラクタをprivateにする発想はなかったけど、メンバ変数に入れる値が限られているなら、それもありか。
できるかぎり、プリミティブ型の変数を使わないという話もなるほどと思った。ただ、こうするとかなりクラスの数が多くなりそう…。まあ、今後の保守を考えるとそのほうがいいのかな。
switch文重複問題の解決に、interfaceを使う話、例に示された二つのクラスに、全く同じ名前のメンバ変数があって、それなら継承でいいのでは?と思ったら、継承はやめたほうがいいらしい。
オーバーライドで書き換えることが、不具合の原因になりかねないのだとか。今はそういう考えなのか…。
継承を使いたい場合は、委譲する(スーパークラスをインスタンス変数にしておく)という方法のほうがいいのだとか。普通に今の仕事のプロジェクトで、継承で実装してしまってるなぁ…。
本題ではないけど、nullを発明した、アントニー・ホーアという方が、10億ドルにのぼる損害をだしてしまったことで、謝罪したという話が面白かった。いわゆる、ヌルポというのは、例外エラーの代表格だしね。やっぱり、null安全の言語を使うのがいいのだろうなと思う。
関心事にふさわしい命名をするのがいいというのは分かるけど、なかなか難しそう。自分なら、普通に商品クラスを作ってしまうなぁ。予約品や発送品というクラスにしたほうがいいと。でも、連携はどうすればいいのだろう…。
モデリング設計については、テーブル設計についてもあてはまるのかな。それとも、データベースだと商品テーブルというのを作るのもありなのかな。
TDDの、テストを成功させる最低限のコードを書く理由がよく分かってない。エラーのままコードを書いて実装を進めるのはやめたほうがいいのだろうか…。
途中、「筆者はリファクタリング専門のエンジニアとして仕事をしています」と書いてあって驚いた。リファクタリング専門の仕事なんてあるのか…。
どおりで、これだけいろいろな視点からコード設計術について書けるわけだ…。
「木こりのジレンマ」の話は聞いたことがあるけど、本当そうだよなと思う。昨年から関わってるプロジェクトがまさにそうだけど、設計もろくにせずに、がむしゃらに頑張っていると、不具合だらけになる…。こないだ数か月遅れでリリースはしたけど、うまく動くのかと不安だ…。
レガシーコードに人は引きずられやすいという話は、本当、自分も反省しないといけないことだなと思う。
今年入った新人は、自分の書いたコードの改修をメインにやってくれているけど、テストコードもない分かりづらいコードでごめんと思う。
最後に、おすすめの設計本の紹介をされていたけど、気になった読んだことない本をまた読んでみようかなと思う。「Clean Code」とか「セキュア・バイ・デザイン」とか。この本より後に発売された本だけおd、今年の初めに発売された「Good Code, Bad Code」も気になってる。
本当、もっと設計を意識した開発をできるようになっていきたい。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
具体的な小さいコードを用いて設計的にまずいコードをどのように改善していけばよいのかがそれぞれステップバイステップで学べる本
ジュニアなソフトウェアエンジニアを対象にしているのでどのレベルの人が読んでも学ぶことがあると思う
実践する中でリファレンス的にも使えそう
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
コーディングや設計のアンチパターンには身に覚えのあるものがとても多く、学びになった
また、最後の章の設計関連の参考書籍も大変参考になるものも多く、次の学びにつなげようと思えた
本書で学んだことを展開して、レガシーコードに少しでも苦しめられないようにしていきたいと思えた
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
可読性の高く、変更が容易なコードを書くための方法をかなりわかりやすく書いてくれています。
読む価値ありです。
ただ量が多いので一度読んだだけでは全て把握することは難しいかもしれないです。
コードを書いて、読み直して、それを元にまた書いてを繰り返していくのがよさそうです。