エンジニア1年目で複雑なコードの改善に取り組んだ話

DroidKaigi 2024での登壇資料です。
https://2024.droidkaigi.jp/timetable/694515/

Transcript

1. AbemaTV, Inc. All Rights Reserved
 AbemaTV, Inc. All Rights Reserved
 1 エンジニア1年目で 複雑なコードの改善に 取り組んだ話 2024 September 12th たなむら (@mtnmr) DroidKaigi 2024
2. AbemaTV, Inc. All Rights Reserved
 2 自己紹介 2023.4 株式会社サイバーエージェント 2023.5 株式会社AbemaTV Native Mobileチーム / Androidエンジニア たなむら (@mtnmr)
3. AbemaTV, Inc. All Rights Reserved
 3 エンジニアになるまで 総合病院で臨床検査技師 ⇩ 主婦 && プログラミング勉強期間 1年ちょっと💻 ⇩ サイバーエージェントにRe:Career採用で入社・この時点で業務経験なし ※ Re:Career採用 既卒・社会人向けの採用 選考フローは分かれているものの入社後は新卒として研修・配属・サポートを受けられる
4. AbemaTV, Inc. All Rights Reserved
 4 エンジニアになるまで 独学勉強中はCodelabが楽しくてひたすらやっていた • Jetpack Compose • MVVM • Retrofit • Coroutine • Hilt 　　など
5. AbemaTV, Inc. All Rights Reserved
 5 エンジニアになって思ったこと • 新しい技術は移り変わるので、リリースから数年経ったアプリには レガシーコードが必ずある • レガシーコードがアプリの根幹となる機能を今も支えていたりして 簡単には変えられない • 今のアプリ開発のスタンダードを知っていることはもちろん大事だが それだけでは業務できない... レガシーコードに向き合う力が必要
6. AbemaTV, Inc. All Rights Reserved
 6 レガシーコードとは マイケル•C•フェザーズ(2009)『レガシーコード改善ガイド』翔泳社 テストのないコード 修正、拡張、作業が 非常に難しいコード David Scott Bernstein (2019)『レガシーコードからの脱却 ―ソフトウェア の寿命を延ばし価値を高める9つのプラクティス』オライリージャパン
7. AbemaTV, Inc. All Rights Reserved
 7 レガシーコードとは 変更しづらいコード • 使用技術が古くなっている ◦ キャッチアップコストが高く、変更を入れづらい ◦ メンテナンスが継続されているのか怪しいライブラリの使用 • 当時の仕様・実装された意図が不明 ◦ 何か理由があってそうなっているかもしれないので変更が入れづらい
8. AbemaTV, Inc. All Rights Reserved
 8 この発表で伝えたいこと エンジニア1年目の秋、2ヶ月半ほどかけてレガシーコードの改善に取り組んだ🔥 • 経験したプロジェクトの進め方から レガシーコード改善に悩む誰かのヒントになれたら嬉しい • 自分の書くコードをレガシーになりにくくしたい！ そのために今何ができるのか、自分が考えていること
9. AbemaTV, Inc. All Rights Reserved
 9 1. レガシーコード改善に至るまでの背景 2. リリースまでの詳細プロセス 3. プロジェクト後の効果 4. 今からできる自分のコード改善 目次
10. AbemaTV, Inc. All Rights Reserved
 10 1. レガシーコード改善に至るまでの背景 2. リリースまでの詳細プロセス 3. プロジェクト後の効果 4. 今からできる自分のコード改善 目次
11. AbemaTV, Inc. All Rights Reserved
 11 ABEMA モバイルアプリについて • ABEMAは発足から10年目 ◦ Androidのリポジトリも2015年7月が最初のコミット ◦ 2016年2月29日にAndroidモバイルアプリがリリース • 提供機能 ◦ 24時間365日番組型の放送 ◦ ビデオ・ライブ配信などの動画視聴 ◦ ABEMAプレミアム ◦ パートナーサービス new!
