社会人1年生エンジニアの今週の自学 #5（5/15~5/21）

2023年5月14日 23:58

こんにちは！どぎーです！
ついに2週間弱ぶりの投稿となってしまいました😇
1周回って週の頭に投稿するサイクルに戻れそうなので、ナイスだということにします🤘笑

ということで、今回は先々週&先週を合わせて振り返り、5/15(月) から「何を学ぶか」・「何を進めるか」を宣言していきます！

先々週&先週の振り返り

MUST
- ✅ React Native アプリリファクタ
- 😐 React Native アプリ認証周りの実装
- 😐 AWS 練習用のプロジェクトのフロントエンド側の環境構築
- 😭 AWS の Udemy 進める（学習計画を立てる）
WANT
- 😐 デザインパターン入門のサンプルコードを Kotlin で書いてみる
  - Iterator
  - Adapter
- 😭 M3 のドキュメントを読み、概要を掴む
- 😭 Android の個人開発アプリでネットワーク通信周りの DI を整理

React Native アプリリファクタ

探り探りで共同開発してきた React Native のプロジェクトですが、ゴールデンウィークにチーム全体でまとまった時間がとれるということで、2日間の開発合宿を行いました😚
対面で同期的にコミュニケーションをとれるチャンスだったので、いままで納得のいっていなかった部分を洗い出し、リファクタを行いました。

リファクタした項目は以下のとおりです。

モデルの整理
components ディレクトリ内のファイル整理
screens ディレクトリ内のファイル整理
カラーコードの定数化
px 値の定数化

モデルの整理
元々 src/types というディレクトリで type を管理していたのですが、アプリのドメインとしての type とそれ以外の type（コンポーネントで扱うユニオン型やナビゲーションに関わるオブジェクトなど）が混在していました。
また src/types 内の type 定義やファイルの切り分け方が混沌としていました。

このあたりの課題を解決すべく、以下のようにモデルの整理を行いました。

アプリのドメインとしての type を src/models に移す
それ以外の type を src/types に残す

アプリのドメインとしての type を src/models に切り出したのは、type のうちどこまでがアプリのドメインかを明確にするためです。
つまり、アプリのドメインとしてチームの認識が揃った type のみを src/models に格納するようにしました。
その結果、プロジェクトの最も抽象にあたるドメインが src/models に集まることになり、余計な依存や変更がなくなりました。

残った型は責務がバラバラでリファクタしたい気持ちが山々でしたが、今後 src/components や src/navigation のディレクトリ構成も変わる可能性がありました。なのでリファクタしても二度手間になると判断し、あえてそのまま残しました。
私としては、src/types というディレクトリ名がそもそも曖昧で、責務が曖昧でファットなディレクトリになりかねないので、src/types ディレクトリ自体をなくしたいと考えています。

src/types ディレクトリをどうしていくかは今後の課題です。

components, screens ディレクトリ内のファイル整理
src/components ディレクトリは、よしこさんの記事を参考にしてモデルの関心ごとに整理しました！

…と言いたいところだったのですが、「えいや！」で進めているプロジェクトということもあり、ドメインやデザインの変更が発生する可能性があったので、今回はその下準備にとどめました。

具体的には src/components 内のファイル構成やコードを以下のように統一しました。

styles.ts 内では @package をつけて named export する
コンポーネントの実装は [コンポーネント名].tsx で行い、@package をつけて named export する
ディレクトリ名はコンポーネントの名前にする
index.ts でコンポーネントを export する

@package アノテーションは、uhyo さんが製作した ESLint のプラグイン eslint-plugin-import-access の機能です。
これを用いることで、export をそのディレクトリ内に閉じ込めることができます。
したがって、関数やコンポーネントごとにファイルを分割しつつ、公開範囲を最小限にとどめた状態で export することができます🔥

画面もコンポーネントと捉え、src/screens 内のファイル構成も src/components に統一しました。

モデルの関心によるディレクトリの整理は、1次リリース後に対応していきます。

カラーコード、px 値の定数化
いままでハードコードしていたカラーコードや余白の px 値を定数化し、合宿期間で一気に置き換えました。

カラーコードは Material Design 3 の Color System を参考に定義しました。
Material Design 3 を理解しておらず、見よう見まねでスキーマに当てはめたため、今振り返ると直したいところが見えてきます😇
今回のリファクタではカラーコードの定数化が目的だったので、ひとまず OK ということにします🙄

具体的に気になるところは以下のとおりです。

Surface と Background が混在している
- Material Design 3 では Surface のみ
- 混在していたので Surface か Background どちらを使えば良いか判断できず、一部のハードコードを定数に置き換えられていない
Error Container を Error Variant と定義している

今後 Material Design 3 を勉強しつつリファクタしていきます。

今回のリファクタでカラーコードや px 値は定数化できましたが、テキストスタイル（fontSize, fontWeight など）は共通化できていません。
こちらも1次リリース後に対応していきます。

React Native アプリ認証周りの実装

TODO: 後で書く
- 状態管理する必要があることに気づいた
- 状態管理は useContext or Recoil で行う
- Recoil の調査から

AWS 練習用のプロジェクトのフロントエンド側の環境構築

