0->1 現場におけるReactNative

React Native | JMDC TECH Talk #1
- how should we start new project
- how should we implement (especially RN project)
- how should we negotiate schedule with business side persons

In order to create a good architecture, sometimes we need to discuss due date vs internal quality.
For these cases, we can reduce cost and have enough time to consider "What is the best ???" by using strategy I showed in this slide.

I'm not sure whether my experience would be a help, but... if you want, I'd happy to translate it.

Transcript

1. !"#$%!&'()*+ ,-./01.023- 〜これから難題に挑む者へ〜
2. "!#$!%!4!55
3. 6678(9+:;< =9>?@A
4. BCDE ユタマこたろう ブラック研究室出身のため、ち ょっととやそっとの無茶振りや 徹夜じゃへこたれないメンタリ ティを持つことに成功。 新卒時代は徹夜をしたくて仕方 がなかったが、『今は無理！』 @YutamaKotaro
5. BCDE ユタマこたろう 某サービスを新人エンジニアを教育 しながら二人だけで、３ヶ月で、要 件もきまりきっていない ＋ 申請一 週間前の急な機能追加もこなし無事 ローンチ。 プロジェクトが危なくなると開 発案件をいただけることも 多々！ @YutamaKotaro
6. BCDE ユタマこたろう やばいと召喚される系エンジニ ア。合言葉は気合と根性。 武器のバイタリティが減りつつ あるため考えた『孔明の知略』 で乗りきりたい。 @YutamaKotaro
7. FGHIJ 遺言ishなことも交えながら、 0,1プロジェクトにおける背景 RNの0->1プロジェクトのすすめかた 気合いで乗り切らない！やばプロジェクト RNだけで大丈夫か？
8. FGHIJ 楽しくもしんどい0,1プロジェクトを 
 どう乗り越えるのがベター？？
9. "K%LMGHNO< ()*+PQ
10. "#$%LMGHNO()*+PQ 理想論　≠　現実的解
11. "#$%LMGHNO()*+PQ 予算 スピード感 
 due date
12. "#$%LMGHNO()*+PQ したがって 今後の展望をしっかりと理解 変更に耐えられる設計を重視 抑えるところは抑える
13. RSLMGHNO,1< T*UVWX:YY
14. ,1T*UVWX:Y 結論から言うと RN最高です！
15. 結論から言うと RN最高です！ というのは他の方に任せるとして・・・・ 
 別の角度から見ていきたいと思います。 ,1T*UVWX:Y
16. 0->1プロジェクトにおけるあるある。 ,1T*UVWX:Y
17. 0->1プロジェクトにおけるあるある。 Web, iOS, Android 同時リリース！！ 
 
 でもコストはローコストにしたい・・・ ,1T*UVWX:Y
18. RNに飛びつきたいところではあるが・・・ ,1T*UVWX:Y
19. RNに飛びつきたいところではあるが・・・ ガワネイティブ 
 部分的なガワネイティブ も検討余地あり・・・ ,1T*UVWX:Y
20. モバイルとアプリのデザインを見てみると、 
 0,1段階では類似していることもしばしば・・・ Form Form Web side App side ,1T*UVWX:Y
21. モバイルとアプリのデザインを見てみると、 
 0,1段階では類似していることもしばしば・・・ Form Form Web side App side - ほぼ同じ ,1T*UVWX:Y
22. モバイルとアプリのデザインを見てみると、 
 0,1段階では類似していることもしばしば・・・ Form Form Web side App side - ほぼ同じ - 将来的にAppUXが作られる ,1T*UVWX:Y
23. モバイルとアプリのデザインを見てみると、 
 0,1段階では類似していることもしばしば・・・ Form Form Web side App side - ほぼ同じ - 将来的にAppUXが作られる 共通化しても 
 　　無駄が多い・・・？？ ,1T*UVWX:Y
24. モバイルとアプリのデザインを見てみると、 
 0,1段階では類似していることもしばしば・・・ Form Form Web side App side もし仮に、この部分だけを WebViewに置き換える と・・・？？ ,1T*UVWX:Y
25. RN Side ,1T*UVWX:Y Web Side
26. そのまま使える。 ,1T*UVWX:Y - フォームUI - バリデーションロジック - Analytics tools - Marketing tools - Etc…
27. - フォームUI - バリデーションロジック - Analytics tools - Marketing tools - Etc… 工数削減！！ ,1T*UVWX:Y
28. それぞれで作ると・・・・ Form Form Web side App side ,1T*UVWX:Y
29. それぞれで作ると・・・・ Form Form Web side App side ,1T*UVWX:Y 頑張っても1.6(1 + 0.6) 
 くらいのコストがかかる。 変更があると少し大変・・・🥲
30. App UXを作る時には、 Form Form Web side App side 0.6かけて作ったものを潰し て、１のコストがかかるので ,1T*UVWX:Y
31. App UXを作る時には、 Form Form Web side App side 0.6かけて作ったものを潰し て、１のコストがかかるので ,1T*UVWX:Y 合計2.6くらいのコスト
32. 局所ガワネイティブを使った場合は Form Form Web side App side ,1T*UVWX:Y
33. Form Form Web side App side ,1T*UVWX:Y 1.1(1 + 0.1) 
 くらいでDay0完了 変更も楽々対応😀 局所ガワネイティブを使った場合は
34. App UXを作る時には、 Form Form Web side App side ,1T*UVWX:Y 0.1かけて作ったものを潰し て、１のコストがかかるので 合計2.1くらい
35. App UXを作る時には、 Form Form Web side App side ,1T*UVWX:Y サクッと作り替え！ 工数削減！
36. まとめると・・・。 コスト大 ガチネイティブ　＋　Web コスト小 RN　＋　Web ガワネイティブ + Web 部分ガワネイティブ + Web ,1T*UVWX:Y
37. Pros ,1T*UVWX:Y -　コスト小で作れる 
 - メンテコストも抑えられる
38. Pros ,1T*UVWX:Y -　コスト小で作れる 
 - メンテコストも抑えられる Cons -　オフライン時の対応 
 - UXの損失（画面によるが・・・）
39. Pros ,1T*UVWX:Y Cons -　オフライン時の対応 
 - UXの損失（画面によるが・・・） 
 - Appleによるリジェクトの可能性 -　コスト小で作れる 
 - メンテコストも抑えられる
40. ,1T*UVWX:Y From 
 developer.apple.com
41. ,1T*UVWX:Y From 
 developer.apple.com 完全なガワネイティブなら、 
 　　カメラ、PUSH、in app purchase などのNative-ish機能が必要。
42. （可能であれば）コンポーネントのwebとの共有 ,1T*UVWX:Y
43. （可能であれば）コンポーネントのwebとの共有 Form Form Web side App side 将来的にUIが変わる可能性は大 ,1T*UVWX:Y
44. （可能であれば）コンポーネントのwebとの共有 Form Form Web side App side 将来的にUIが変わる可能性は大 ただし、コンポーネントの気質 が大きく変わることはない。 ,1T*UVWX:Y
45. したがって。。。 コンポーネントは共通化しておくメリットはあり。 ,1T*UVWX:Y
46. したがって。。。 コンポーネントは共通化しておくメリットはあり。 - ComponentLibraryを使えるならweb対応 のものを 
 ,1T*UVWX:Y
47. ,1T*UVWX:Y
48. したがって。。。 コンポーネントは共通化しておくメリットはあり。 - ComponentLibraryを使えるならweb対応 のものを - monorepo + RNFW かっこいいこと喋れるかと思ったけどnxで火傷した・・・ 遺言としてはworkspaces, lernaでよいかと・・・ ,1T*UVWX:Y
49. 仮にできなくてもアプリ内でレスポンシブにするシ ステムだけは組んでおいた方がいい・・・（遺言） ,1T*UVWX:Y
50. ,1T*UVWX:Y コンポーネントは共通化しておくメリットあり
51. ,1T*UVWX:Y コンポーネントは共通化しておくメリットあり 共通化よりも効果的なのは 
 　　　　　　　　部分ガワネイティブ 　　　　　　　　ガワネイティブ ここで減った工数は、次の進め方のところで 
 　いいアーキテクチャーを作る時に使いたい・・・！！
52. "K%LMGHNO< SZ[\
53. "K%LMGHNNOSZ[\ 0->1フェーズでは、ざっくりと 
 変わってしまうこともそれなりにあります。
54. 0->1フェーズでは、ざっくりと 
 変わってしまうこともそれなりにあります。 180degぐらいの機能変更 
 大規模なリニューアル "K%LMGHNNOSZ[\
55. そしてやばいのが 
 『とりあえずやるしかない状況』 "K%LMGHNNOSZ[\
56. そしてやばいのが 
 『とりあえずやるしかない状況』 RDD "K%LMGHNNOSZ[\
57. 『Release Driven』は 
 正しいの・・・・？？？🥲 "K%LMGHNNOSZ[\
58. ダメ、ゼッタイ！🤬 "K%LMGHNNOSZ[\
59. 短納期のために品質を犠牲にすることは可能。 
 だがその分は数週間で報われる。 From martinfowler.com "K%LMGHNNOSZ[\
60. - Neglecting internal quality leads to rapid build up of cruft - This cruft slows down feature development - Even a great team produces cruft, but by keeping internal quality high, is able to keep it under control. - High internal quality keeps cruft to a minimum, allowing a team to add features with less effort, time, and cost From martinfowler.com "K%LMGHNNOSZ[\
61. したがって 0,1でRDDの時に軽視されがちな 『アーキテクチャー』『綺麗に作る』 
 は 『変更の多い0,1でこそ大切』 "K%LMGHNNOSZ[\
62. 『無茶なスケジュールを無茶をして達成するより』 『交渉をして、無茶をして、綺麗 な状態でリリースした方がいい』 "K%LMGHNNOSZ[\
63. ビジネスサイドとの折り合いがつかない時もありま すが・・・・ "K%LMGHNNOSZ[\
64. ビジネスサイドとの折り合いがつかない時もありま すが・・・・ A common debate in software development projects is between spending time on improving the quality of the software versus concentrating on releasing more valuable features. The "cost" of high internal quality software is negative. The usual trade-off between cost and quality, one that we are used to for most decisions in our life, does not make sense with the internal quality of software. From martinfowler.com "K%LMGHNNOSZ[\
65. ここだけは妥協するポイントではない。😤 "K%LMGHNNOSZ[\
66. Internal quality を上げる 
 ジェネラルなルールとして 
 おすすめなのが "K%LMGHNNOSZ[\
67. "K%LMGHNNOSZ[\
68. "K%LMGHNNOSZ[\
69. ディレクトリやファイル単位で のインポートを制御してくれ る。 "K%LMGHNNOSZ[\
70. Cruftを削除しにくい状態(見 つけにくい。） 依存関係、依存方向 
 　　　　　　カオス "K%LMGHNNOSZ[\
71. 依存ツリーをシンプルにできる ので、 影響範囲や使用範囲がわかりや すくなる。 置き換えもしやすい。 "K%LMGHNNOSZ[\
72. "K%LMGHNNOSZ[\ 最悪、なんとかなりやすい・・
73. ただし、若干使いにくくtsと噛み合わせるために は、一工夫するか、lint-ignoreされること も・・・ Type　は依存関係に入りますか？ いいのがあったら知りたいです・・・😭 "K%LMGHNNOSZ[\
74. もう一個重要なのがRNのアップデート。 "K%LMGHNNOSZ[\
75. もう一個重要なのがRNのアップデート。 From 
 mattoakes.net "K%LMGHNNOSZ[\
76. 当然ですが・・・ 
 こまめにアップデートをしていくようにしましょう。 "K%LMGHNNOSZ[\
77. 当然ですが・・・ 
 こまめにアップデートをしていくようにしましょう。 "K%LMGHNNOSZ[\ そういうスケジュールが組まれるようにしましょう。
78. 当然ですが・・・ 
 こまめにアップデートをしていくようにしましょう。 "K%LMGHNNOSZ[\ そういうスケジュールが組まれるようにしましょう。 さもなくば大変なことになります。
79. 当然ですが・・・ 
 こまめにアップデートをしていくようにしましょう。 "K%LMGHNNOSZ[\ そういうスケジュールが組まれるようにしましょう。 さもなくば大変なことになります。 したがってExpoはとにかくbetter
80. まとめると・・・ ツールを使って、捨てやすい状態を作り cruftを最小限に・・・ "K%LMGHNNOSZ[\ 機能や実装方法でコストは抑えても、 internal qualityは抑えてはいけない。
81. まとめると・・・ ツールを使って、捨てやすい状態を作り cruftを最小限に・・・ アップデートの時間もとりましょう。 cruftの山が出来上がります・・・ "K%LMGHNNOSZ[\ 機能や実装方法でコストは抑えても、 internal qualityは抑えてはいけない。
82. ]^_U`abc9_< deLMGHNOfgh[i
83. ]^_U`abc9_ 工数削減のために、 
 　　　『部分的webViewも検討の余地あり』 
 　　　
84. ]^_U`abc9_ コードは絶対に綺麗に！😤 
 　　　『All Nativeは譲ってもこれは譲らない』 
 　　　『すぐに元を取れる』 工数削減のために、 
 　　　『部分的webViewも検討の余地あり』 
 　　　
85. ]^_U`abc9_ 簡単に捨てられるようにすること。 
 　　　『捨てられる＝リファクタしやすい』 工数削減のために、 
 　　　『部分的webViewも検討の余地あり』 
 　　　 コードは絶対に綺麗に！😤 
 　　　『All Nativeは譲ってもこれは譲らない』 
 　　　『すぐに元を取れる』
86. ]^_U`abc9_ 『こまめなアップデート』も 
 　　　品質をあげることにつながります。 
 　　『時間ない！なんかわからんけどビルド！😭』 
 　　　はやめましょう。
87. ]^_U`abc9_ 『こまめなアップデート』も 
 　　　品質をあげることにつながります。 
 　　『時間ない！なんかわからんけどビルド！😭』 
 　　　はやめましょう。 （ライブラリの選定もそう。 
 　　大御所も死んだりするので難しい・・・ 
 　　しっかりと選びましょう😀）
88. =a7hj kl_gm>n