12. AbemaTV, Inc. All Rights Reserved
 12 リアーキテクチャの取り組み • 元々Fluxアーキテクチャを採用 • 2019年10月 Android / iOSがNativeチームとして統合 ◦ PF間での仕様差異あり ◦ 共通仕様となるビジネスロジックとPF固有の処理が分離できていない 共通化を目指してリアーキテクチャ
13. AbemaTV, Inc. All Rights Reserved
 13 リアーキテクチャの取り組み Clean Architectureベースのアーキテクチャ + KMPの採用 『ABEMA モバイルアプリにおけるリアーキテクチャの取り組みと展望』（CA BASE NEXT 2021） https://ca-base-next.cyberagent.co.jp/2021/sessions/abema-mobile-rearchitecture/
14. AbemaTV, Inc. All Rights Reserved
 14 リアーキテクチャの取り組み リアーキテクチャしていない部分もある • Android固有処理が多くiOSとの共通化をしない実装 ◦ 課金処理基盤 ◦ アプリ全体で使うユーザー情報や端末情報 など • 改修頻度が少ない機能
15. AbemaTV, Inc. All Rights Reserved
 15 リアーキテクチャの取り組み リアーキテクチャしていない部分もある • Android固有処理が多くiOSとの共通化をしない実装 ◦ 課金処理基盤 今回のレガシーコードはこれ！ ◦ アプリ全体で使うユーザー情報や端末情報 など • 改修頻度が少ない機能
16. AbemaTV, Inc. All Rights Reserved
 16 課金基盤のFlux解体プロジェクト ABEMAプレミアム以外の定期購読の提供のために 課金基盤を拡張 or 修正が予定されていた
17. AbemaTV, Inc. All Rights Reserved
 17 課金基盤のFlux解体プロジェクト ABEMAプレミアム以外の定期購読の提供のために 課金基盤を拡張 or 修正が予定されていた が、、、既存実装が複雑だったので変更しにくい😢 既存のまま頑張って拡張　vs　作り替えコスト
18. AbemaTV, Inc. All Rights Reserved
 18 課金基盤のFlux解体プロジェクト ABEMAプレミアム以外の定期購読の提供のために 課金基盤を拡張 or 修正が予定されていた が、、、既存実装が複雑だったので変更しにくい😢 既存のまま頑張って拡張　vs　作り替えコスト 課金基盤の刷新をしよう！
19. AbemaTV, Inc. All Rights Reserved
 19 1. レガシーコード改善に至るまでの背景 2. リリースまでの詳細プロセス 3. プロジェクト後の効果 4. 今からできる自分のコード改善 目次
20. AbemaTV, Inc. All Rights Reserved
 20 課金基盤のFlux解体プロジェクト キャッチ アップ 設計 実装 QA テスト リリース
21. AbemaTV, Inc. All Rights Reserved
 21 課金基盤のFlux解体プロジェクト キャッチ アップ 設計 実装 QA テスト リリース およそ2ヶ月半 相談しながら1人 実装2人 レビュワー1人
22. AbemaTV, Inc. All Rights Reserved
 22 課金基盤のFlux解体プロジェクト キャッチ アップ 設計 実装 QA テスト リリース
23. AbemaTV, Inc. All Rights Reserved
 23 キャッチアップ 既存仕様を理解していないと改修できない！
24. AbemaTV, Inc. All Rights Reserved
 24 キャッチアップ どういうコードだったか 機能 アプリ内決済 （定期購読・アカウント復元などのロジックをもつ） 変遷 2016年最初の基盤実装 → Kotlin化・Google Billing Library移行・Amazon対応... → 2018年頃には2023年現在の形に 技術 Fluxアーキテクチャ 非同期処理はRxJava
25. AbemaTV, Inc. All Rights Reserved
 25 キャッチアップ つらみ
26. AbemaTV, Inc. All Rights Reserved
 26 キャッチアップ つらみ • Flux、RxJavaに触れてこなかったので初見
27. AbemaTV, Inc. All Rights Reserved
 27 キャッチアップ つらみ • Flux、RxJavaに触れてこなかったので初見 • 購入による副作用やエラーハンドリングは明確な仕様書がなかった ◦ 既存のコードリーディングが頼り
