Angularと
 漸進的なリプレース


自己紹介 村井亮介 @RyosukeIketeru Mosh株式会社 共同創業者 時代に取り残されがち

余談
 なぜかアメリカにいて、電波が悪かったらごめんなさい

MOSH 情熱がめぐる経済をつくる

なぜリプレースするのか


ストレスフリーな開発者体験を
 つくるため😌


どんなストレスがあったのか
 （あるのか）😕


1. 過剰なデータのバケツリレー 余計なレイヤーを作りすぎた 1. DTOから何も書かれていないモデルインスタンス への変換 右から左へ渡すだけのコードを何度も書かないといけない 2. モデルからプレゼンテーションのためのViewモデル への変換 続・右から左へ渡すだけのコードを何度も書かないといけない 3. わざわざ変換しているモデルの責務がない まとめておきたいドメインロジックはそこにはない...

2. オレオレライブラリ デコレーターでUIを生成し、UIの揺れをなくしたかったが ... 1. 細かいデザインの調整がめんどい 微調整のためのデコレーターが増えまくる 動的なデータを扱うのが大変 2. キャッチアップコストがうなぎ上り 新しく入ってくれた方が詰む ドキュメントがあればまだいいが、それでもキャッチアップが大変 世間で使われている事だけを使う方が良い カスタムコンポーネントは認知負荷が低い物だけを作るべき 3. アトミックなコンポーネントと組み合わせる指針 共通化をすごく頑張らなくていい どうしてもデザインの差分は出るので、絶対に揺れない部分を共通化 共通のロジックは純粋関数をサービスにまとめる あとは多少冗長的でも良い。認知負荷が下がる事が大事

リプレースとは


MOSHにおける整理 今日は斬新的リプレースについて

1. 構成 1. リポジトリを新たに作成し、旧リポジトリが取り込む Route component群を独立したmosh-pageモジュールとして構成。 ライブラリとしてexportし、旧リポジトリ側libraryとしてimportする 2. 旧リポジトリと共有するモジュールは独立した libraryとしてexportする APIコールのためのサービスや、ボタンなどのコンポーネントは、直接新リポジトリ でも使用できる 3. NXは神だった 新リポジトリのライブラリ群を別のリポジトリとして管理シスつ、サブ モジュールで管理してシームレスに開発できる 4. リプレースだけではなく、新プロダクト作成にも活きる 部品や通信周りは共有できるなど

2. よかったこと 1. 機能開発のリリースを止めずにリプレースができた 兎にも角にもこれに尽きる 時間はかかるけど。 2. LinterやTest、Storybookなど、新世界の改善をいち早く適用開始できた リポジトリやプロジェクトを分けないと、テストやLinterなど適用が難しいことがある 3. 小さい影響で試しながら進められる aboutページなど、影響の小さいところから初めて、徐々に軌道に載せることができた （1と同じかもしれない）

3. 反省 新/旧の境界を明示し、新世界のルールの適用範囲をわかるようにした。しかし ... 1. ビルドが面倒 サブモジュールをクローンしたり手間が増える 動的なデータを扱うのが大変 2. キャッチアップコストがうなぎ上り 新しく入ってくれた方が詰む ソースコードが劇的に追いにくくなる 3. NX前は地獄だった LibraryProject毎にビルドするのが大変 HotReloadが効かなかったりもする ビルドプロセスが長くなって遅い

もう一つの漸進的リプレース
 （今後の話）


1. 事業成長と要求の多様化 マーケットの探索が先鋭化したニーズを発見

2. クイックな探索と実装のイテレーション→ユニット モデリング→サービス分割→サービスに対応するユニットをつくる

3. ユニット分割の根幹をなすサービス分割とMFE あらゆるユニットが探索的実装と独立したデリバリーを可能にする

継続的リファクタリング+
 漸進的リプレースを😌


サービス分割、MFE、
 それに付随した要素技術のアップデートに 興味がある方、だけでなく
 
 SSR、ネイティブアプリ、カスタムデザイン、 個別GA埋め込み等
 取り組みたい課題多数
 👇
 https://careers.mosh.jp/ Service / Mission / Team / Media / Values / Work Style / Positions / Message from CEO / etc… 今後について

ご清聴ありがとうございました