増田亨さんによる「設計の考え方とやり方」勉強会に参加して個人的に勉強になったこと



# はじめに
[増田亨さんによる「設計の考え方とやり方」勉強会](https://asken.connpass.com/event/254709/?utm_campaign=event_participate_to_follower&utm_source=notifications&utm_medium=twitter)に参加したので、
感想文がてら勉強になったことを残しておこうかと思います。
→　[勉強会スライド](https://speakerdeck.com/masuda220/she-ji-falsekao-efang-toyarifang)
# 目次
<!-- タイトルとアンカー名を編集 -->
1. [良い設計とは](#良い設計とは)
1. [データベース設計](#データベース設計)
1. [参考文献](#reference)

<!-- 各チャプター -->
<a id="#良い設計とは"></a>
# 良い設計とは
**良い設計とは、変更が楽で安全であること**とおっしゃってました。
この定義は、色々な設計本で語られているとおりですが、改めて残しておきます。

**なぜ変更に焦点をおくのかというと、市場・事業の変化があるから**
変更ができないと以下のデメリットがあります。
・事業の変化のスピード、変化のコストが増える
・開発者の成長を阻害する

**このデメリットの中で面白かったポイントがあります。それは、開発者の成長を阻害するというポイントです。**
私が携わったプロジェクトでは、機能の改修や機能追加という作業が大半でした。つまり、すでに構造が出来上がっているソフトウェアの開発に携わっていました。
私は設計や良いコードを書くことに興味があったので、その手の勉強をしています。
得た知識と照らし合わせると、**参画したプロジェクトのコードには悪い点や、こうしたらいいのにみたいな箇所が多々ありました。**
しかし、**テストコードもリファクタリングの時間もなく、そもそも開発の工数自体ギリギリみたいなプロジェクト**が基本だったので、
勉強したことを生かせないみたいな状態でした。

また、増田さんは変更をしていく中で、良い書き方や命名の仕方など自分の中の引き出しが増えていき、設計のスキルがあがるというようなこともおっしゃっていたので、**変更できるようにしておくというのはすごく大事なことだと再認識しました。**

<a id="#データベース設計"></a>
# データベース設計
個人的に、プログラムは書いてきましたが、データベースの設計からかかわることがなく、
良いデータベースの設計に関する勉強をしてこなかったし、設計本にはデータベースの設計について書かれていることがなかったので新鮮でした。（自分が本を探してないだけかも。最近一冊買いました。）

データベースの設計には、**ミュータブルなデータモデル**と**イミュータブルなデータモデル**の二つがあるらしいです。
ざっと特徴をあげます。
* ミュータブルなデータモデル
  * レコードの上書きが可能
  * Null許容
  * 削除フラグを使い、削除状態を管理
* イミュータブルなデータモデル
  * レコードの上書き不可(INSERTのみ）
  * Null非許容
  * 削除した、更新したとかを記録する

**イミュータブルなデータモデルという言葉自体初耳だったので、こういう考え方があるのかと感動しました。**
端的に言えば、UPDATEを使わない方針。
UPDATEは状態を更新するため操作が複雑になるからだそうです。
ミュータブルなデータモデルと違って、カラムに状態を持たないので、WHERE句が単純化されるという効果もあります。

**個人的に、イミュータブルなデータモデルにはメリットが大きいと思ったので、詳しく勉強したいなと思いました。**
増田さんの発表では以下のメリットを挙げていました。
* SQLが単純になる
* データベース操作プログラムが単純になる
* テーブルの状態を前提にした更新がなくなる

参加者の人たちの中にはイミュータブルなデータモデルについて、**変更を逐一記録するのでDBの容量を圧迫するのではないか？という質問**をしている人がいました。
対する増田さんの回答は、**利用者が多いシステムでない限り、最近の環境ではDBの容量がネックになることはない**ということをおっしゃられていました。

<a id="#開発の進め方"></a>
# 開発の進め方
開発を進めるにあたって、増田さんは**とっとと作って、とっとと成長させる**という進め方を推奨していました。
→[スライド](https://speakerdeck.com/masuda220/she-ji-falsekao-efang-toyarifang?slide=32)
変更が前提となるソフトウェアの開発は、最初にがちがちに設計していくのではなく、
**簡単な図などの情報を作ったらコードファーストで動かせるものを作っていく。**
この考え方について、こんなたとえ話をしていました。
A案、B案、C案でどれで行くか、会議を重ねて決定するより、簡単にA案、B案、C案を作って動かせるものをみて決めた方が早いし、良い決定ができる(うろ覚えですが、こんな感じのことをおっしゃっていました）

私は個人開発をしているのですが、個人的にこの考え方に感銘を受けました。
なぜかというと、**最初に開発に着手するまでの心理的負担が減る**ように思ったからです。
何事も始めるまでが一番腰が重いですが、**最初の設計をざっくりしたものに留めてコードを書いていくスタイルは、最初からがちがちに設計してコードを書いていくスタイルよりも心理的負担が少ない**と感じます。
**実際、作ってみないとわからない課題もありますし、設計に関しても、作りながら仕様の理解を深めたり、概念をとらえなおしたりしているうちに、さらにいい設計が思いつく**ということもあります。
なので、増田さんの考え方のコードファーストは個人的に取り入れていきたいとおもいました。
具体的取り入れるうえで、以下の技術があった方がはかどりそうです。
* IDEの使い方(基本、IDE使うはずなので特に勉強の必要なし）
* Githubなどのリポジトリ([gitflow](https://atmarkit.itmedia.co.jp/ait/articles/1311/18/news017.html)などのブランチモデルの知識はあった方がいいかも）
* CI/CD(自分も勉強しないといけませんが、[GitHub Actions](https://docs.github.com/ja/actions/learn-github-actions)が使えそう)
* コードを設計書・仕様書として書ける技術(EntityとかValue Objectとかクラス設計の技術)
* コードから関連図や一覧表を自動生成(個人的に一番勉強したい。増田さんはJIGを使ってた。[スライドP43](https://speakerdeck.com/masuda220/she-ji-falsekao-efang-toyarifang?slide=43)～[スライドP48](https://speakerdeck.com/masuda220/she-ji-falsekao-efang-toyarifang?slide=48))
* コンパイラやインスペクションツールで文書品質を保証



<a id="#reference"></a>
# 参考文献
* [増田亨さんによる「設計の考え方とやり方」勉強会](https://asken.connpass.com/event/254709/?utm_campaign=event_participate_to_follower&utm_source=notifications&utm_medium=twitter)
* [勉強会スライド](https://speakerdeck.com/masuda220/she-ji-falsekao-efang-toyarifang)
<!--
[増田亨さんによる「設計の考え方とやり方」勉強会](https://asken.connpass.com/event/254709/?utm_campaign=event_participate_to_follower&utm_source=notifications&utm_medium=twitter)
良い設計とは、変更が楽で安全

なぜ変更に焦点をおくのかというと、市場・事業の変化があるから(特に最近はサイクルが早い）

また変更ができないと以下のデメリットがある。
・事業の変化のスピード、変化のコストが増える
・開発者の成長を阻害する

プログラムの書き方として二つある
・トランザクションスクリプト方式
・ドメインモデル方式

トランザクションスクリプト方式では、以下のデメリットがある
・ロジックが断片化し重複しやすい
・ロジックの意味が分かりにくい

ドメインモデル方式では関連するロジックとデータを一つにまとめるので、上記のデメリットがない

作り方
とにかく作ってリファクタリングで改善していく
リファクタリングは大体以下の流れ
分割 → 分割意図が伝わるように命名見直し → さらに改善

データベース
任意の項目は別テーブルにする
NOT NULL制約を徹底

目標の仮決めをしてさっさと作って、改善していく
簡易なモデル図を作成
実装
文書はツールでコードから作る

てすとについて
ドメインモデルのテストは書かない(複雑な場合はのぞく）
アプリケーションサービスを中心に書く

継承よりコンポジション

説明書とか利用規約を読むとボキャブラリーが増える-->