「現場で役立つシステム設計の原則」読書会レポート vol.1

株式会社リゾームシステム企画・開発部第4グループの尾古(@patorash)です。

先週から、社内の有志で新たに読書会を始めましたので、それをレポートしていきたいと思います。

読書会の題材

読書会の題材として選んだのは、現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法です。

作者:増田亨
技術評論社

こちらを選んだ理由ですが、読書会は今までも何度かやっていますが、その都度、具体的な技術の本、開発手法の本を交互に採用しています。その中で、今後の直近の開発で役立ち、且つ、技術者として長期的な視点で使える視座を与えてくれるのではないかということで、この本の採用を決めました。

読書会の進め方

開催頻度ですが、週に1回、1時間程度としています。読書会の進め方ですが、

当日までに事前に章を読んでおく
感想や疑問点をまとめる
読書会当日、感想をそれぞれ発表する
意見交換を行う
まとめをYammerにアウトプットする

としました。YammerはMicrosoftがOffice365で提供している社内SNSです。

これまでは交代しながら音読していくスタイルの読書会を行っていたのですが、読むこと・進めることに集中しがちで、本来やりたかった読書後の議論が疎かになっていると感じていたため、今回からやり方を変えることにしました。

1回目レポート

1章ずつ進めていくことにしましたので、初回は第1章の「小さくまとめてわかりやすくする」でした。参加者は6名の予定でしたが、業務の都合で不参加になった方もいて、4名で開催しました。

それぞれの感想

まず、それぞれの読書の感想をまとめます。

変数を使い回していたことがあったので、気をつけていきたい。
新しく型(クラス)を作って値の制限をしているところがRailsのモデルでバリデーションしているところと似ていると思った。
重複したコードをなくすのはいいけれど、たまたま同じようなコードがあるのを無理やり共通化するのはよくないとプリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則に書いてあったのを思い出した。*1
読みやすいコードの話などをまだあまり知らなかったのでよかった。定期的に読み返したい。
変更が大変なプログラムのアンチパターンについて書いてあって、担当プロジェクトでもよく見かけるケースがあった。
Railsだとクラスを増やしにくい印象がある。わかっていてもこのように進めにくいのでは？Railsは大きなプロジェクトを作るのに適していないなと感じた。
弊社ではメソッドへの切り出し、クラスへの切り出しは既によくやっている手法である。切り出すと、テスト可能になる。
バリューオブジェクトの定義がドメイン駆動設計の根幹になりそう。
Rubyでも3.0以降はRBSで型の恩恵が受けられるので、バリューオブジェクトを充実させるのはよさそう。

意見交換

感想を聞いた後、本を見返しながら、意見交換を行いました。

Railsでもcomposed_ofを使って値オブジェクトとカラムのマッピングできるとパーフェクトRuby on Railsに書いてあった。*2
無理やり共通化しているコードを担当プロジェクトで見たことがあった。変数の初期化がブロックの外で行われていたため、わかりにくかった。
before_actionで変数の初期化をする件について
- シンプルなsetくらいであれば許容できる。
- アクション毎にメソッドを呼んで変数の初期化をちゃんと行っていることを確認したい。そうでないと、いちいちbefore_actionで初期化されているかどうかを確認しなければならなくて面倒。
- before_actionでやるのは認証・認可などだけにしてほしい。
- 他のbefore_actionが、更に他のbefore_actionでの変数初期化に依存しているケースがあった。
値オブジェクトはRailsならばどこに置くべきか？
- app/domains/がいいのではないか？
  - app/以下は自動的に読み込まれるため。
プログラミング初心者は逆に値オブジェクトを煩わしく感じそう。
業務アプリケーションでよく使う値オブジェクトの表を見ながら…
- こういうのはよく使うから、プロジェクト毎に作らずに共通化できたらよさそう。
- よく姓名を扱うのだが、PersonNameクラスを作りたいと思った。
- 会社用のライブラリ置場を作りたい。そこに値オブジェクトを定義したgemを登録していくと工数削減できそう。
  - GitHub Packagesが使えそうか検討してみよう。*3