AACという武器を手に1,400行のFragment2体と戦った話

Android Reject Conference 2019/2で発表した資料です。
https://connpass.com/event/112296/

Transcript

1. AACという武器を手に 1,400行のFragment2体と 戦った話 Android Reject Conference 2019/2 2019/02/13 (Wed.) @syarihu
2. Taichi Sato (@syarihu) • Money Forward, Inc. ◦ Android Engineer • TechBooster
5. 戦うことになった経緯
6. 戦うことになった経緯 • 手入力画面のデザイン改善をすること になった
7. Before
8. After
9. 比較
10. 入出金履歴詳細の電卓デザイン
11. 戦うことになった経緯 • 手入力画面のデザイン改善をすること になった ◦ 電卓のデザインが変わった
12. 戦うことになった経緯 • 手入力画面のデザイン改善をすること になった ◦ 電卓のデザインが変わった • 入出金履歴詳細画面も新しいデザイン に合わせる必要があった
13. 戦うことになった経緯 • 手入力画面のデザイン改善をすること になった ◦ 電卓のデザインが変わった • 入出金履歴詳細画面も新しいデザイン に合わせる必要があった
14. 戦うことになった経緯 • 手入力画面のデザイン改善をすること になった ◦ 電卓のデザインが変わった • 入出金履歴詳細画面も新しいデザイン に合わせる必要があった これがやばい
15. 戦うことになった経緯 ※よく見たら片方は1,300行だったのでタイトルと微妙に違うんですがゆるしてください TransactionDetailFragment.java TransactionEditFragment.java
16. 戦うことになった経緯 ManualInputFragment.java
17. 戦うことになった経緯
18. 戦うことになった経緯
19. 戦うことになった経緯 • 2つのFragmentが互いに依存してる • どっちのFragmentも色んなところに依 存してる • ちょっと修正しようとするとバグる • とにかくやばい
20. 戦いの準備
21. 戦いの準備 • 手入力改善をやることになったのが６月 ごろ ◦ この時期は１人で開発していたので 全てを把握しやすい状況だった ◦ 新卒も入ってくるしメンバーが 増えると今のままだとやばい
22. アプリ全体の設計を整えよう！
23. 設計を整える
24. 以前の設計 ※この時点での設計をざっくりまとめただけで、色々な作り方で作られていたので 　全部これ通りに整っていたわけではない
25. 設計を整える • 人によって作りがバラバラで全体的に 整ってなかったけどMVVMっぽいのに 寄せていくのが良さそうだった • テストコードが書きにくいのでDIは入れ たい
26. 設計を整える • あんまり設計を固めすぎても全てを移 行できるとは思えない ◦ 移行を推進できる人がいなくなった途 端にそれが負債になる • 既存の作りにできるだけ合う形で きれいにしていきたい
27. 新しい設計
28. 設計を整える • MVVM ◦ AAC ▪ ViewModel, LiveData ◦ DataBinding • DI ◦ Dagger2
29. 設計を整える • 新しい設計をドキュメントにまとめてプロ ジェクトに関わる人に説明 • 後の入出金履歴詳細画面も見据えて 手入力画面の改善から新しい設計を適 用することにした
30. 入出金履歴詳細画面の 仕様を整理する
31. 仕様を整理する - 入出金履歴詳細画面（自動連携 - 出金）
32. 仕様を整理する - 入出金履歴詳細画面（自動連携 - 入金）
33. 仕様を整理する - 入出金履歴詳細画面（手入力）
34. 仕様を整理する - レシート項目編集画面
35. 仕様を整理する - ジョルテ連携
36. やること 1. 入出金履歴詳細画面のリファクタ 2. レシート項目編集画面のリファクタ 3. ジョルテ対応 4. TransactionDetailFragment.javaと TransactionEditFragment.javaを 消し飛ばす
37. 入出金履歴詳細画面のリファクタ
38. やること • レイアウトを作り直す • 表示する項目をLiveDataで宣言 • ViewModelにロジックを実装 • Viewに反映する ◦ レイアウトにViewModelをbind ◦ LiveDataをobserveする
39. やった結果
40. やった結果 - 手入力履歴 ※実際の発表ではGIF動画で再生しました
41. やった結果 - 自動連携履歴 ※実際の発表ではGIF動画で再生しました
42. やった結果 • 表示する項目多すぎ ◦ 出し分けめっちゃ多い ◦ 振替とかが特にやばい • 色々なところからデータとってきて加工 しないといけないからどうしても行数が 増える
43. やった結果 • 結果約1,200行のViewModelになって しまった • ただ設計変えたおかげでコードの 見通しは良くなった • Viewとロジックが分離できた • 仕様がだいぶ把握できた
44. やった結果 • エラーハンドリングをちゃんと実装したり 細かいところも直せた
45. やった結果 • アプリの設計を少し見直そうかとも思っ たけどこの画面の仕様が複雑すぎるの で一旦このままにすることにした
46. レシート項目編集画面の リファクタ
47. やること • レシート項目編集画面を新しく作る ◦ 振替などの出し分けが無い ◦ 入金 / 出金先が財布だけ ◦ 保存を押したらレシート読み取り結果 画面に反映
48. やった結果
49. ジョルテ連携対応
50. やること • レシート項目編集画面に送信機能がつ いた感じなので送信ボタンを押したとき の挙動だけ変えて作る • あとはジョルテ連携用の実装を ごにょごにょする
51. やった結果
52. TransactionDetailFragment.javaと TransactionEditFragment.javaを 消し飛ばす
53. やること • ここまでの対応で２つのFragmentへの 依存が完全に消えたので関連ファイル をすべて消し飛ばす
54. やった結果
55. 戦いの終わり
60. 戦いの終わり • ４ヶ月くらいの長い戦いだった • 当初の目的だった電卓のデザインの統 一はもちろんできてよかった • 仕様がだいぶ整理できたのは良かった
61. 戦いの終わり • リファクタしてコードも増えたけど5,337 行増えて7,312行減ったので 1,975行は減らせた • 設計を変えたおかげでViewとロジックを 分離できた
62. 今後の課題 • 改めて入出金履歴詳細画面の仕様自 体が複雑すぎることが分かったのでこ の画面自体の見直しが必要 • 設計ももう少し見直したほうが良いかも
63. ありがとうございました