# 2021/02/28 メンター相談

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

## 単体テストの説明文は英語と日本語どちらが良いか？

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/reczU3z3i7Maci7pV)

- prahaでは日本語
- コミットメッセージも日本語
- チームでは日本語母国語の人が多い
- パッとみた時に理解しやすい
- 翻訳→理解→翻訳で質が落ちていく
- 英語派の意見がいいのはなぜ？
- プログラムの中に日本語が混じっているのは変？
- 関数名・変数名
- ローマ字表記について
- M&Aのサービス：専門用語が多い -> ローマ字を使った
- **理解しやすい方を選ぶ**

## axiosをそのままDIするのではなく、インターフェースを介してDIしたほうがより疎結合になるのではないか？

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/rec8o66Zz0UhzOPY1)

- axiosの詳細に依存してるのではないか? HttpClientのInterfaceを渡すべきですよね?
- その通り
- prahaでもそのようにしている
- (中野さん) DDDの書籍を読んでいて
- > データソースレイヤーがドメインに依存してしまっているから、依存性逆転の原則を使って(interfaceを用意して)抽象に依存させよう
- というのを見た
- [中野さんの意見](https://prahachallengeseason1.slack.com/archives/C01G28ESQR4/p1614477426073800?thread_ts=1614351520.048900&cid=C01G28ESQR4)
- (質問) getの戻り値(型等)をどこで確認する？
- any でレスポンスされた値を、どこで型変換するか?
- Factoryクラスを用意して、そこで変換する
- Factory: ドメインオブジェクトを返す関数備えたクラス
- 成功しているのか失敗しているのかの判定
- HttpClientでハンドリングはしない、呼び出し元でハンドリングする
- エラーが発生するかどうかの通知のみ、HttpClientに任せる
- (補足ですが)TypeScriptだと型の補完が効かないことが結構ある
- 例) typoが発生することがある。
- 例) クエリパラメータを忘れてしまう
- → aspidaを使っている
- apiの型に応じてフロントエンド用の型を作ってくれる
- swaggerを元に型を生成している
- swagger: APIの仕様書を自動生成するライブラリ
- aspidaのためにswaggerを作る必要がある
- nestjs/swaggerモジュールで自動生成?
- Swagger ⇆ aspida 変換するライブラリがあるよ
- TypeScriptは型との勝負、型を作るのに時間をかける
- なんでもやってくれるフレームワークが好きではない
- 何をやっているかわかりづらい？

## Storybookを導入して良かったこと

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recm1BkODIsqVFoiq)

- 1番はコンポーネント設計がきれいになった（シンプル）
- 渡されたものを描画するだけのシンプルな作りに強制できる
- （シンプルではないと△を渡せない)
- 2番はフロントとバック開発の作業が分けられてできるようになった
- APIがなくても先にフロント開発を進められる
- 独立して進められる
- (チーム2) 実務で採用している
- お客さんの要望を試してすぐ見せられた
- (質問) storybookの導入タイミング、個人開発では導入する？
- 個人開発だと、全体を自分が把握している
- フロントとバックエンドを並行して進めないので、あまり導入しない？
- prahaでは小さいコンポーネントから作り始める
- コンポーネントあるところにStoryあり
- Storyの置き場所
- stories派とコンポーネントディレクトリはに分かれている
- 松原さんは 近くにおきたい派
- テストも近くにおきたい
- すぐ見やすい

## tictactoeコードレビュー

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/rec3GbR7XAOLRYQnB)

### furukawa

