勉強会での内容を気になったポイントに絞ってまとめ、僕の解釈や感想も書いてみました。今まで僕が参加した回の現場から学ぶモデル駆動設計の勉強会での学びや気付きなどについてまとめ記事を作ってみました。琢磨さん)>>発表資料テストコードは書かない派で、必要な時は渋々書く!!とのことでした。脳内でオブジェクトたちを妄想して動かしてテストする→コードを書く→クラス図に書く→配置や想定外の依存確認・修正→クラス図での発見をコードに反映という流れで設計をしている。(2周3周とこれを回す)まずは妄想からスタート。普段からソースコードめちゃくちゃ読んで、読むときにには脳内でいろんなオブジェクトが登場してやりとりしてるからそんな感じでやれるんだろうなという印象でした。美しいコードとは簡潔で統一性がありテストしやすく形式美であること簡潔というところで1クラス50行、読み込みパッケージ3つ、フィールド3つ、メソッド5つを目安にされているそうで、その方針だと1クラスであれもこれも詰め込んで無茶苦茶なクラスにはならないのだと思います。1クラス50行に抑えているから脳内でオブジェクトの妄想ができるし、テスト書かなくてもいいくらいシンプルになっているのかなと思いながらこの話を聞いていました。手続き的に書かないようにとかネスト深くならないようにと言う話・・・・この辺りは普通の話だったので少し安心でしたが、、、やはりこう言う当たり前のことを当たり前に一貫してやれることが美しいコードにつながり、基本的だけど一番重要なことなんだな。パッケージングはコードの表現と同じくらい重要で、構造、境界、カプセル化など意識してパッケージングを考えられるかどうかで、プログラマーとして差が出る。言われると、見直してみようと思います。このように考えられているのはOSSのコードを読み込んで、パッケージングがカチッとされているのとそうでないのとを見比べた経験があるからなのだろうなと思いながら話を聞いていました。勉強するものは取捨選択(異なるコンテキストで3回出たものは勉強するとか)現場での設計経験だけでなく、設計やモデリングの引き出しを増やして、その引き出しを使って設計の良し悪しを判断できるようになっていく必要があるのだと感じました。勉強に使える時間は限られるので、取捨選択をどうしていくかというのも意識しましょうね。設計のコアは名前付け。同じ振る舞いのものには一貫して同じ名前を、モデリングで付けた名前を一貫してコードでも利用。自分の設計を見つめ直していくか。本を読んだり勉強会参加したり、ライブラリやフレームワークのコード読んだりを積み重ねて設計ができるように。(irofさん)性能最優先で動いて性能が良ければいい。いうところからカオスなコードのリファクタを通じて設計を意識するように。亨さん)gradleのコードを読んで美しいコードに出会えて設計への意識が変わった。自分の考えを人に正しく伝えられる文章力がある人はコーディングでも人に正しく伝えられる。(増田さんOracleだったんだ。現場で設計することが設計の力をつけるのは一番大事くらいに考えていましたが、それだと、自分の設計の引き出しはなかなか増えない。OSSなどのある程度規模の大きいソースコードをざっくりとでも読む。勉強会や設計やモデリングの本を読む。実践して設計の良し悪しが比較できるくらい設計の引き出しを増やすことが重要。いうように、考えを改めるべきだと今回の勉強会を通じて感じました。僕は現場で性能重視でとにかく正しく性能良く動いて、納期守れれば良い。いう考え方で開発の旗振り役をやってしまっていましたが、、、それだと今日あったふつうの設計にはまだまだ程遠いんだなと。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。