TODO: 後で書く
- 環境構築に必要な要素の洗い出し DONE
- create-next-app（そもそものプロジェクト）
- Prettier
  - Prettier の ESLint は不要なエラーも吐かれるので非推奨
- ESLint
  - import-access
  - simple-import-sort
  - sort-destructure-keys
  - unused-imports
- Tailwind CSS
- Jest
- Storybook
- Hygen

ドメイン駆動設計入門の Chapter5（リポジトリ）まで読む（番外）

TODO: 後で書く
- 勉強会に向けてさらっと流し読みしただけ
- Notion に概要・気付き・疑問まとめたい

- Android の文脈のリポジトリは DDD の文脈におけるリポジトリを拡張したものだと感じた
  - DDD の文脈：ドメインオブジェクトの永続化・再構築
  - Android の文脈：アプリ外の API や DB とのやりとりを抽象化（つまり DDD の文脈のリポジトリを内包している）

デザインパターン入門 Adapter まで読む（番外）

TODO: 後で書く
- こちらも勉強会に向けてさらっと流し読みしただけ
- Kotlin でサンプルコードを実装したい
- RecyclerView.Adapter のコードを Adapter の例と比べたい
  - 委譲を使うパターンっぽい
  - Android の RecyclerView

Android アプリ設計パターン入門 MVP の章読み直し（番外）

TODO: 後で書く
- 読み終えた
- 修正が必要な箇所に気付いたので修正した
- README 書いた
  - https://github.com/Kaito-Dogi/android-sample-mvp/blob/main/README.md

- MVP パターンとは別に気になることがあるので今後の課題とする
  - エラーどう表示するか
    - https://github.com/Kaito-Dogi/android-sample-mvp/commit/a5ca099bf3d70f4857d0aa6ceecf102440d260e1
    - どの Exception を投げるか
    - どのようなメッセージをどう渡すか
    - ユーザーに表示するメッセージをどう分岐するか
  - Repository で Result 返すか
    - https://github.com/Kaito-Dogi/android-sample-mvp/blob/main/app/src/main/java/app/doggy/mvpsample/data/repository/CountRepositoryImpl.kt
    - 『例外を投げるな、値を返せ』を読んで、例外を投げるのではなく Result 型を返す方が意味的に丁寧だと思った
      - https://speakerdeck.com/okuzawats/li-wai-wotou-geruna-zhi-wofan-se）
      - なんなら ViewModel で runCatching している時点で Result 型を作っていた
    - Repository からは Result を返し、ViewModel or UseCase でエラーハンドリング（onFailure）する？

技術書典に向けた執筆（番外）

TODO: 後で書く
- 会社から出品する『ゆめみ大技林』の１章分を執筆した
- 構造的部分型と公称型の違いについて書いた
- サンプルプロジェクトも作った
  - https://github.com/Kaito-Dogi/type-systems
- Qiita の記事はこちら
  - https://qiita.com/Kaito-Dogi/items/58023fc6e501f09a56ae
  - 5/21（技術書典当日）以降に公開予定

今週の自学

もしかしたら他にやることあるかもだけど、えいや！

MUST
- ドメイン駆動設計入門の Chapter6（ユースケース）まで読む
- Recoil 調査
- 登壇スライドの作成
- AWS 練習用のプロジェクトのフロントエンド側の環境構築
- React Native アプリ Google 認証の実装

WANT
- AWS の学習計画を立てる
  - Udemy
  - Cloud Practitioner 試験
- デザインパターン入門のサンプルコードを Kotlin で書いてみる
  - Iterator
  - Adapter
- ドメイン駆動設計入門の Chapter4, 5 の概要・気付き・疑問をまとめる
- M3 のドキュメントを読み、概要を掴む
- Android の個人開発アプリでネットワーク通信周りの DI を整理

登壇スライドの作成

『アットウェア x 未来シェア x ゆめみ合同LT会 in 横浜』で LT します！
技術書典で執筆した内容を簡単にお話しします。

今週の雑談

家に可変式ダンベルとインクラインベンチが導入された！
開発合宿！
p5.riso で作品を作って、リソグラフで印刷した！
技育博に参加した！

家に可変式ダンベルとインクラインベンチが導入された！

友人に触発されて買ってしまいました😚

いままでジムに契約していましたが、家から出るのが嫌いな面倒くさがりなので、数ヶ月行っていませんでした😇
このセットでも2万円強だったので、長期的に考えたらジムに行くより安い…！
あと、多分続くはず💪笑

家で筋トレして、本格的にフォームを見直したくなったらパーソナルジムに通うのが結果的にコスパ良さそうと、今さら気付いてしまいました…

ゆめみ社員として技育博に参加してきました。
入社して初めてのイベントでした。
福ちゃんやキースさんの仕事っぷりを目の前で見られてすごく勉強になりました。
ギュンギュン❗️❗️

押忍！#技育博 #ゆめみブース設営完了ぉおおおお😆🔥ノベルティたっぷり用意してっからみんな遊びに来てくれよな🤓ギュンギュン‼️ pic.twitter.com/FOtl67P5Iv
— 会えば分かる広報⭐️ゆめみ福ちゃん (@fukutaro_yumemi) May 14, 2023

それでは今週もよろしくお願いします🙌

この記事が気に入ったらサポートをしてみませんか？