28. AbemaTV, Inc. All Rights Reserved
 28 キャッチアップ • Flux、RxJavaに触れてこなかったので初見 • 購入による副作用やエラーハンドリングは明確な仕様書がなかった ◦ 既存のコードリーディングが頼り • 抽象クラスと、それを継承した具象クラス（Google / Amazon）を 行き来したフロー ◦ メソッドを一貫して追いづらい つらみ
29. AbemaTV, Inc. All Rights Reserved
 29 キャッチアップ つらみ
30. AbemaTV, Inc. All Rights Reserved
 30 キャッチアップ つらみ 具象クラスをたどらないと どこで呼ばれる共通処理かわからない Google/Amazonで 実装
31. AbemaTV, Inc. All Rights Reserved
 31 キャッチアップ • 技術書 ◦ 少し前の本がこういう時に役立つ...！ ◦ 『Androidアプリ設計パターン入門』 PEAKS • ChatGPT ◦ 雑に聞いて得られたキーワードからドキュメントや実装例を探す • 過去のPRを参照する やったこと1: 分からないまま進めずインプット
32. AbemaTV, Inc. All Rights Reserved
 32 キャッチアップ やったこと2: 既存のシーケンスを書き起こす 非公開🤐
33. AbemaTV, Inc. All Rights Reserved
 33 キャッチアップ やったこと2: 既存のシーケンスを書き起こす • 全体のフローが掴めた ◦ 共通処理 / 購入PFに依存する処理の整理 • 設計・実装フェーズで既存実装を見直したいときの参考になった • この改修を自分に任せられるか？という判断軸にもなったかも
34. AbemaTV, Inc. All Rights Reserved
 34 課金基盤のFlux解体プロジェクト キャッチ アップ 設計 実装 QA テスト リリース
35. AbemaTV, Inc. All Rights Reserved
 設計 35 方針 既存実装には変更を加えず、再実装して置き換える • 現行で採用しているアーキテクチャに合わせて FluxをやめClean Architectureベースの形にする • 購入PF固有の処理はインターフェースに抽出して 継承ではなく委譲によって切り出す
36. AbemaTV, Inc. All Rights Reserved
 設計 36 方針 既存実装には変更を加えず、再実装して置き換える • 現行で採用しているアーキテクチャに合わせて FluxをやめClean Architectureベースの形にする • 購入PF固有の処理はインターフェースに抽出して 継承ではなく委譲によって切り出す
37. AbemaTV, Inc. All Rights Reserved
 設計 37 Fluxアーキテクチャ • 単一方向のデータフロー https://facebookarchive.github.io/flux/docs/in-depth-overview
38. AbemaTV, Inc. All Rights Reserved
 設計 Fluxアーキテクチャ
39. AbemaTV, Inc. All Rights Reserved
 設計 39 Clean Architecture • レイヤーごとに関心の分離 • 依存は外側から内側にだけ向かう Robert C. Martin『The Clean Architecture』 https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
40. AbemaTV, Inc. All Rights Reserved
 40 設計 再設計 FluxのAction （Viewの操作によって 実行する処理） FluxのStore （結果の受け取り） UseCase UiLogic （ViewModel / View） ドメインモデルを定義 Repositoryに保存 UIの表示ロジック ビジネスロジック
41. AbemaTV, Inc. All Rights Reserved
 設計 41 再設計
42. AbemaTV, Inc. All Rights Reserved
 設計 42 方針 既存実装には変更を加えず、再実装して置き換える • 現行で採用しているアーキテクチャに合わせて FluxをやめClean Architectureベースの形にする • 購入PF固有の処理はインターフェースに抽出して 継承ではなく委譲によって切り出す
43. AbemaTV, Inc. All Rights Reserved
 設計 43 固有処理の分離 abstract classの継承 インターフェースの実装 • PF固有処理になる部分をインターフェースに分離 • Google / Amazonそれぞれの実装クラスを作成 ◦ Hiltで適切な実装クラスをDIする
