# 2021/07/17 メンター相談 ###### tags: `メンター相談`,`7月` ## TypeScript以外の言語で〇〇ステータスをどう表現する？ [課題の進捗ステータスは"未着手", "レビュー待ち", "レビュー完了"のいずれかであること] を表現するときに文字列リテラルのUnion型を使って以下のように書きました。 ```typescript= type Status = "notStarted" | "waitForReview" | "reviewComplete" class TaskProgressStatus { constructor(public value: Status) {} } ``` 1. このような書き方はしますか？ 2. 文字列リテラル型、Union型が無い言語ではどのように表現しますか？ (Enumを使う？) 3. Go言語 (Enumが無い) では、どのように表現しますか？ 文字列リテラル型で書くと、補完が効くので書きやすい、ビルド時にチェックできるなどの利点がありますが、その他の言語ではどのように書くのかが気になりました。(特にGo言語) --- 1. - Prahaでもこの書き方を使っている 2. - Enumを使います 3. - 自分でswitch文を書くなど自作している人が多い - https://ken-aio.github.io/post/2019/01/21/golang-enum/ - https://mattn.kaoriya.net/software/lang/go/20141208093852.htm - バグの予測可能性が向上すると考えられるので、堅牢なサービスを作る場合に有効 ## Prismaについて質問です。 - Prismaはmigrationの実行までは自動で行ってくれますが、DBの作成自体は手動で行わないといけないという認識であってますでしょうか？ - また、実際に実務で使われる時には環境を立ち上げる度に、DBのコンソールで毎回create database をされているのでしょうか？ https://www.prisma.io/ --- - DBの作成は他の手段でやる必要がある - Teraformで定義して自動でやる - teraform apply - そんなに多くない場合手動でやってもいいかも？ (本番環境と開発環境ぐらいなら) - Local環境の場合はDBをDocker化しておく - 中身を初期化したいときにdockerは楽 (イメージとコンテナを削除するだけ) - MySQLはダメかも？ ## Express + TypeScript を使って新しくプロジェクトを立ち上げる時に、参考にしているリポジトリなどがありましたら教えていただきたいです！ --- - あまり思いつかなかった - イチオシ → コントローラだけNest.jsを使う ## その他 - コントローラー層にあまりテストを書きたくない話について - とはいえ最終的なアウトプットをテストしたい (nakanoさん) - noteの事件もある - → ROI次第 - 直しやすさ(?) - 起きたときのインパクト - どれだけ起こりうるのか - レスポンスオブジェクトでwrapすればまるごと漏れ出すことはなさそう - やはりプラハではあまり書いていない - Prismaには2種類のDB定義ファイルがある - クライアントはschemeを見に行く - データベースはmigrationを見に行く - DDDの特大課題 - 普段コントローラーから作ることが多い (furukawaさん) - DBとコントローラーどちらを先に作る？ - 設計(ドメインモデリング), ユースケースの洗いだし → データベース → (散) → コントローラーなど (matsubaraさん) - データベースが先のほうがイメージしやすい - チームで開発するとき競合しやすいので先に一緒にデータベースを作るほうがやりやすい - DBに値が保存されたことのテスト - JavaではDBUnitがある - データベースの差分比較する - matsubaraさん (JavaScript) - 直接Prismaのメソッドを使用してDBの値を読み出して整合性があるかどうかを見る - 良くない → Repositoryを使用して読み出す - Repositoryの実装が間違っているときに影響を受けてしまう - 工数見積 - 相対見積もり (ストーリーポイント) を行っている - プランニングポーカーを行うことで、チーム間の認識を確認する - `機能`と`期間`のどちらかを固定するともう片方は伸び縮みする - やるissueの完了条件をすり合わせておく ← すごく大事 - 横スライス - フロントエンドとバックエンドに分ける - → つなぎこみを誰もやっていない！が発生する - → ユーザーが機能を使用できないのに完了したことになってしまう - 縦スライス - フォローできるを細かいユーザーストーリーに分割する - 大事 → 完了定義をユーザーが目に見える形で検証できるものにする - 例: ボタンを押したらこの画面に遷移する - Cypress TDD ？！ - 完了条件が明確になるので良さそう - 集約 - 集約内は絶対不整合はないことを保証する - 「この整合性が破綻したらあなたのサービスは終わりますか？」という質問を考える - 例: 銀行預金 - 大抵はそこまでではない場合が多いので、小さくなることが多いかも？ - コツ → できるだけ小さくしよう - その上で、複数集約をまたぐ整合性をどう確保するかを考える (妥協含む) - ユースケースメソッドをまるごと@Transactionで囲むこともある - 人数 ・ 名前 を別の集約にすることもある (どんな例でしたか?)