Prismaを使ってみて分かった事と、ここ最近感じたプロジェクト開発での教訓的なもの
備忘録的な側面が多分にある。 みんなが興味ありそうなPrismaの話は頭に持ってきたので、それだけ読んで閉じてもらってもいいと思う。
HerokuとPrismaの相性があまり良くない
publicスキーマしか実質使えない
HerokuでDBを扱うとなると、Add-onでHeroku Postgresを使うことになる。 Heroku Postgresをアプリに追加すると、環境変数にDATABASE_URLが追加される。 schema.prismaにenv(DATABASE_URL)と記載すると、publicスキーマに対して定義が可能になる。 ここでDBにスキーマを新たに切ったとしたとき、環境変数と文字列を結合した文字列をenv()の引数に渡したい。 だが現状、引数に当たる箇所で演算はできない。
Heroku Connectとの相性が悪い
Heroku ConnectでSalesforceと繋いだ時にSalesforceスキーマが作成される。 Salesforce上の（カスタム）オブジェクトをHeroku Postgresに同期させる事ができる。 つまり、SalesforceスキーマにあるテーブルはSalesforce上で管理される。 Prismaで管理するテーブルとSalesforceで管理するテーブルがあり、そして（当然）プログラムからはその両方を扱わねばならない。 だがローカル環境で試験を行うにはローカルDBにSalesforceで管理するテーブルがないと試験できないので、Prismaでスキーマは作らないといけない。 Salesforceスキーマだけは必ず二重管理になってしまうので相性が悪いと思う。
ここからはここ最近感じたプロジェクト開発での教訓的なもの。Prismaの話は1mmも出ない。
テスト
コントローラのテストをするならサービスはモック化した方が良い
これはその筋の人にしてみれば当たり前かもしれない。 そもそも、コントローラとサービスの二重のテストになってしまう。 後述にもあるDBを繋いでの単体テストを行ってい場合は悲惨で、統制利かせないと悲惨な目に遭う。
DBを繋いだ単体テストにおいてはテストデータの管理がとても重要
双方が同一のテーブルに対してCRUD操作を行う場合を考えるとわかりやすい。 特に並列実行するテストフレームワークの場合、どっちが先に動いたかで結果も変わる。 そもそも並列実行を許容しないという手があるが、それにしてもテストケース実行都度、書き換えたデータを戻さないと同じ事が起きる。
テストコードがある安心感
テストコードが仕様を表し、そのテストコードに定義するケースを全てパスする限りは動作が保証される。 この安心感は結構すごいというのは書籍を通して知っていたが、体験してみると想像以上だった。 PMの方々は、テストコードを書くことの重要性についてご理解いただきつつ、スケジュール作成時には十分考慮いただきたい。 開発は数ヶ月だけども、運用・保守は何年もある。人間どうしても遠い未来の事に関する評価を下げがちだから難しいが。
設計
新しい技術を使うのはほどほどに
趣味と仕事は違うの一言に尽きる。 新しい技術は古いものより優れている面が多い反面、サンプル以上の実装を行おうとするとぶつかる壁が多い。 壁にぶつかれば調査して乗り越えていかねばならないが、その数が多いほど進捗に遅れが生じる。 大抵調査とはググって世界のツヨツヨエンジニアたちの叡智を拝借するのだけども、新しいほどそれが見つからない。 見つかったとしても未解決バグやfeature requestだったりなんてこともザラにある。 極端に保守的になれという訳ではない。時々に応じて塩梅を調整しないと開発メンバーの疲弊につながる。 現時点での自分の感覚だが、せいぜい1PJあたり1つといったところじゃないかなと思っている。 （コミッタのように、その技術について極めて明るい人なのであればその限りではないと思う）
「共通部品は必要になったら都度作ろう」
これは辞めておいた方がいいし、このセリフを聴いたら危機感をもった方がいい。 そもそも、必要になることが大凡目に見えてる物すら作らないのはただの先送りでしかない。 人間、余裕があると思うと大抵はそれを食い潰してしまう。 つまりはリファクタリングの時間なんてものは計画していない限りはないという事になる。 後に残るのは実装にばらつきがあるコード群のみ。保守する人は大変だ。
プロジェクト運営
少人数開発でもコミュニケーション不足は容易く起きる
最近、心理的安全性ってものについて学んでいる。 この心理的安全性ってのは、あったからといって何もかもが上手くいく銀の弾丸ではない。 ただ、これがないと知能労働の場においては必ずパフォーマンスが著しく低下するとの事。 心理的安全じゃないと、メンバー間で遠慮とか個人的な損得感情（怒られたくない、評価を下げられたくない等）が素直な意見や提案、都合の悪いことの報告を阻害する。 身をもってそれは体験したので、割とこの心理的安全性ってのの話は信じていいかもなって思っている。 最近よく耳にする報告・連絡・相談は上司が実践して醸成していくものって話も、これに近しい話なのではと思ったり。 心理的安全性も上司が形成するものだそうです。
