はじめに
増田亨さんによる「設計の考え方とやり方」勉強会に参加したので、
感想文がてら勉強になったことを残しておこうかと思います。
→ 勉強会スライド
目次
良い設計とは
良い設計とは、変更が楽で安全であることとおっしゃってました。
この定義は、色々な設計本で語られているとおりですが、改めて残しておきます。
なぜ変更に焦点をおくのかというと、市場・事業の変化があるから
変更ができないと以下のデメリットがあります。
・事業の変化のスピード、変化のコストが増える
・開発者の成長を阻害する
このデメリットの中で面白かったポイントがあります。それは、開発者の成長を阻害するというポイントです。
私が携わったプロジェクトでは、機能の改修や機能追加という作業が大半でした。つまり、すでに構造が出来上がっているソフトウェアの開発に携わっていました。
私は設計や良いコードを書くことに興味があったので、その手の勉強をしています。
得た知識と照らし合わせると、参画したプロジェクトのコードには悪い点や、こうしたらいいのにみたいな箇所が多々ありました。
しかし、テストコードもリファクタリングの時間もなく、そもそも開発の工数自体ギリギリみたいなプロジェクトが基本だったので、
勉強したことを生かせないみたいな状態でした。
また、増田さんは変更をしていく中で、良い書き方や命名の仕方など自分の中の引き出しが増えていき、設計のスキルがあがるというようなこともおっしゃっていたので、変更できるようにしておくというのはすごく大事なことだと再認識しました。
データベース設計
個人的に、プログラムは書いてきましたが、データベースの設計からかかわることがなく、
良いデータベースの設計に関する勉強をしてこなかったし、設計本にはデータベースの設計について書かれていることがなかったので新鮮でした。（自分が本を探してないだけかも。最近一冊買いました。）
データベースの設計には、ミュータブルなデータモデルとイミュータブルなデータモデルの二つがあるらしいです。
ざっと特徴をあげます。
- ミュータブルなデータモデル
- レコードの上書きが可能
- Null許容
- 削除フラグを使い、削除状態を管理
- イミュータブルなデータモデル
- レコードの上書き不可(INSERTのみ）
- Null非許容
- 削除した、更新したとかを記録する
イミュータブルなデータモデルという言葉自体初耳だったので、こういう考え方があるのかと感動しました。
端的に言えば、UPDATEを使わない方針。
UPDATEは状態を更新するため操作が複雑になるからだそうです。
ミュータブルなデータモデルと違って、カラムに状態を持たないので、WHERE句が単純化されるという効果もあります。
個人的に、イミュータブルなデータモデルにはメリットが大きいと思ったので、詳しく勉強したいなと思いました。
増田さんの発表では以下のメリットを挙げていました。
- SQLが単純になる
- データベース操作プログラムが単純になる
- テーブルの状態を前提にした更新がなくなる
参加者の人たちの中にはイミュータブルなデータモデルについて、変更を逐一記録するのでDBの容量を圧迫するのではないか？という質問をしている人がいました。
対する増田さんの回答は、利用者が多いシステムでない限り、最近の環境ではDBの容量がネックになることはないということをおっしゃられていました。
開発の進め方
開発を進めるにあたって、増田さんはとっとと作って、とっとと成長させるという進め方を推奨していました。
→スライド
変更が前提となるソフトウェアの開発は、最初にがちがちに設計していくのではなく、
簡単な図などの情報を作ったらコードファーストで動かせるものを作っていく。
この考え方について、こんなたとえ話をしていました。
A案、B案、C案でどれで行くか、会議を重ねて決定するより、簡単にA案、B案、C案を作って動かせるものをみて決めた方が早いし、良い決定ができる(うろ覚えですが、こんな感じのことをおっしゃっていました）
私は個人開発をしているのですが、個人的にこの考え方に感銘を受けました。
なぜかというと、最初に開発に着手するまでの心理的負担が減るように思ったからです。
何事も始めるまでが一番腰が重いですが、最初の設計をざっくりしたものに留めてコードを書いていくスタイルは、最初からがちがちに設計してコードを書いていくスタイルよりも心理的負担が少ないと感じます。
実際、作ってみないとわからない課題もありますし、設計に関しても、作りながら仕様の理解を深めたり、概念をとらえなおしたりしているうちに、さらにいい設計が思いつくということもあります。
なので、増田さんの考え方のコードファーストは個人的に取り入れていきたいとおもいました。
具体的取り入れるうえで、以下の技術があった方がはかどりそうです。
- IDEの使い方(基本、IDE使うはずなので特に勉強の必要なし）
- Githubなどのリポジトリ(gitflowなどのブランチモデルの知識はあった方がいいかも）
- CI/CD(自分も勉強しないといけませんが、GitHub Actionsが使えそう)
- コードを設計書・仕様書として書ける技術(EntityとかValue Objectとかクラス設計の技術)
- コードから関連図や一覧表を自動生成(個人的に一番勉強したい。増田さんはJIGを使ってた。スライドP43～スライドP48)
- コンパイラやインスペクションツールで文書品質を保証