Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Da5a59469ce3ebb55619ce34f85f8c4f?s=47 syarihu
February 13, 2019

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

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

Da5a59469ce3ebb55619ce34f85f8c4f?s=128

syarihu

February 13, 2019
Tweet

More Decks by syarihu

Other Decks in Technology

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. 戦いの準備 • 手入力改善をやることになったのが6月 ごろ ◦ この時期は1人で開発していたので 全てを把握しやすい状況だった ◦ 新卒も入ってくるしメンバーが 増えると今のままだとやばい

  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. やること • ここまでの対応で2つのFragmentへの 依存が完全に消えたので関連ファイル をすべて消し飛ばす

  54. やった結果

  55. 戦いの終わり

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

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

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

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