長いので章ごとにしてます。
9 設計の健全性をそこなうさまざまな悪魔たち
9.1 デッドコード
- リスト9.1 ifの条件に絶対合致しないデッドコードは…バグじゃないの？
if(false)とかの話かと思いました…。- バージョン管理システムありますもん、今更やりませんよね…？
- railsだと…
9.2 YAGNI原則
- これ重要…。
- つい、「こんなこともあろうかと…！」とカッコつけたくなりますが、いやいや…。
- 長い間同じプロジェクトにいれば、カッコつけで書いたコードが使われていないのをたくさん目撃してます…。
- 気をつけよう…。
- YAGNI原則は…上位工程にも言えますよね…。
9.3 マジックナンバー
- リスト9.2、ひどい。変数名も適当すぎて…。メソッド名だけでかろうじて読めるくらい。
- リスト9.3、主題の改善をめちゃくちゃはみ出してて、例としては適当でないような…。
- 突然こんな改善提案が来たらどうしていいかわかりません><
9.4 文字列型執着
- …そんな面倒なことをやる人いるの？
- フラグを数字の文字列にして、桁数で管理、も同じですかね。
- DBのテーブルの件数次第ではそういうことが必要なときもあるかもなぁ…。
9.5 グローバル変数
- 巨大データクラスもグローバル変数と同じような短所を持つ、というのは確かに、と思いました。
- 確かに知らず知らずのうちに作ってしまいそうです。
9.5.1 影響範囲を最小化するよう設計すること
- よく考えて設計しろとしか書いてなかった…。
9.6 null問題
- 物によっては毎回チェックするのでよいような気がしますが…
9.6.1 nullを返さない、渡さない
- 「装備なし」を装備…！
- ひとつのテクニックですね。
- これはこれであんまり直感的でないような気はします。
- アプリが落ちるような不具合は起きなそうですが…。
- 「装備なし」であることをチェックするコードを入れ忘れて表示がヘンになったりして、笑われるような不具合はボチボチ起きそう。
9.6.2 null安全
9.7 例外の握り潰し
- リスト9.14、本当に問題ないならコメントをつけて…！
- 処理を続けたいなら、エラートラッカーには投げて！
9.7.1 原因分析困難に陥り開発者を疲弊させる
- そういえば、どうして握り潰したくなるんでしょう🤔
9.7.2 問題検出時にけたたましく叫ばせる
- せやなぁ…という感じ。
9.8 設計秩序を破壊するメタプログラミング
- 個々の処理で使おうとしてたら大反対しますね…。
- いつ、どのオブジェクトに作用するとか、ちゃんと知って使いたいものです。
9.8.1 リフレクションによるクラス構造および値の変更
- え？こんなことするひといるの…？
- （できることを知っておくのは大事だと思います！）
9.8.2 型の強みを活かせなくなるハードコード
え？？こんなことするひといるの…？？- 全部手で書くのが面倒で、文字列でメソッド呼び出しをしたりすることがありました…。たしかにリファクタリングで抜け落ちそう…。気をつけます><
- （できることを知っておくのは大事だと思います！）
9.8.3 デメリットを理解し用途を限定すること
- 同意。
9.9 技術駆動パッケージング
9.10 サンプルコードのコピペ
- 内容をわかって組み込んで、というのはよく言う気がします…。
- そうしてしまう背景をもう少し解決したい気持ちです。
- あ…でも、software designのサンプルコードみたいのだと、とりあえず動かしたかったからそのまんま書いちゃったかも。これかな？
9.11 銀の弾丸
- お、おう、そうですよね！
- うちのチームは読書会…！
