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

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
3. None
4. None

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. 戦いの終わり

56. None
57. None
58. None
59. None

60. 戦いの終わり • ４ヶ月くらいの長い戦いだった • 当初の目的だった電卓のデザインの統 一はもちろんできてよかった • 仕様がだいぶ整理できたのは良かった

61. 戦いの終わり • リファクタしてコードも増えたけど5,337 行増えて7,312行減ったので 1,975行は減らせた • 設計を変えたおかげでViewとロジックを 分離できた

62. 今後の課題 • 改めて入出金履歴詳細画面の仕様自 体が複雑すぎることが分かったのでこ の画面自体の見直しが必要 • 設計ももう少し見直したほうが良いかも

63. ありがとうございました