# 2021/6/26 メンター相談

###### tags: `メンター相談`,`6月`

## penpenの通知頻度のモデリング

- タスクのテーブルがあり、次回の通知頻度が格納されている。
- 送信時刻が現在時刻よりも前だった場合は、通知を送る
- いつ送るか、
- 送信するたびに次回送信時刻に100min足す
- できないこと
- ユースケースが限られる
- 毎週月曜日とかはできない
- 回収するとしたら、送信周期をcrontabに変える
- 次回計算するときに次回送信日はここだというのを決めていくことができる
- cronでほぼ全ての周期を表現できる
- [crontab.guru](https://crontab.guru/)
- cronの欠点
- 送信するタスクがどれかを調べるのが必要なので、それが大変
- cronの次回通知送信予告日をカラムに持たせる
- 下川さんテーブル
- リマインド周期
- 気になる
- パターンごとにテーブルが増える
- 増える場合に、このモデリングだとテーブルが増えるので、要件次第でこの設計を採用するかは検討必要
- タスク通知は、penpenと同じ
- 次回通知日のレコードをinsertする
- 失敗しようが、成功しようが増えていくイメージ
- 次回予告日を過ぎている場合、
- 履歴が混じってきてくる
- タスク通知テーブルで最新のものだけ取り出す場合
- 最新日時のみとってくるクエリを作るか、最新のものをとってくるviewを作るなどありそうだが、どうするのが良いか？
- どれだけ頻繁に読み込みが発生するかは気にするポイント
- 1つのテーブルでviewを使ったことはあまりないが、複数テーブルでのJOINする場合にview使う
- 今回だとインデックスを貼る方が楽そう
- 浦川テーブル
- 同じカラムだが、送信頻度変数が場合によって、意味が異なるので、この場合は、この変数はこの意味というようにロジックが発生してしまう

## SOLID原則に関して将来発生する未知の変更に対してどこまで対応するか

- ドメイン層とユースケース層は、須のjavascriptで描けるようにする
- classしか触らないようにする
- ドメインを見るだけだと、このアプリケーションがどのライブラリなどを使っているのか、をわからないようにしている
- RailsのActive Record
- ドメインが一番変えられる可能性があるので
- ②テストを絶対かく
- リファクタリングしやすいので安心感がある
- 仕様がどうなるかわからない場合は、めちゃくちゃかく
- インターフェースに変更を加えると既存テストは落ちる
- テスト用のFactoryメソッドを用意しておくと良い
- TestUtilの中にUserFactoryを作っておいて、Fakerのライブラリを使って引数なしで呼び出すと良さそう
- Railsなどだと用意されているかも
- FactoryPodというライブラリをよく使っている
- 指定なしでランダムな値を作ってくれる
- ドメインエンティティのインスタンスを作る際に、アプリケーションで新規作成する場合と、リポジトリから再構築される場合があるが、テスト用にインスタンスを作成したい場合に、リポジトリのFactoryメソッドを使っても良いのか
- 良いと思う。あまりやったことはないが
- 基本的にはやらなくても、普通にnewしたものをテストすれば、ユースケースは満たせそう
- DBに不正データが入ったときのテストはあまりしない
- Factoryパターンとはどんなものか？
- テストの時もよく使うし、productの時にもよく使う
- https://www.typescriptlang.org/play?#code/MYGwhgzhAEAKCmAnCB7AdtA3gKGtADgK4BGIAlsNMOhAC6KHC0qIAU+iZAbmLfNGjABbeAC5odTmgDmAGgKcefaGGliBhIcSQBKLAF9sh6mjoEkqNADEwTFgE9oAXmitBIgPzjJZGfNXwXhpaus4AfFi40IjwtISIGGjwAO5wFuhuwvwAPtnQAOSIYGgAJihC7vD5-mrQudAAjAAMTTpG2NgmZmUAyuWxABa+0g3OrnpOETh4XSgg8AB0ICjS7OnWtsyI9qw6bcY0tNC9-bRDMgBMY7vhkXjJvmXJC2DziLRryOg2dtu7+x0gA
- ③凝集度
- これはなんのクラスなのか言えなかったら、別クラスに分けようかなというのは考える
- 使いやすくなるし
- 副作用のない処理に設計する
- 引数を変えない処理
- データベース
- ①迷ったら多 vs 多にする
- クライアントの事業を理解する
- 企画会議に参加するとか
- できるだけクラスではなく、インターフェースに依存する
- インターフェースに依存していれば、他が変わっても変更に強くなる
- 共通の処理を別に切り出す
- 別のフォルダに切り出す。ドメイン層下のSharedとか。
- 細かく共通処理を分けたために、自分の意図通りに共通処理を使ってもらえてない問題がある（中野さん）
- 共通化したけど、気づかない問題
- 毎回の会議で共有する
- Slackで通知。既読が着くまでリマインドし続ける
- prahaでは毎週金曜でリファクタリングdayを設けていたことある
- 共通化したメソッドは、1つのユースケースに対してのメソッド名にすべき？あまり抽象化しないほうがよい？
- 社長と従業員があったときにそれぞれの共通メソッドを作るべき？
- 共通化したいものの1つ上位のインターフェースを作る
- javadocsのようなのを書くのは、メンテナンスがされなくなったりするので、あまりやらない
- なぜこんな書き方をしているのか、となることはコメント書く。リンク貼ったりする
- trycatchやloopが深くなった場合に、書いたりする
- t-wadaさんがおっしゃっていたが、why notの場合にコメントする
- データベースのコメントに対するコメントはあまり使わない
- railsだとschema.rbができるので、カラムのコメントが入っているとそれを見るだけでなんのカラムがあるかよく話かる
- コメントのメンテナンス維持がなかなかされないので、prahaではあまり描かない
- prahaでは命名第一！
- プロジェクトにはゆとりが必要
- 松原さんが重要と考える順番としては①②③