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

株式会社リゾームシステム企画・開発部第3グループの渡辺です。
今回は、読書会の第9回目のレポートになります。
前回のレポートは、こちらです。
tech.rhizome-e.com

9回目レポート

今回は、第9章「オブジェクト指向の開発プロセス」を読み進めました。

それぞれの感想・意見交換

開発の進め方

分析・設計にほとんど時間をかけずにとにかくプログラミングするという流れはある。
- 特に、Railsでは顕著ではないかと思う。ちょっと規模が大きくなるとコードの見通しが急速に悪化するというのは、身に覚えがある。
- コードの見通しが悪い
- 手がつけられないほど難解
もう少し分析や設計に時間をかけるのが良いのかもしれない..。

ドキュメントについて

開発の初期から利用規約・ユーザーガイドのアウトラインを作成しておき、開発が進むにつれ内容を充実させる、というのはいい考えだと思う。
データベースのテーブル名／カラム名とコメントは書くようにしている。I18nのデータを元にコメントにしていく仕組みを準備している。gemにしてもいいかもしれない。
- 何のためのカラムか、制約か、わかりやすくなる
技術方式のドキュメントもソースコードで表現できる(Infrastructure as Code)
- 現代においては、この辺りはもう全てコード化しておくべきもの。学ばなければならないものが多い反面、自動化できることの恩恵は大きい。
ソースコードがドキュメントの代わりになる
- ドメインオブジェクトのクラス名等と業務の関心事が一致してれば可能
- とても魅力的だが、テスターの人にもある程度の知識が必要になる（IDE使えたりとか）
- 技術者ではない人向けには別途ユーザーガイドなどを用意すると良い
- ドメインモデルで設計ができれば、コードがドキュメントみたいなことが実現できる

情報共有の方法について

口頭でのやりとりをラフスケッチとしてホワイトボードに起こしていくというのは、写真を撮るだけでいいしよくやっていた。
- リモートワークが主流になった現在だと、MiroやMS Whiteboard等を活用するのもいいかもしれない。
ラフスケッチ良さそう
- 今は口頭とかテキストベース
  - イメージしにくかったり見落としがあったりとか

ドメイン知識について

オブジェクト指向の開発を進めていく上で業務の理解は必須になっている
分からないことは聞く。分かったふりはしないこと。
- どのようにしてドメイン知識をつけたか、同じチームのメンバーに確認する
他の章にも書いてあったが、プログラミングスキルとドメイン知識の両方を備えていかないと、優秀なエンジニアとは言えないと思う。業務知識の勉強会を行うことも大事と思われるので、そういうことも計画していったほうがよいかもしれない。

まとめ

本章では特に「ドキュメント」「情報共有」について、今までの経験でどうした方がいいのか答えが出ていなかったのですが、答えを見つける手がかりを得ることができました。
技術者向けには、ドメインモデルでの設計やInfrastructure as Codeにより、ソースコード自体をドキュメントとし、技術者以外の関係者との情報共有は、「利用者向けのドキュメント」や「画面・帳票」をメインに利用できるようしていきたいです。

現在実施している「現場で役立つシステム設計の原則」読書会は、ついに次回の第10章で最後となりました。
改めて今までを振り返り、今回得た知識を業務で活用して行こうと思います。