1.
どうしてコードはレガシーになるのか
～あるAndroidアプリのレガシー脱出記～
株式会社Diverse・株式会社ミクシィ 菊池

2.
About me
@kikuchy (菊池紘)
株式会社ミクシィ‑(出向)‑> 株式会社Diverse
Androidアプリ開発がメイン
Androidオールスターズ2などで登壇しました

3.
結論

4.
レガシーコードとは何か

5.
当たり前のことを当たり前にできなくさせるコード
‑> レガシーコード

6.
なぜコードはレガシーになってしまうのか？

7.
人間が当たり前のことをやらない
‑> レガシーを生む

8.
本題

9.
デーティングサービスYYCとは
男女の出会いの機会を提供しています
累計会員数1000万人以上
この前16周年でした

10.
YYC Android
YYCのAndroidアプリ
ひと月で1.7万人以上の方にご利用いただいています
（エンジニア視点での）特徴
JavaとKotlinのハイブリット
RxJavaを全面的に使用

11.
リニューアル
2016年初旬にフルスクラッチでリニューアルしました

12.
劇的ビフォーアフター

13.
旧 新
ファイル数 370 (Java) 738 (Java+ Kotlin)
平均行数 306 77 / 72 (Java/ Kotlin)
最長ファイルの行数 4535 1275 / 462 (Java/ Kotlin)
最長ファイルの種別 Activity View (1275行のファイル)
コードの見通しがよくなりました✧＼ ۹( 'ω' )‫ﻭ‬ /／✧

14.
旧 新
Clashrytics (直近30日のデータから)
撮影時点でのDAU 963 7343
クラッシュも少なくなりました₍₍ ᕕ(´ ω` *)ᕗ⁾⁾

15.
横たわるレガシーコード
最長4535行のActivity
全体的にコピペ
inner classから外のクラスへ参照もちまくり
org.apache.http に密結合でSDKのアップデートができず
ローカル変数で良いものまで全部クラスフィールド
フィールドへ再代入しまくりで、どれがどのタイミングで変更され
るのか
コンストラクタの中で自クラスのインスタンスを作って何もしない
etc...

16.
コンストラクタの中で自クラスのインスタンスを作って何もしない図
class Hoge {
public Hoge(String param) { ... }
public Hoge() {
// 誤
new Hoge("default");
// 正
// this("default");
}
}

17.
結果
高すぎるメンテナンスコスト
不安定、低評価
読めない・生理的に読みたくない
‑> そしてフルスクラッチでのリニューアル断行へ

18.
二の轍は踏むまい
(´；ω；` )

19.
なぜこのコードはレガシーになったのか

20.
イケてないポイント
最長4535行のActivity
全体的にコピペ
inner classから外のクラスへ参照もちまくり
org.apache.http に密結合でSDKのアップデートができず
ローカル変数で良いものまで全部クラスフィールド
フィールドへ再代入しまくりで、どれがどのタイミングで変更され
るのか
コンストラクタの中で自クラスのインスタンスを作って何もしない

21.
原因と結果
1. 設計方針が不明瞭
2. 密結合
3. 力量不足& セーフティネットの欠如

22.
1. 設計方針が不明瞭
前任者不在＆ 設計に関するドキュメント皆無
「この後どう書けばよいのか」後任にはっきりと伝わらない
そもそもAPI以外ほぼ全部がActivityに直書きされていた
後任もそこに書けばいいと思ってしまう（思ってしまった）
割れ窓理論
その結果がこれだよ
最長4535行のActivity
全体的にコピペ

23.
2. 密結合
設計方針が不明瞭であることも密結合になる原因の一つ
長大なコードがべた書きされている
修正にとても時間がかかる
そもそもモジュール化されていない
時間がかかりすぎるのでリファクタリングは断念された
古いコードを使い続けざるを得ない
更にべた書きのコードが増える
以下ループ
その結果がこれだよ
inner classから外のクラスへ参照もちまくり
org.apache.http に密結合でSDKのアップデートができず

24.
3. 力量不足& セーフティネットの欠如
まずい書き方をする人が居て、それを止める仕組みがなかった
コードレビュー文化がない時代に書かれていた
コーディング規約もなかった
噂によると初期開発者のレベルはかなり低かったらしい
その結果がこれだよ
ローカル変数で良いものまで全部クラスフィールド
フィールドへ再代入しまくりで、どれがどのタイミングで変更
されるのか読めない
コンストラクタの中で自クラスのインスタンスを作って何もし
ない

25.
そして対策
1. 設計方針が不明瞭
‑> 設計とドキュメント
2. 密結合
‑> モジュール化
3. 力量不足& セーフティネットの欠如
‑> コードレビュー実施& コーディング規約整備

26.
設計とドキュメント
設計方針はCleanArchitectureとMVPの間の子
依存は一方向に
重視する原則や歴史的経緯をWikiに
クラス説明などはJavaDocコメントに
作った本人も、どんなものだったか忘れる
思い出せるので仕事が早い

27.
モジュール化
普通にJavaらしくクラスを使う
ちゃんと役割分担する
情報源
情報の表示
仕様の実行
『何でもActivity (Controller)に書かない』と気をつけるだけでも違
う
処理の抽象度を高めることで、本質的なことだけ考えられる

28.
コードレビュー実施& コーディング規約整備
gitlabのMergeRequest使用
チームを跨いでのレビュー
弊社サービスpoiboyのAndroidメンバーと相互レビュー
全員のレベルアップ＋モチベーションアップ
規約を整備
AOSPとクックパッドさんのJavaコーディング規約をベースに
改変しながら
Kotlinの規約も用意
考えないといけないことが減って楽に

29.
当たり前じゃないか？

30.
当たり前のことを当たり前にできなくさせる
コード
‑> レガシーコード

31.
人間が当たり前のことをやらない
‑> レガシーを生む

32.
当たり前のことを当たり前に
やっていきましょう

33.
まとめ
当たり前のことをしないとレガシーコードが湧く
当たり前のことをするための環境整備をすべし

34.
よいエンジニアライフを満喫しましょう！
✧＼ ۹( 'ω' )‫ﻭ‬ /／✧