Implementation Patterns勉強会
今日から勉強会開始。今日は4章まで。
立ち上がりは静かだったが、だんだん議論が盛り上がっていった。
- プログラムはdetailばかりになりがちだが、conceptも理解できるように書かれなければならない。←難しい!
- たとえ開発担当が自分1人だけでも他人に読みやすいコードを書く必要がある。そうしないとずっとそのコードの保守を自分がやらなければならなくなる。
- Kent Beckが柔軟性のことを述べるとは思わなかった。XPな人なので柔軟性に対しては"YAGNI"という考えだと思っていた。
- Javaのアノテーションは有効だけど、コードがシンプルになってもアノテーションが複雑になっては意味がない。コードがシンプルだけどもXML定義ファイル地獄に陥る場合も同様。
- 関連するデータ群は極力1つにまとめた方がいい。本書での例では金融商品が金額と通貨種別を持っていてそれらを一緒に変更するのであれば、Moneyのようなヘルパーオブジェクトにした方がよいとある。確かにこうしておけば属性が増えても対応は容易。もし、金額と通貨種別をセットで渡すメソッドを作っていたら、追加した属性を渡せるようにするためにメソッドを使っている箇所を全て修正する必要がある。
- Kent Beckがコストのことを述べるとは思わなかった。
といった意見が出た。
価値とか原則とか出てくるところはKent Beckらしいよなあ。
そんなこと考えながらプログラミングしている奴なんてほとんどいないけど。
でも価値や原則はすごく大事。
こういったことを意識しているかいないかでコードの出来に大きな差が出ると思う。