ビジネス中心に7年間走り続けたAndroidをリアーキしてる話

Transcript

1. ビジネス中心に7年間走り続けた Androidをリアーキしてる話 2021/05/19 @ Qiita × Uzabase Tech Meetup#2 Koji Ishii ~ UZABASEの7つのルールを添えて ~
2. 2 自己紹介 Qiitaではこんな記事書いてました
3. 3 自己紹介 こんな本書いてます。 iOS/Androidもガッツリ書いてきまし た。
4. 4 自己紹介 法人向けNewsPicks エンジニアリングマネージャー (開発リーダー) スマフォチームに所属していない、 たまにしかスマフォ実装してなかっ たが 今回のリアーキではガッツリ書きま した。 この件がきっかけで、来月からスマ フォチームのリーダーに抜擢されま した。
5. • 自由主義でいこう • 創造性がなければ意味がない • ユーザの理想から始める • スピードで驚かす • 迷ったら挑戦する道を選ぶ • 渦中の友を助ける • 異能は才能 ユーザベース 7つのルール 5
6. なぜ変えるのか (Why) どのように変えていったか (How) このように変えてます (What) 今後の展望 01 02 03 04 6 目次
7. 01 | なぜ変えるのか（Why）
8. 優秀なAndroidエンジニアで構成され ているチーム (私は別チーム所属) • 社員 • 長く参画してくれてるフリーエンジニア • 業務委託の方（最近参加） NewsPicksのアプリを使っていた人ならわかる。 技術力がないとできないUI。そしてスピード感あるリリース頻度 01 | なぜ変えるのか 8 ユーザの理想から始める スピードで驚かす
9. 正直いうとここ10年で一番ひどいコード。 少し触るだけでバグが出る。 もう辞める... 優秀な業務委託の方 01 | なぜ変えるのか 9
10. なぜ技術力があるメンバーでもこう なったか ビジネス優先で走り続けてきた結果です。 NewsPicksは高い成長を続けています。 ビジネス的にやりたいことだらけです。 何度かリニューアルやアーキテクチャ変更はした が、抜本的な変更をする時間が取れなかったし、 体制が取れなかった。 01 | なぜ変えるのか 10
11. 01 | なぜ変えるのか 11 具体的な技術構成 / 問題点 • 巨大な1つのモジュール。ルールベースでレイヤーが切られている。 ◦ ルール違反はPRで指摘するしかない。ルールってなんだっけ？ • カスタムApplicationクラスへの依存が多い ◦ テストコードも書きづらいし、容易に循環参照しちゃう • 単体テストがほぼなし ◦ 気楽にリファクタできない • ライブラリなどのバージョンを気楽にあげられない ◦ 上げると思わぬクラッシュ • いろんなアーキテクチャが混在 ◦ HttpClientだけみても、Volley, Ktor, Retrofit2 • EventBusの乱用 ◦ 追いづらい • 属人性のあるコード ◦ レビューで指摘されるのは過去を知らないと書けないやつとか • ABテストの残骸 ◦ 消そうぜ • ViewModelの中でViewを使っちゃてるよ ◦ ・・・
12. 01 | なぜ変えるのか 12 技術的負債が溜まりすぎ
13. 会計の負債 負債（借金）があってもそこから負債以上の利益 が出てれば問題ないですよね。 利益が出せてるんだから、負債は返せばいいんで す！ 01 | なぜ変えるのか 13
14. 残ってしまっている技術的負債 その時は最適だったりそれで良かったのが 時代や組織、事業フェーズの変化によって 適さなくなった資産 アルファドライブ(ユーザベースグルー プ)CTO 01 | なぜ変えるのか 14 技術的負債って？
15. このままでは昔からいる人が万が一辞めて しまったら、開発スピードは確実に落ちる し、バグも増える。何よりも技術スタック 的にも魅力がなくて優秀なエンジニアを採 用できない。たとえ採用できてもスピード が出せない。 法人開発者リーダー（表） 01 | なぜ変えるのか 15
16. このまま何年も実装していくのはつまらん な。技術者としてこれ続けると終わってい きそうで不安だ。モチベーションあがら ん。 あと法人の機能は、俺じゃなくてもスマ フォ経験値が少ない開発者でも実装できる ようにしたいな。俺、楽になるし。 01 | なぜ変えるのか 16 法人開発者リーダー（裏）
17. 02 | どのように変えていったか(How) 技術じゃなく方法
18. 02 | どのように変えていったか 18 大前提 • 法人向け機能はザ・ビジネス。握ったスケジュールは絶 対。できるだけ速く機能を出して解約させない・獲得確 率を上げたい • Androidチームも他のビジネスの実装を進めているし人 数も少ない。誰も頼れない。 • 俺はこのまま実装続けるの嫌だ。絶対アーキテクチャを 変えたい (統一したい) • 俺、法人開発リーダだし責任重大。遅延、ダメ
19. 1人でもやり切ってやるという意思のみ + (今までの経験/自信) ただし、リスクは最小にしたい。 具体的には、間に合わなそうな場合に実装する時 間の確保をどうするか。 -> 年末年始の休暇と※ ロンバケ制度がある。 ※ 半期に一度、有給とは別に5日連続休暇できる制度 ユーザの理想から始める 02 | どのように変えていったか 19 迷ったら挑戦する道を選ぶ
20. 02 | どのように変えていったか 20 こう進めた • Androidチームに「法人の新機能で新アーキテクチャを使い たい」と頭出し。一般的に知られている文言でざっくり説明 （抽象的） (MVVM/Databinding/Repositoryとかとか) • 2週間ぐらいで実践で使えるレベルのサンプル実装を作成。 一般論だったアイデアを現実の世界に耐えられるレベルま で作成し、Androidチームに合意 • 法人チームは他のメンバーにリーダー業務やiOS開発をで きる部分は委譲 • で、孤独の中で法人の機能の実装開始
21. 02 | どのように変えていったか 21 途中まで • 想像していた以上に既存コードの影響を受けるので、回避す るための実装が必要 • 既存の機能を新で作ろうとしたときに想像以上に複雑な仕様 -> 開発量がとんでもなく多いことがわかってきた... やばい！！！
22. 俺、手伝うよ！！ 楽しそうじゃん！！ Androidチーム 社員 02 | どのように変えていったか 22 渦中の友を助ける
23. 02 | どのように変えていったか 23 結果 • 法人機能はスケジュール通りリリース（休暇取れたよ） • NewsPicksの経験がない外部委託の開発者でも問題なく実装できて いるし、Android経験がない開発者も実装可能に • 法人機能以外も新アーキテクチャに移行が決定 • Androidチームが負債解消のため2人 -> 5人体制になる • 採用時に優秀な人を採用しやすくなっている • iOSも技術的負債解消のプロジェクト開始(SwiftUIなど)
24. 03 | このように変えてます（What）
25. 03 | このように変えてます 25 • NewsPicks -> 元々全てのコードが入っていたモジュール。 Applicationクラスだけに依存 するように変更中 • ui -> UIに関連する全て。Activity,Fragment,ViewModel。ViewModelは全くViewに依存さ せない • infrastructures -> 永続レイヤー。HttpやDBにアクセスする • domains -> ビジネスロジック, ValueObject, EntityなどDDDの考えを取り入れた • マルチモジュール化 • 明確な役割のあるレイヤーで分 割することで依存させるライブラ リを変える • コンパイラーに任せる • 古いコードは一旦legacyモ ジュールに突っ込む • legacyは洗練されてないので無 駄なコードが多い（ビルドが遅 い） • 新コードはlegacy依存がないの でビルドが早い
26. 03 | このように変えてます 26 • 依存性逆転を容易にしたいので DI導入(Dagger Hilt) • 非同期処理はCoroutines Flow • LiveDataは使わない。Coroutinesだけ。（独自クラスでやってるが StateFlowにするかも） • Databindingは、@BindingConversionや@BindingAdapterをフル活用。
27. 03 | このように変えてます 27 その他、便利クラスを作成 たとえば、縦・横の一覧系は、独自 RecyclerViewAdapter作成したことで、一つのクラスだけで全ての一覧系の デザインに対応可能 (Groupieみたいなやつ)にしたり、Dialog系や共通エラーとか色々便利なクラスを実装し、 Wikiに記述。実装でルールを縛り処理の統一性を保っている
28. 04 | 今後の展望
29. 04 | 今後の展望 29 • 新アーキテクチャに移行を進める • テストは必須にして、進化し続けるアーキテクチャを目指す • iOSも同様 • NewsPicksで技術的ブランドを確立したい • 20%ルールを作る！（役員も合意） • Android / iOS ともに 5名体制を構築のためいろんなタイプの人を積 極採用中 創造性がなければ意味がない 異能は才能
30. 30 締め • 意思があれば、システム改善は絶対できるよ • ただし、組織の文化は大事。（意思を実現し やすいかどうか） • たまには無茶(新機能を作りつつリアーキを1 人でやろうとした・・・)してもいいかも。 周りの環境がいい方向に変わる。
31. • 創造性がなければ意味がない • ユーザの理想から始める • スピードで驚かす • 迷ったら挑戦する道を選ぶ • 渦中の友を助ける • 異能は才能 ユーザベース 7つのルール 31 • 自由主義でいこう
32. ご清聴ありがとうございました 32