良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方
- 技術評論社 (2022年4月30日発売)
本棚登録 : 899人
感想 : 44件
- Amazon.co.jp ・本 (400ページ)
- / ISBN・EAN: 9784297127831
作品紹介・あらすじ
本書は、より成長させやすいコードの書き方と設計を学ぶ入門書です。
システム開発では、ソフトウェアの変更が難しくなる事態が頻発します。
コードの可読性が低く調査に時間がかかる、
コードの影響範囲が不明で変更すると動かなくなる、
新機能を追加したいがどこに実装すればいいかわからない……。
変更しづらいコードは、成長できないコードです。
ビジネスの進化への追随や、機能の改善が難しくなります。
成長できないコードの問題を、設計で解決します。
感想・レビュー・書評
-
コメント0件をすべて表示
-
案件やお客様毎に標準的な組み方のルールなどもあるので、骨幹の無駄をなくす考え方だけ拝借。
むしろ考え方の方が面白く読めた印象がある。
23
-
具体的な小さいコードを用いて設計的にまずいコードをどのように改善していけばよいのかがそれぞれステップバイステップで学べる本
ジュニアなソフトウェアエンジニアを対象にしているのでどのレベルの人が読んでも学ぶことがあると思う
実践する中でリファレンス的にも使えそう
2
-
Webエンジニア向けの本。Javaのソースコードを例にクラス設計などのアンチパターンと解決策を紹介している。
序盤は基本的なコードの書き方で、中盤はJavaを使ったクラス、密結合や名前設計といった話、終盤は設計の意義やチームとしてのコミュニケーション、他のおすすめ本の紹介が書かれている。
どのようにエンジニアとしてのスキルアップをしていくかの道標にもなるので、定期的に読み返したい
2
-
昨年のITエンジニア本大賞受賞作ということで気になっていたので、読んでみた。
悪いコード例が、見おぼえあるし、なんなら自分のコードのようだった…。
クラスの中のメソッドの返却値が、それ自身のクラスのインスタンスというやり方に驚いた。パフォーマンス的に問題ありそうと思ったけど、今時気にする必要はほぼないとのこと(組込みソフトウェアは別)
メンバ変数を書き換えるのは問題あるのか…。メンバ変数はできるかぎり不変にしたほうがいいらしい。
まあでも、確かに関数内以外で宣言された変数の変更は副作用になるだろうしね。一種のグローバル変数みたいなもんだし。
ファクトリメソッドの概念も面白い。コンストラクタをprivateにする発想はなかったけど、メンバ変数に入れる値が限られているなら、それもありか。
できるかぎり、プリミティブ型の変数を使わないという話もなるほどと思った。ただ、こうするとかなりクラスの数が多くなりそう…。まあ、今後の保守を考えるとそのほうがいいのかな。
switch文重複問題の解決に、interfaceを使う話、例に示された二つのクラスに、全く同じ名前のメンバ変数があって、それなら継承でいいのでは？と思ったら、継承はやめたほうがいいらしい。
オーバーライドで書き換えることが、不具合の原因になりかねないのだとか。今はそういう考えなのか…。
継承を使いたい場合は、委譲する(スーパークラスをインスタンス変数にしておく)という方法のほうがいいのだとか。普通に今の仕事のプロジェクトで、継承で実装してしまってるなぁ…。
本題ではないけど、nullを発明した、アントニー・ホーアという方が、10億ドルにのぼる損害をだしてしまったことで、謝罪したという話が面白かった。いわゆる、ヌルポというのは、例外エラーの代表格だしね。やっぱり、null安全の言語を使うのがいいのだろうなと思う。
関心事にふさわしい命名をするのがいいというのは分かるけど、なかなか難しそう。自分なら、普通に商品クラスを作ってしまうなぁ。予約品や発送品というクラスにしたほうがいいと。でも、連携はどうすればいいのだろう…。
モデリング設計については、テーブル設計についてもあてはまるのかな。それとも、データベースだと商品テーブルというのを作るのもありなのかな。
TDDの、テストを成功させる最低限のコードを書く理由がよく分かってない。エラーのままコードを書いて実装を進めるのはやめたほうがいいのだろうか…。
途中、「筆者はリファクタリング専門のエンジニアとして仕事をしています」と書いてあって驚いた。リファクタリング専門の仕事なんてあるのか…。
どおりで、これだけいろいろな視点からコード設計術について書けるわけだ…。
「木こりのジレンマ」の話は聞いたことがあるけど、本当そうだよなと思う。昨年から関わってるプロジェクトがまさにそうだけど、設計もろくにせずに、がむしゃらに頑張っていると、不具合だらけになる…。こないだ数か月遅れでリリースはしたけど、うまく動くのかと不安だ…。
レガシーコードに人は引きずられやすいという話は、本当、自分も反省しないといけないことだなと思う。
今年入った新人は、自分の書いたコードの改修をメインにやってくれているけど、テストコードもない分かりづらいコードでごめんと思う。
最後に、おすすめの設計本の紹介をされていたけど、気になった読んだことない本をまた読んでみようかなと思う。「Clean Code」とか「セキュア・バイ・デザイン」とか。この本より後に発売された本だけおｄ、今年の初めに発売された「Good Code, Bad Code」も気になってる。
本当、もっと設計を意識した開発をできるようになっていきたい。
1
-
本書は名著の再構築で初学者向けだが、内容に誤りがあり批判的な読み方が必要。参考文献の良書を読む方が良いかも。実装課題は納得できるが解決案は説得力に欠け、設計のノウハウは学べない。悪いコードの例示は著者の偏見が色濃く、SNSでの評価は信じがたい。"わかりやすい"が人気の理由だが、質は低く誤解を招く可能性あり。
1
-
前任者が書いた悪いコードを見て育った新入社員が、真似して悪いコードの書き手となる、って話はドキッとする。リファクタリングできる人がどこかで断ち切るか、プログラマが自らリファクタリングについて勉強しないと、一生その組織は悪いままだと思う。怖い。
設計も保守もしない、開発フェーズだけ参画してきたようなプログラマに、この本を読んで行いを改善して欲しいと思った。
1
-
可読性の高く、変更が容易なコードを書くための方法をかなりわかりやすく書いてくれています。
読む価値ありです。
ただ量が多いので一度読んだだけでは全て把握することは難しいかもしれないです。
コードを書いて、読み直して、それを元にまた書いてを繰り返していくのがよさそうです。
0
