modeling-how-to-learn.connpass.com
こちらのイベントに参加してきたので、会の様子と感想を書いていきます。
会で印象的だったこと
「普通の設計」をするということ～綿引琢磨さん～
綿引さんにとっての普通の設計とは、「美しいコードを探求するための営み」だと言うことです。
美しいコードを探求するためには、以下のステップを踏むということです。
1. 脳内でイメージを作る
まずは、コンテキスト*1に合わせてどんな役割のオブジェクトがいてどんな振舞いをして、どう相互作用するかを考えるそうです。
2. コードを書く
次に、脳内テストしながら(後述しますが脳内テストするためにシンプルなクラス構造を心掛けているようです)、違和感がないかを自問自答するそうです。
違和感がある場合は、”クソコード”とコメントで書いたり、本当に耐えられない時は全消しして1のステップに戻るそうです。
3. クラス図に起こす
次のステップとして、静的構造として美しさがあるかを確認*2するということです。
なお、綿引さんはクラス図を作る際に自動生成ツールを使わないということです。(配置や依存が意図通りにできるため)
4. 試行錯誤する
2で書いたコードと3のクラス図を見ながら、自分の書いたコードにフィードバックをしていき、新たな気づきやイメージをコードに加えていくということです。
5. 繰り返す
2回～4回位、1～4のステップを繰り返すということです。最初に考え付いたことは大体間違っているため、繰り返すことに意味があるという話でした。
こうして美しいコードを書いていくということですが、美しいコードの条件としては、綿引さんは以下の条件を大切にしているということです。
・簡潔さ
自分が脳内テストできること、50行以内、パッケージインポートは(java.*を除いて)3つまで、フィールドは3つまで、メソッド内は5行まで(基本的には3行)
・統一性
表現がぶれていないこと(ドメイン用語、同一の振舞いに対して異なる名前をつけない)
・文章として読めるようにする
コードが文章に近い形で読めるようにしているか？(streamやUtil系は使わない)
・テストしやすさ
テストは書かないけど、テストのしやすさは大切にしている。
採番・日付系を内部生成しないことやテストしやすい構造を作ること...
・形式美
見た目が直感的に美しいか(これまでの項目を守れていれば大体美しくなる)
・パッケージング
単なるグルーピングになっていないか？構造や境界を表現できているか？
ただ、ここまで美しいコードを意識してきても、実際の現場はそうはいかないということで、そうした現場で綿引さんが意識していることを最後にまとめてくださいました。具体的には、以下3つを心掛けているということです。
- デザインパターンをはじめとしたパターンは、なるべく使わない
- 動いて喜ぶのではなく、細部(例外クラス...)まで徹底的にこだわる
- クソコードを許容する。常に美しいコードはない。(時間と共に劣化するものだと理解しておく)
ふつうの設計の基本要素～irofさん～
続いてふつうのプログラマのirofさんからお話がありました。以下、話されていたポイントをどんどん書いていきます。
ふつうに設計する
驚き最小の原則で、目立たない設計がふつうの設計で、当たり前のことが当たり前にできていることをirofさんは大事にしているということです。*3そのため、「ふつうのことしかしないですね...」という言葉はirofさんにとっては落胆の言葉に感じないということでした。
また、プログラミングをしている以上、コードを参加させながら設計するのはふつうのことだと考えているというお話でした。
設計はモデリング
irofさんにとって、設計はモデリングの一種で、モデリングと同じモデルになるということです。(モデリングは設計ではないということでした)
設計外の文書化は手を抜きたい
設計に関わらない文書化はやりたくないとうことです。ただ、文書化自体は大事だと思っていて、例えばダイアグラムを書かないとかは違うそうです。
過去の言語化は役立つ
自分が考えたことはそれを言語化しておくと、後々役に立つよというお話をされていました。
設計をどう進めるか
まず頭の中で考え、その後に自然言語とか制約の少ない道具(ホワイトボード...)を使いながら設計し、UMLを基に設計し、コードを書いて動かしていきながら設計する、というステップを踏むそうです。(制約の強度を強めていくイメージ)
強めの制約があるツールの活用
特定モデルの導入をする時は、強い制約のツールを導入することをお勧めするという話でした。
自由に書けてしまうことで、モデル本来の力を発揮できなくなることを気にされているそうです。
制約を持ち込む
後々にやってくるであろう制約を早めに持ち込むことで、フィードバックを早くもらい、手戻りを結果的に減らそうとされているそうです。
この結果、パターンの見出しなどのブレイクスルーが期待できるという話がなされていました。
なんでもモデリング
身の回りの事象など、とりあえずモデリングしてみる練習をされているということです。(アレクサに暖房をつけてもらおうとしたらつかなかったなど)
こうして楽しむことが、モデリングの上達につながるということです。
名前重要
同じものは同じふるまいの名前にしたり、いまいちな名前ならいまいちな名前をそのままつけておいたり(hogehogeなど)、パターンを名前に付けないようにしたり(xxManagerなど)、徹底的に名前に拘るということです。
ふつうのUMLやERD
コードで追いきれなかったら欲しくなるようなUML(ERD)や、初見でもUML(ERD)であることが分かることをふつうのUML(ERD)として考えているそうです。
一方、常にUML(ERD)に完全準拠したり、バージョンや歴史を語れるほど理解することはふつうではないということです。
設計の勉強
とにかくやること、という話にはなってしまうということですが、irofさんがやっている例として、
- 本を読む(カタログ本で手札を増やす)
- 分からない言葉が出てきたら調べる
- 何回も出てきた概念は勉強する
を挙げてくださいました。
雑談
設計に目覚めたタイミング
irofさんは、大きな機会があって設計に目覚めたのではなく、小さな積み重ねがあって今に当たったということでした。springやJUnitをはじめ、コードをひたすら読んでいくということもしたそうで、そういったものの積み重ねがあるかもしれないというお話をされていました。
綿引さんは、オープンソースを中心にコードを読む機会が多かったので、自然と設計になじんでいたようです。*4
また、(怖い先輩から)UMLの本をもらった時期と(変なリーダーから)ひたすらクラス図を書けと言われた時期が近く、そこで設計の力がついたかもしれないと言っていました。
増田さんが見る2人の共通点
ソースコードをまず書いてみて、実際に動かしてみて、コードや図からフィードバックをもらうということを当たり前のようにやっているのが増田さんにとっては印象的だということです。
そのため、普通にやり直し(1からソースコードの書き直し)をするようです。
普段のコミュニケーションとコードの関連性
綿引さんは文章のように読めるコードを目指しているということもあり、「自分の考えていることを明確に伝えたい」という意思を持っている人とそうではない人の違いは、コードに結構はっきりと表れることを最近良く感じているそうです。
会全体を通した感想
綿引さんとirofさんが考えている「ふつう」のことがたくさん知れてとっても面白かったです。
(javaチャンピオンとかと比べた時に)ふつうな人が、実際にどんな風にプログラミングや設計をしているのか、という話を聴く機会は少ないので、学びが多かったです。
綿引さんとirofさんの優しい口調は、心にすっと入ってくる感じがして、話も聞きやすかったです。
