本棚登録 : 
感想 : 
昨年のITエンジニア本大賞受賞作ということで気になっていたので、読んでみた。
悪いコード例が、見おぼえあるし、なんなら自分のコードのようだった…。
クラスの中のメソッドの返却値が、それ自身のクラスのインスタンスというやり方に驚いた。パフォーマンス的に問題ありそうと思ったけど、今時気にする必要はほぼないとのこと(組込みソフトウェアは別)
メンバ変数を書き換えるのは問題あるのか…。メンバ変数はできるかぎり不変にしたほうがいいらしい。
まあでも、確かに関数内以外で宣言された変数の変更は副作用になるだろうしね。一種のグローバル変数みたいなもんだし。
ファクトリメソッドの概念も面白い。コンストラクタをprivateにする発想はなかったけど、メンバ変数に入れる値が限られているなら、それもありか。
できるかぎり、プリミティブ型の変数を使わないという話もなるほどと思った。ただ、こうするとかなりクラスの数が多くなりそう…。まあ、今後の保守を考えるとそのほうがいいのかな。
switch文重複問題の解決に、interfaceを使う話、例に示された二つのクラスに、全く同じ名前のメンバ変数があって、それなら継承でいいのでは？と思ったら、継承はやめたほうがいいらしい。
オーバーライドで書き換えることが、不具合の原因になりかねないのだとか。今はそういう考えなのか…。
継承を使いたい場合は、委譲する(スーパークラスをインスタンス変数にしておく)という方法のほうがいいのだとか。普通に今の仕事のプロジェクトで、継承で実装してしまってるなぁ…。
本題ではないけど、nullを発明した、アントニー・ホーアという方が、10億ドルにのぼる損害をだしてしまったことで、謝罪したという話が面白かった。いわゆる、ヌルポというのは、例外エラーの代表格だしね。やっぱり、null安全の言語を使うのがいいのだろうなと思う。
関心事にふさわしい命名をするのがいいというのは分かるけど、なかなか難しそう。自分なら、普通に商品クラスを作ってしまうなぁ。予約品や発送品というクラスにしたほうがいいと。でも、連携はどうすればいいのだろう…。
モデリング設計については、テーブル設計についてもあてはまるのかな。それとも、データベースだと商品テーブルというのを作るのもありなのかな。
TDDの、テストを成功させる最低限のコードを書く理由がよく分かってない。エラーのままコードを書いて実装を進めるのはやめたほうがいいのだろうか…。
途中、「筆者はリファクタリング専門のエンジニアとして仕事をしています」と書いてあって驚いた。リファクタリング専門の仕事なんてあるのか…。
どおりで、これだけいろいろな視点からコード設計術について書けるわけだ…。
「木こりのジレンマ」の話は聞いたことがあるけど、本当そうだよなと思う。昨年から関わってるプロジェクトがまさにそうだけど、設計もろくにせずに、がむしゃらに頑張っていると、不具合だらけになる…。こないだ数か月遅れでリリースはしたけど、うまく動くのかと不安だ…。
レガシーコードに人は引きずられやすいという話は、本当、自分も反省しないといけないことだなと思う。
今年入った新人は、自分の書いたコードの改修をメインにやってくれているけど、テストコードもない分かりづらいコードでごめんと思う。
最後に、おすすめの設計本の紹介をされていたけど、気になった読んだことない本をまた読んでみようかなと思う。「Clean Code」とか「セキュア・バイ・デザイン」とか。この本より後に発売された本だけおｄ、今年の初めに発売された「Good Code, Bad Code」も気になってる。
本当、もっと設計を意識した開発をできるようになっていきたい。
1
- 感想投稿日 : 2023年11月4日
- 読了日 : 2023年11月4日
- 本棚登録日 : 2023年11月4日
みんなの感想をみる
