Cookpad.apk#1-ReactNativeについて
by
kazy1991
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
cookpad.apk 最近風当たりの強いReact Native for Androidについて
Slide 2
Slide 2 text
自己紹介 - 吉田万輝(かずき) - 2014年度クックパッド新卒入社 - 所属: 投稿開発部(10名) - Android エンジニア - Github: @kazy1991 - Twitter: @101kaz
Slide 3
Slide 3 text
「クックパッドMYキッチン」で検索
Slide 4
Slide 4 text
マルチプラットフォーム展開
Slide 5
Slide 5 text
ReactNativeを採用して後悔しているか?
Slide 6
Slide 6 text
No. 今のチームにはマッチしていて満足度が高い です。 ※チーム構成や目的に応じて RNの評価は大きく異なると思われます。
Slide 7
Slide 7 text
RNの評価が分かれそうなポイント - チームのメンバー構成 - 開発チームの規模 - 対象のユーザーの規模 - フルRNアプリ or ハイブリッドアプリ
Slide 8
Slide 8 text
ReactNativeがマッチする環境 - チームのメンバー構成 - Android, iOS, (出来ればJavaScriptも)に詳しい人がいる - 開発チームの規模 - 小さいチーム(2~6人程度) - 対象のユーザーの規模 - そこそこ(MAU数十~百万の単位になってくるとかなり厳しそう ) - フルRNアプリ or ハイブリッドアプリ - フルRNアプリを強く推奨
Slide 9
Slide 9 text
なぜか
Slide 10
Slide 10 text
チームメンバー構成について - ReactNativeはiOS,Androidエコシステムを上手く抽象化していますが、 よくわからない事象で嵌まる事があるのでiOS,Androidの専門性が必要 - リリースは通常の開発と同じなので安全で正しいリリースをするためにも iOS,Androidの知識が必要 - そのためiOS,Androidに詳しいエンジニアは必須
Slide 11
Slide 11 text
開発チーム規模と対象ユーザーの規模 - ReactNativeがそこまで安定したエコシステムではないので、チームメンバーの サポートを考えると一人が変更を常に追っていける規模感でないと厳しい - RN起因のどうしても解決できないクラッシュも多々起きる。ユーザーの規模が大 きくなると無視できないレベルになりそう
Slide 12
Slide 12 text
フルRNアプリを推す理由 - ReactNative自体が安定してないので出来る限りレールに乗った方が、 嵌まることが少ない - ReactNativeを導入するとプロジェクトがかなり汚染するので、 ネイティブ画面の開発する際に開発体験(DX)を著しく下げる
Slide 13
Slide 13 text
投稿開発部の開発メンバー - iOS: 2名 - Android: 1名 - rails: 1名 - デザイナー: 1名 - JavaScript: 1名(部長)
Slide 14
Slide 14 text
MYキッチンアプリ - 目的: - レシピ投稿者向けたクックパッドアプリのリデザイン - Chrome Canaryのようなベータ版アプリとしての役割も担っている - 機能 - 多くの画面がAPIレスポンスをViewにマッピングしている程度で、センサーなど ハードウェア機能をほとんど利用しない - 対象: - 小規模:ベータユーザー(DAUで数百人程度)
Slide 15
Slide 15 text
MYキッチンアプリの技術面 - プラットフォーム: - iOS and Android - コードベース: - 100% React Native App (with native-module) - 言語: - JavaScript -> TypeScript
Slide 16
Slide 16 text
RN製アプリのメリット
Slide 17
Slide 17 text
快適なリリース - CodePushを利用した高速なリリース - 多い時には月20回以上のデプロイ - 問題が起きてもすぐ直せる心理的 な安心感
Slide 18
Slide 18 text
すぐれた開発環境 - ホットリロードを利用した高速な開発 - 少しコードの書けるデザイナーの方ならガンガン実装まで出来る - 小さいチームなのでみんなが実装できるのはとても重要 - そこそこのクオリティでマルチプラットフォーム対応が可能 - ネイティブ実装と遷移のアニメーションが異なるなどの差異は諦める
Slide 19
Slide 19 text
RN製アプリのデメリット
Slide 20
Slide 20 text
クラッシュレポート - Sentryを利用しているが、捕捉出来てないクラッシュがありそう(要出典) - スタックトレースがJava(kotlin)ほど見やすくない - ReactNative内のNPEなども観測しているがどうしようも出来ない
Slide 21
Slide 21 text
まとめ(ReactNativeが向いている環境) - チームのメンバー構成 - Android, iOS, JavaScriptに詳しい人間がいる - 開発チームの規模 - 小さいチーム(2~6人)程度 - 対象のユーザーの規模 - そこそこ(数十~百万の単位になってくると厳しそう ) - フルRNアプリ or ハイブリッドアプリ - フルRNアプリを強く推奨 ReactNativeは組織にマッチするととても強力なツールになるのでぜひ検討してみて下さい!
Slide 22
Slide 22 text
ありがとうございました!!
Slide 23
Slide 23 text
ReactNative開発FAQ
Slide 24
Slide 24 text
バージョンアップについて - ReactNativeのバージョンアップが辛いという話をたまに聞きますが、 追従は全く辛くないです - OSSのネイティブモジュールなどが入っているとハマるかも..? - 前提としてOSSのネイティブモジュールは基本利用しないほうが良いです
Slide 25
Slide 25 text
マルチプラットフォーム辛くないですか? - 確認は大変ですが、実装コストを考えると対応する価値が十分にあります - リリース前はiOSとAndroid両プラットフォームでの確認を必須にしています