44. AbemaTV, Inc. All Rights Reserved
 設計 44 固有処理の分離 固有処理は インターフェースで呼ぶ それぞれの実装 クラスを作る
45. AbemaTV, Inc. All Rights Reserved
 設計 45 どうやって進めたか • 設計開始してから1日の終わりに共有・相談ミーティングを実施 ◦ 頻度高く実施したことで設計方針がずれていかなかった ◦ 先輩エンジニアの設計の考え方をかなりインプットできた • 全体設計はAndroidエンジニアの実装共有会でも相談・共有 ◦ 懸念になる部分をクリアにしてから実装に進めた
46. AbemaTV, Inc. All Rights Reserved
 設計 46 どうやって進めたか • 設計はラフに、コードベースで進めるのはどう？ ◦ 設計の意思疎通・スキル把握ができているチームなら有効◎ ◦ そうでない場合大幅な遅れにつながるリスクがありそう ▪ 今回は1年目エンジニアが設計しているため 時間をかけてチームとしてすり合わせた
47. AbemaTV, Inc. All Rights Reserved
 設計 47 最終アウトプット シーケンスとクラス設計を決定 非公開🤐 非公開🤐
48. AbemaTV, Inc. All Rights Reserved
 48 課金基盤のFlux解体プロジェクト キャッチ アップ 設計 実装 QA テスト リリース
49. AbemaTV, Inc. All Rights Reserved
 実装 49 どうやって進めたか • 設計を元に2人で実装＋レビュワー1人 • トランクベース開発 ◦ ドメイン・インターフェースから定義する ▪ 共通クラス・PF実装クラスを同時に進めてもコンフリクトしない ◦ 分割できる実装は分けて早めにレビューをもらう ▪ 設計固めているが細かいずれに早く気づける
50. AbemaTV, Inc. All Rights Reserved
 実装 50 どうやって進めたか • もらったコメントを修正するだけで終わらせない ◦ 理解した上でコードを書く 口頭で聞いたこともメモ📝
51. AbemaTV, Inc. All Rights Reserved
 51 課金基盤のFlux解体プロジェクト キャッチ アップ 設計 実装 QA テスト リリース
52. AbemaTV, Inc. All Rights Reserved
 テスト 52 つらみ 1から作り直したので挙動の担保が心配 その上変更箇所が課金基盤のため不具合があったらかなりクリティカル😇
53. AbemaTV, Inc. All Rights Reserved
 テスト 53 ユニットテスト • 全体実装ができてから作成 ◦ 機能ごとに正常系を先に書く → その後異常系を追加 • ABEMAのサーバー・課金SDKからのレスポンスによるパターンが多い ◦ 網羅性：パラメータ化テスト ◦ 可読性：テストパターンを構造化
54. AbemaTV, Inc. All Rights Reserved
 テスト 54 ユニットテスト テストパターンが多いので メソッドを列挙せず構造化 レスポンスのパターンごとに ハンドリングが違うため パラメータ化して網羅的にテスト 購入テスト内で共通の準備を 実行するベースクラスを作る
55. AbemaTV, Inc. All Rights Reserved
 テスト 55 ユニットテスト • TDDという選択肢はなかった？ ◦ 当時の自分には知識がなかった ◦ このプロジェクト後に課金機能拡張が控えており キャッチアップの時間が取れなかった
56. AbemaTV, Inc. All Rights Reserved
 テスト 56 QA • エラー時のユーザーフィードバックまで含めて網羅的に実施 • QAチームとの連携 ◦ 項目書を元にテキストでのやりとり ◦ 影響範囲や特定条件でのパターンのすり合わせなど 進捗に合わせて定期ミーティングをするのが良かったかも
57. AbemaTV, Inc. All Rights Reserved
 57 課金基盤のFlux解体プロジェクト キャッチ アップ 設計 実装 QA テスト リリース
