---
# System prepended metadata

title: 2021/06/20 メンター相談
tags: [メンター相談, 6月]

---

# 2021/06/20 メンター相談

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

## DRY原則について

https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recITInjWHBzIIaiy?blocks=hide

### ①SRPとDRY原則の関係はどのようなものになりますか？どのような違いがありますか？

近い概念だと思う

- DRY起源: Andy Hunt、Dave Thomas
- SOLID起源: Robert C. Martin
- 考えた人が違うため、似た概念に違う言葉がついてもおかしくはない

SRPには 「一つのコードの変更理由は一つだけ」という基準がある
→ 変更理由に着目している点は、DRYには無い特徴

### その他

- SRPに則っているとクラスの存在理由が明確なので、コードを読みやすい
- SRPの基準はチームですり合わせが必要
    - [Next.jsのサンプルアプリ](https://github.com/vercel/commerce) のコードをチームで読んだ時、読むのに苦労した (基準が違うので)
- アーキテクチャがあると「変更理由」を決めやすくなる

### ②どこまでDRYを意識しますか？共通化に関して意識していることや、基準などはありますか？

共通化した部分から作る事が多い

- フロントエンド: ボタンなど小さいコンポーネントから作る
- バックエンド: ドメインエンティティからつくる

プラハでは、序盤にモブプロして、共通部分を先に作る

- ドメインエンティティを先に作る
    - ユースケースを書き出す → どのようなエンティティが必要かが見えてくる
    - どこにどんな単体テストを書くかだけ決めて、実装は後で行う
- 共通部分を先に作ると、手戻りが少ない
    - ユースケースから先に作ると、各々で同じ部分を共通化してしまう可能性がある
    - 競合しないようにする調整も面倒
- ただし共通化の際は、本当に同じものかどうかはモブプロの段階でよく話し合う

### その他

- XPには「ゆとりの時間」という概念がある
- 開発しないでリファクタ、テストに集中
- → 共通化がやりやすそう

## Reduxの利点はどのようなものになるでしょうか？どのようなときにReduxを使いますか？

https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recC45hHJYdbyl35C?blocks=hide

- まずはRedux以外でできないかを考える
- きつくなったら Redux
- ただ、今までReduxじゃないとダメだった場面は無かったかも、、？

Reduxの利点 (強いて挙げるなら)

- dispatch経由でステートを更新するので、useCallbackで関数をラップする必要が無い
- selectorを使うとStoreから加工したデータを返せる
    - → コンポーネントの中でデータの加工をする必要がなくなる

公式サイトに [いつReduxを使うべきか？](https://redux.js.org/faq/general) について詳しい説明がある

- たくさんの画面でステートを共有するとき
- ステートが頻繁に更新されるとき
    - → ステートの最新状態が予測しづらい
    - Reduxは履歴をとってくれるのでデバックしやすい
- などなど

### その他

- [ReduxToolkit](https://redux-toolkit.js.org/introduction/getting-started) が良さそう
    - 公式が推奨している
    - TypeScriptとの相性もいい
- [CypressとReduxの連携](https://www.cypress.io/blog/2018/11/14/testing-redux-store/) が便利 (らしい)
- ReduxとuseStateを共存させることもできる ([Organizing State | Redux](https://redux.js.org/faq/organizing-state))
