Angularと漸進的なリプレース

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… 今後について

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

Angularと漸進的なリプレース

Angularと漸進的なリプレース

MOSH,Inc

Transcript