58. AbemaTV, Inc. All Rights Reserved
 リリース 58 安全に100%適用したい...！ • Feature Flag ◦ コードを書き換えずにフラグのオン/オフによって 動的に機能を変更できる ◦ 機能を任意のタイミングで有効化・ABテストに利用
59. AbemaTV, Inc. All Rights Reserved
 リリース 59 Feature Flagによる制御 • Google / Amazon固有の問題があっても 独立して切り戻すことができるようフラグを分けて設定 PFごとに設定されたフラグを参照 購入処理呼び出し
60. AbemaTV, Inc. All Rights Reserved
 リリース 60 安定リリース • ユーザーに100％適用してSLIやログの監視 • 安定リリース後 ◦ 設定したFeature Flagを無効化・削除 ◦ 旧課金基盤実装を削除 ◦ 削除までやらないと負債として残ってしまう
61. AbemaTV, Inc. All Rights Reserved
 課金基盤のFlux解体プロジェクト 61 プロジェクト終了！ 今まで課金基盤を支えてくれた旧実装、ありがとう😭
62. AbemaTV, Inc. All Rights Reserved
 課金基盤のFlux解体プロジェクトまとめ 62 キャッチ アップ 設計 実装 QA テスト リリース ・既存実装書き起こし ・分からないままにせず 　インプット ・リアーキテクチャ ・インターフェース分離 ・定期的なレビュー ・設計をもとに分担 ・トランクベース ・機能の担保（網羅性） ・理解のしやすさ（可読性） ・Feature Flag ・旧実装の削除まで
63. AbemaTV, Inc. All Rights Reserved
 63 1. レガシーコード改善に至るまでの背景 2. リリースまでの詳細プロセス 3. プロジェクト後の効果 4. 今からできる自分のコード改善 目次
64. AbemaTV, Inc. All Rights Reserved
 復習・今回のプロジェクトの目的 64 • 課金処理を拡張していきたかったが既存のまま拡張するコストが高く、 先にレガシーコードを作り替えるのが良いという判断 • コード改善に時間をかけられない問題 ◦ 継続的な成長・開発速度の向上のためにやった方が良い場合がある ◦ 新規機能の追加・ユーザー体験の改善と比較してメリットが 見えにくい、コストと効果が見合わない ◦ 今回は目的が明確にあり人的コストをかけられた
65. AbemaTV, Inc. All Rights Reserved
 プロジェクトの効果 65 • 機能拡張時の設計コスト ⬇ • 課金処理のキャッチアップコスト ⬇ • ドキュメントが整備された ◦ iOSとの実装差異を含めた整理 ◦ 処理フローとユーザー体験 チーム
66. AbemaTV, Inc. All Rights Reserved
 プロジェクトの効果 66 • 経験値💰 ◦ コード理解力（レガシーコードに怯まない） ◦ 設計力（方針を実現できるような全体像を考える） • 自信🔥 ◦ サポート受けながらも大きなコード改善をリリースまでやり切った 個人
67. AbemaTV, Inc. All Rights Reserved
 なんで1年目エンジニアにやり切れた？ 67 • 自分の理解度を整理して伝える（アウトプットを残す） • 疑問に思ったことを相談する • 早くフィードバックをもらえる進め方をする
68. AbemaTV, Inc. All Rights Reserved
 なんで1年目エンジニアにやり切れた？ 68 結論
69. AbemaTV, Inc. All Rights Reserved
 なんで1年目エンジニアにやり切れた？ 69 プロジェクトを適切に進められるかは技術力に寄らない部分が大きい ⚠1番避けたいのはふんわりした理解や思い込みのまま確認を取らずに進めること 自分の状況や考えを伝える + 先輩エンジニアの思考を吸収できるか コミュニケーション 結論
70. AbemaTV, Inc. All Rights Reserved
 70 1. レガシーコード改善に至るまでの背景 2. リリースまでの詳細プロセス 3. プロジェクト後の効果 4. 今からできる自分のコード改善 目次
71. AbemaTV, Inc. All Rights Reserved
 レガシーコードになりにくくしたい！ 71 技術力・知識をつける以外に 今からできることはある💪
