マイニフティアプリ開発チームにおける 開発スタイルの紹介

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Copyright © NIFTY Corporation All Rights Reserved.  5  マイニフティチームの抱える課題インフラ / API / iOS / Androidと必要なスキルが幅広く  実装方針が人により異なるときがあった  新規プロジェクトかつ人員が流動的に入れ替わったため、  アプリ開発経験がないエンジニアが多くいた  今後も多くのニフティサービスと連携する可能性があり柔軟性が大事になる  メンバーが少ないため、品質のチェック方法に工夫が必要になる  柔軟な共通アーキテクチャと技術共有できる土壌が必要 

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright © NIFTY Corporation All Rights Reserved.  7  アーキテクチャに共通する概念 API / iOS / Android共にの考えを導入 Clean Architecture  各レイヤーにより関心の分離する  DIP(Dependency Inversion Principle)により依存の方向を一方向にする  フレームワーク/UI/データベース等を変更・交換しやすくする  Clean Architecture DB  UI  Devices  Controllers  Entity  Use Cases  Gateways  DataSouceInterface DataSouceImplement Repository(呼び出し側)

Slide 8

Slide 8 text

Copyright © NIFTY Corporation All Rights Reserved.  8  アプリアーキテクチャ Repositoryパターン  Repository層にデータをキャッシュしてHTTP通信を減らす  永続化したいデータはLocalDataSource経由でローカルDBに保存する  View側からはローカルかリモートのどちらにデータがあるかを意識しないで良くなる  View ViewModel Repository LocalDataSouce RemoteDataSouce ローカルDB HTTP Client Model iOS / Android共にを採用 MVVM + Repositoryパターン

Slide 9

Slide 9 text

Copyright © NIFTY Corporation All Rights Reserved.  9  アプリアーキテクチャデータフローの統一  RepositoryにあるデータをSingle Source of Truthとする  Repositoryにあるデータの変更を検知してデータを自動的にViewに反映する  Usecaseにアプリケーションロジックを記載する  イベント・データの流れをにする一方向 View ViewModel Usecase Repository DataSource Model イベント（タップ・pull等）   データの変更 

Slide 10

Slide 10 text

Copyright © NIFTY Corporation All Rights Reserved.  10  アーキテクチャの利点と課題利点  課題  概念を理解するとAPI/iOS/Androidの  区別なく実装方針が共有しやすい  パッケージが綺麗に分割され、  レイヤーごとの役割が明確で混乱しない  誰が書いても似たようなモジュール名と依存関係になりやすい  Clean Architecture自体の  学習コストが高め  実装が冗長になることがある  （UsecaseがRepositoryをつなぐだけ等）  油断するとViewModelまたはUsecaseが肥大化してしまう 

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright © NIFTY Corporation All Rights Reserved.  16  品質を保つためにマイニフティチームの課題を考える少人数の開発のため、端末ごとの実機テストや利用感を多く試すのに時間がかかる  iOS/Android/APIで多くのログやメトリクスを集めているが  必ずしも確認できていない  SLO低下や障害のアラートはあるが、アラート起こる前の潜在的な問題に気付けない 

Slide 17

Slide 17 text

Copyright © NIFTY Corporation All Rights Reserved.  17  テストパターンと使用感のフィードバックを増やすリリース前に社内全体で内部テストの実施社内全体で希望者を募り、TestFlightやGoogle Playの内部テスター機能で配信  機種固有の問題を洗い出すために実施（特にAndroid）  フィードバック例  画面サイズが極小の端末でスクロールができなくてログインできない  Xiaomi端末でスプラッシュ表示がおかしい  アプリ背景色と被っていて入力欄のカーソルが見えづらい 

Slide 18

Slide 18 text

Copyright © NIFTY Corporation All Rights Reserved.  18  品質を確認する月一で API / アプリのパフォーマンス会を実施メトリクスやダッシュボードを見る機会を創出  エラー率やレイテンシー、画面エンゲージメント等で気になる点を確認  UI / UXの改善点やバグ、潜在的な問題点、運用改善(Toil削減等)を検討  Firebase Performance Monitoring   Cloud Watch  (SLOダッシュボード/各種メトリクス)  

Slide 19

Slide 19 text

Copyright © NIFTY Corporation All Rights Reserved.  19  まとめマイニフティチームの取り組み API/iOS/AndroidにClean Architectureの考えを反映  意図の共有や属人化解消、技術継承のため、コード輪読とモブプロを実施  定期的な品質チェックに社内テストやパフォーマンス会を実施  それぞれのコードの理解しやすさを共通化  メンバー間で実装方針のブレをなくす 

Slide 20

Slide 20 text