[コード](https://github.com/kooooichi24/react-tutorial/tree/%E8%AA%B2%E9%A1%8C12/src)

- 実務なら、TSを使った方がいい
- CSS modulesを使っている
- 実務では、CSS-in-JSを使う
- 例: Emotion
- CSS-modulesでは
- クラス名の補完が効かない
- CSS-in-JS
- JSの変数をスタイルに使える
- 動的にスタイルを変更できる
- → 使い勝手がいい、主流はCSS-in-JSに移りつつある
- それ以外、強いて言うなら
- storyでクリック時の動作確認にconsole.logではなくactionを使った方がいい
- → actionだとstorybook上で確認できるので、見やすい
- console.logだと開発者ツールを開かないと見えないよね
- argを使い回すべきか??
- バックエンドのテストでは、必ず責務を独立させる
- 一長一短 (実務でも意見が分かれる)

## ishihara

[コード](https://github.com/sushidesu/tictactoe/pull/6)

- tictactoe/index.ts
- Markerの型
- TypeScriptだと、nullとundefinedが区別される
- `type Marker = Player | null` に `| undefined` を追加すると良い
- 引数が複数ある時
- オブジェクトにした方がいい(やりやすい)
- 補完が効く
- 順番を気にしなくて良くなる
- renderMarkerはHooksの中に持つものだろうか？
- rendarMarkerは描画に関するもの
- Playerが自分のマスを選択できるようになったときに困るかも
- Squareの中にrendarMarkerを持たせる
- 上からはPlayer型のみを渡す
- widthとheight
- 何回もPropsでやりとりしていてめんどくさかったですよね？そこで、、、
- ContextProviderを使う
- Providerでコンポーネントをラップすると、
- それ以下のコンポーネントで(バケツリレーなしで)contextValueを使える
- バケツリレーの省略として使う
- ほとんど変わらないような情報（3×3）などは、Contextにした方が良い
- どこにContext定義する？
- (Next.jsの場合) Page層に書くことがおおい
- リファクタする時、再利用する時はHooksとして書き出す
- 三項演算子の使い方
- chainできるけども、見づらい場合がある
- prahaでは三項演算子のネストは一つだけに制限している
- React.FCは非推奨になりつつある
- 場所
- Boardなど
- デメリット
- React.FCはchildrenを保証する型
- `<Hoge>{ /* ここがchildren */ }</Hoge>`
- 使う側が勘違いしてしまう可能性がある
- 意図しないchildrenの渡し間違いを防げる
- DefaultPropsが上書きされてしまう
- FC以外を使うならばType？VFC？
- シンプルにtypeで定義、戻り値JSX.Element
- 例: `const Hoge = ({ name }: HogeProps): JSX.Element => ...`
- huskyおすすめです
- (質問) emotionだと、スタイルコンポーネントと普通のコンポーネントの区別が付かなくなりそう? (大規模の時どうしてる？)
- これまでは命名で解決していた (StyledHoge等)
- ただ、命名なので強制力は無い、、
- コードレビューの時に区別がつきづらい、レビューしづらい？
- そうかもしれない
- DOM側にロジックを書かない
- その上のロジックのみをレビューする
- コンポーネントの出し分けも極力DOM側に書かない
- 今は三項演算子で済むかもしれないが、今後肥大化する可能性がある

## DIはどのような場面で使われるでしょうか？

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recCFdc37HK6ppDPI)

- 最も多いのは、レイヤー化されたアーキテクチャを採用しているとき
- Clean Arch
- 最小限の構成でも結構分かれている
- 実コードはDIだらけだよ
- repository -> dababase -> ...
- （主観ですが）設計がきれいならばDIが必ずある、逆に汚いとDI少ない気がする
- PrAhaではどんなアーキテクチャ使いますか？
- オニオンアーキテクチャをよく使う
- クリーンvsオニオン → オニオン！
- オニオンでもDomain層を守ってくれる役割があるので
- 
- こう分けたい

## テストケースはどのように上手く作成できるようになるのか？

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recrmmdb7AXXVJARj)

- prahaのおすすめ指針
- まず、正常形と異常形 (5つ)
- 正常形 (4つの分岐)
- 引数がある時、ないとき
- データがいっぱいある時 (文字列 10000字)
- 境界値
- 文字数が4,5,6のとき
- 異常系
- サービスを熟知する
- サービス固有のユースケースを考える
- 例えば韓国に展開するのならばハングルバージョンをテストする
- 言語仕様に詳しくなる
- reduce -> 初期値がないと空配列で例外を投げる -> 知らないとわからない
- t-wadaさんのブログを読みまくる!!

## DIの良い実装例はありますか？

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recNOwJStdEx6MCsd)

- CleanArchitectureをGitRepository見れば頻出なので理解しやすいと思う
- 参考記事: https://qiita.com/ttiger55/items/50d88e9dbf3039d7ab66
- OSSでもDIよく使われるが、コードがわかりづらい？(複雑？)

## 作成したテストケースはどのように管理していますか？

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recEK23qAu60Z1G5v)

- テストケースは開発向けのものである
- 管理したことがなかった
- 最新に維持する手間がかかる (同期する手間)
- 管理しているテストケースが最新かどうか怪しいと、結局コードを見るようになる
- そのため、コードを正とする方がいいと考えた

## その他

- DIされる対象クラスが持つメソッドを使うためにDIする
- (質問) コンストラクタではなくてFactoryで自動で作った方がいい？
- (質問) 引数にわざわざ入れなくて良くなる、引数に入れるのは違和感？
- → レイヤードアーキテクチャではよくやる
- (質問) 呼び出し先で自由に中身を変更されてしまうのでは？
- インターフェースを介してDIする
- インターフェースでは使用するもののみを宣言
- 呼び出し先で中身を変えない方が安全なので、そのようなメソッドは公開しない
- インターフェースは宣言のようなもの

## メンターセッションで取り上げた情報のリンク集

- apiの型を用意してくれるaspida
- https://github.com/aspida/aspida
- API変えるたびにaspida側のファイルを更新するのは面倒なので、swaggerからaspida側のファイルを生成することが多い
- https://petstore.swagger.io/#/pet/uploadFile
- https://github.com/aspida/openapi2aspida#readme
- APIを変えるたびにswaggerを更新するのは面倒なので、apiからswaggerを自動生成することが多い
- https://github.com/nestjs/swagger/
- DIをよく見かけるのは、レイヤー分けされたアーキテクチャを作る時
- https://qiita.com/ttiger55/items/50d88e9dbf3039d7ab66
- css-in-jsの代表格たち
- https://emotion.sh/docs/introduction
- https://styled-components.com/
- 変わらない情報を渡す時にpropsのバケツリレーを回避したい。そんな時はcontext
- https://reactjs.org/docs/context.html
- react.FCを使わない方が良い理由
- https://www.harrymt.com/blog/2020/05/20/react-typescript-react-fc.html
- https://fettblog.eu/typescript-react-why-i-dont-use-react-fc/
- https://github.com/facebook/create-react-app/pull/8177