こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
タイトルの通り、オブジェクト指向のこころを読んでいくイベントです。
今日は第3, 4章を読んでいきました。
会の様子
第3章の感想
最初に、第3章で問題として提示されている優先度の付け方に関しては、実際の現場でも起きそうだし、これなら変更に強いと言い切れるようなよい実装方法がぱっと思いつかないなという話をしていきました。
また、3.5に関しては、オブジェクト指向を使えば変更に強い設計ができるというつながりがやや雑な気がするという話や、現在の状態を持つというのは具体的にどういうことなのか？という話をしていきました。
3.5には、フィーチャーを整理したクラス図もあったのですが、この後の展開からしてフィーチャーを抽象化するのはいいアイデアではないという話が出てくるので、この図がなんであるのか？という話になり、ベンダーが提示してきたものであり理想を書いたクラス図に過ぎないのではないかという話で落ち着きました。
第4章の感想
最初にクラス図を見たときに、「これはフィーチャーが増えていくにつれて組み合わせ爆発が起きそうで明らかに拡張しにくそうだけど、なんでこの本はこの解決策を提示しているんだ...?」と思ったので結果的には肩透かしを食らったという話が出ていました。
また、直感とは？という議論になり、言語化できるものだけど現時点ではできていないことで直感だと思う場合(循環的複雑度が高いなど)と、純粋なコードの美しさといった言語化も難しい場合の2パターンがありそうだよね、という話をしていきました。美しいコードでは、凄腕のエンジニアが美しいと感じるコードの話(専門知識や複雑なアルゴリズムを駆使しないと解けないと思っていた問題を、数行で解決してしまう)をしていきました。
第3章の応用問題に関して議論
「ジオメトリに関しては、v1にしてもv2にしても抽象化できるが、フィーチャーレベルだと属性も責務も違うので、そもそも抽象化できるようなロジックがないため」というのが回答として出てきました。
同じ「図形」だからというレベルの根拠での抽象化は危険だよねという話や、実際の現場で近い場面に出くわした話の共有などがありました。
第3章のあなたの意見に関して議論
ユビキタス言語は作っても消えやすい(定着しにくい)というのと、ユビキタス言語は部署が変わると使えなくなることに注意しないといけないという話が出ていました。
第4章の応用問題に関して議論
「ジオメトリレベルで抽象化を実施し、スロットレベルでV1, V2に対応するクラスを作った。凝集度が低く結合度が高いコードになっており、フィーチャーが増えた際の拡張が大変なため、妥当な実装方針ではない。」というのが回答として出ました。
第4章のあなたの意見に関して議論
1に関しては、同意する意見が多く出ていました。
自分たちが働いている現場は不確実性が高い状態なのを想定していることや、知識を蓄えた後の自分の方が賢いからというのが理由としては挙げられていました。
その後は、本書の時点での「詳細に踏み込む」とは具体的にどんな行動を指すのか？という話になり、
- ベストな変数名にこだわる
- 実現するアルゴリズムを考える
- DBのテーブルのカラムの設定を考える
- マイクロサービス化を考える
というのが例として挙がっていました。
2に関しては、かなり微妙なラインだという話が出ました。
発想のスタートが直感で、その直感をみんなで深掘りして回答を導き出すというのはいいことだし実際にやる*1けれども、直感を理由に改修や方向転換を迫られるのは非常に厳しいという話が出ていました。
併せて、自分自身が違和感を持った+違和感の理由が直感しかない、という場合は、(直感ではなく理由を言語化することは試みる前提で)違和感があることをはっきりと言わないといけないよなあというのも話として出ていました。
会全体を通した感想
今回もまだ実装部分の話は少なく、早く本題(？)であるデザインパターンの話に移りたいという声もありましたが、結局議論は盛り上がり、今回もイベント終了時間をオーバーして話をしていました。
特に直感の部分は大分話が盛り上がっていて、本書の主張に理解は示しつつもなかなか従いずらい側面はあるんだなあというのを実感しました。
