読書会自体はGW前にやっていたのですが、諸々あって書くのが遅くなってしまった…。
第9回の感想です。前回の感想はこちら。
会社のブログのレポートはこちら。
9章 オブジェクト指向開発のプロセス
- 開発の基本はV字モデルではあるが、そのサイクルが異なる。今はアジャイルで開発することが主流なので、同じチームで全部を担当することが普通になっている。大体うちでもそういうプロセスでやってる。
- しかし、ここに書いてある通り、分析・設計にほとんど時間をかけずにとにかくプログラミングするという流れはある。特に、Railsでは顕著ではないかと思う。ちょっと規模が大きくなるとコードの見通しが急速に悪化するというのは、見に覚えがある。
- ドメインモデルを中心にしたソフトウェアの考え方。従来の開発の仕方は、今いるメンバーは殆ど経験したことがないんじゃなかろうか？オブジェクト指向らしい開発の進め方について。設計した人が開発もするのでドキュメントの確認も減るし大変効率が良い。
- 口頭でのやりとりをラフスケッチとしてホワイトボードに起こしていくというのは、写真を撮るだけでいいしよくやっていた。うちの会社だとスマホで写真を撮って共有、がやりにくいが…。リモートワークが主流になった現在だと、そういうツールを使いこなせばいいのかもしれないが、あんまりやってない。Miroとか？一応MS Whiteboardはある。ペン付きのPCならいいんだけれど、Macだとそのあたり厳しい。
- ドキュメントに関して。データベースのテーブル名／カラム名とコメントは書くようにしている。I18nのデータを元にコメントにしていく仕組みを準備している。gemにしてもいいかもしれない。
- 全体を俯瞰するドキュメント。これはインセプションデッキと役割が似ている。時々見返したり、見直したりする必要がある。
- 技術方式のドキュメントもソースコードで表現できるというところ。Infrastructure as Codeの話。現代においては、この辺りはもう全てコード化しておくべきもの。学ばなければならないものが多い反面、自動化できることの恩恵は大きい。
- 分析と設計が一体になった開発のやり方をマネジメントする
- 受託開発の行うときに発注する側、受注する側で気を付けるべき点等が書かれているのはよい。準委任契約のほうがいいという点は、そうだろうなぁと思う。
- 進捗の判断…チケット単位でドメインオブジェクトを作るように組んでいけば、この通りに進捗管理できるんだろうか？ドメインオブジェクトの組み合わせて機能を作っていけるので、例え機能が未実装でも、ドメインオブジェクト作成の進捗があれば、進んでいるとみなせるということか。その発想はなかった。
- 品質保証について。ドメインオブジェクト単位で独立しているから、テストしやすく、ミスがあったとしても簡単に修正できる。
- 他の章にも書いてあったが、プログラミングスキルとドメイン知識の両方を備えていかないと、優秀なエンジニアとは言えないと思う。業務知識の勉強会を行うことも大事と思われるので、そういうことも計画していったほうがよいかもしれない。
雑感
読書会のメンバーは自社製品の開発をしているので、受託開発する際の契約に関するところは、「うーん？」という感じであった。設計と、設計レビューにもっと時間を割いて、熟練者の知見を吸収していったほうがいいんでないか？ということを話したように思う。大して設計せずにすぐ作り込んでから、実装に対するレビューをしてしまうとレビューの視点もブレるし、実装者もあんまり変更したくないもんだから設計がおかしいまま実現しようとしてしまいがちだと思う。わかったふりをせずに、貪欲に質問したほうがいい。みんな答えてくれるから。
「どうやって業務知識をつけていったんですか？」という質問があった。「扱っている製品が違うので、一概には言えないんだけれど、定例会のタイミングとかで疑問をぶつけたり、お客さんからの反応を聞き出したり、おすすめされた記事を読んだり等はしていたよ」という話をしたり等。先輩社員にドメイン知識をどうやってつけたのか？を聞いてみたら、ヒントがあるのではないか？と話したら「そういえばあんまり聞いたことがなかった」ということだったので、聞いてみよう！ということに。