72. AbemaTV, Inc. All Rights Reserved
 レガシーコードから感じた辛み 72 変更のしづらさに繋がっていること • 古くなった技術のキャッチアップ • 複雑な処理だと理解に時間がかかる • 仕様や意図が不明
73. AbemaTV, Inc. All Rights Reserved
 レガシーコードから感じた辛み 73 変更のしづらさに繋がっていること • 古くなった技術のキャッチアップ • 複雑な処理だと理解に時間がかかる • 仕様や意図が不明 これを減らしたい！
74. AbemaTV, Inc. All Rights Reserved
 レガシーコードから感じた辛み 74 変更のしづらさに繋がっていること • 古くなった技術のキャッチアップ • 複雑な処理だと理解に時間がかかる • 仕様や意図が不明 実装当時の最善の選択による偉大なコードなので キャッチアップする側が頑張る できるだけコードを読みやすくすることで改善！ できるだけ手がかりを残すことで改善！
75. AbemaTV, Inc. All Rights Reserved
 読みやすいコードを書く 75 • コード行数が短いほど良いわけではない • メソッドの責務分離 • クラス・メソッドの命名 • 適切なコードコメント など Dustin Boswell, Trevor Foucher (2012) 『リーダブルコード』オライリージャパン Chris Zimmerman (2023) 『ルールズ・オブ・プログラミング より良いコードを書くための21のルール』オライリージャパン
76. AbemaTV, Inc. All Rights Reserved
 キャッチアップの手がかりを残す 76 • ドキュメントになっていないものを残す ◦ ⚠ただしメンテナンスされないと負債になる可能性も秘めている • PRから辿れるようにリンクする ◦ 当時の設計書 ◦ 仕様書 ◦ その他参考資料
77. AbemaTV, Inc. All Rights Reserved
 まとめ 77 • 自分が経験したレガシーコード改善の詳細プロセス ◦ コミュニケーションをしっかり取りながらプロジェクト完遂し、 その後の効果が大きい改善になった ◦ これが常に最適解というわけではなく その時の状況やレベルに合わせて選択する • 1年目でレガシーコードに向き合って多くの学びが得られた ◦ 経験と自信 ◦ 自分が残すコードやドキュメントへの考え方
78. AbemaTV, Inc. All Rights Reserved
 参考 78 過去発表資料 • 『ABEMA モバイルアプリにおけるリアーキテクチャの取り組みと展望』（CA BASE NEXT 2021） https://ca-base-next.cyberagent.co.jp/2021/sessions/abema-mobile-rearchitecture/ 書籍 • マイケル•C•フェザーズ（2009）『レガシーコード改善ガイド』（ウルシステムズ株式会社監訳, 平澤 章, 越智 典子, 稲葉 信之, 田村 友彦, 小堀 真義 訳）翔泳社 • David Scott Bernstein （2019）『レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス』（吉羽 龍太郎, 永瀬 美穂, 原田 騎郎, 有野 雅士 訳）オライリージャパン • 日高 正博, 小西裕介, 藤原聖, 吉岡 毅, 今井 智章（2018） 『Androidアプリ設計パターン入門』PEAKS出版 • Robert C.Martin（2018）『Clean Architecture 達人に学ぶソフトウェアの構造と設計』（角 征典, 高木 正弘 訳）アスキードワンゴ • Dustin Boswell, Trevor Foucher（2012） 『リーダブルコード』（角 征典 訳）オライリージャパン • Chris Zimmerman（2023） 『ルールズ・オブ・プログラミング より良いコードを書くための21のルール』（久富木 隆一訳）オライリージャパン サイト • Flux https://facebookarchive.github.io/flux/docs/in-depth-overview • Robert C. Martin『The Clean Architecture』 https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
79. AbemaTV, Inc. All Rights Reserved
 Special Thanks 79 • 課金基盤のFlux解体プロジェクト ◦ Index197511 さん ◦ AkitoshiHashizume さん • ABEMA Nativeチームの皆さん
80. AbemaTV, Inc. All Rights Reserved