# 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))