どうしてコードはレガシーになるのか

どうしてコードはレガシーになるのか

～あるAndroidアプリのレガシー脱出記～

株式会社 Diverse・株式会社ミクシィ菊池

About me

@kikuchy (菊池紘)

株式会社ミクシィ ‑(出向)‑> 株式会社DiverseAndroidアプリ開発がメインAndroidオールスターズ2などで登壇しました

結論

レガシーコードとは何か

当たり前のことを当たり前にできなくさせるコード

‑> レガシーコード

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

人間が当たり前のことをやらない

‑> レガシーを生む

本題

デーティングサービス YYCとは男女の出会いの機会を提供しています

累計会員数1000万人以上

この前16周年でした

YYC AndroidYYCのAndroidアプリひと月で1.7万人以上の方にご利用いただいています

（エンジニア視点での）特徴

JavaとKotlinのハイブリットRxJavaを全面的に使用

リニューアル

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

劇的ビフォーアフター

旧新

ファイル数 370 (Java) 738 (Java + Kotlin)

平均行数 306 77 / 72 (Java / Kotlin)

最長ファイルの行数 4535 1275 / 462 (Java / Kotlin)

最長ファイルの種別 Activity View (1275行のファイル)

コードの見通しがよくなりました✧＼\ ۹( 'ω' )و /／✧

旧新

Clashrytics (直近30日のデータから)

撮影時点でのDAU 963 7343

クラッシュも少なくなりました₍₍ ᕕ(´ ω` *)ᕗ⁾⁾

横たわるレガシーコード

最長4535行のActivity全体的にコピペ

inner classから外のクラスへ参照もちまくり org.apache.http に密結合でSDKのアップデートができず

ローカル変数で良いものまで全部クラスフィールド

フィールドへ再代入しまくりで、どれがどのタイミングで変更され

るのか

コンストラクタの中で自クラスのインスタンスを作って何もしない

etc...

コンストラクタの中で自クラスのインスタンスを作って何もしない図

class Hoge { public Hoge(String param) { ... }

public Hoge() { // 誤 new Hoge("default"); // 正 // this("default"); }}

結果

高すぎるメンテナンスコスト

不安定、低評価

読めない・生理的に読みたくない

‑> そしてフルスクラッチでのリニューアル断行へ

二の轍は踏むまい

(´；ω；` )

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

イケてないポイント




フィールドへ再代入しまくりで、どれがどのタイミングで変更され

るのか

コンストラクタの中で自クラスのインスタンスを作って何もしない

原因と結果

1. 設計方針が不明瞭

2. 密結合

3. 力量不足 & セーフティネットの欠如

1. 設計方針が不明瞭前任者不在＆設計に関するドキュメント皆無

「この後どう書けばよいのか」後任にはっきりと伝わらない

そもそもAPI以外ほぼ全部がActivityに直書きされていた後任もそこに書けばいいと思ってしまう（思ってしまった）

割れ窓理論

その結果がこれだよ


2. 密結合設計方針が不明瞭であることも密結合になる原因の一つ

長大なコードがべた書きされている

修正にとても時間がかかる

そもそもモジュール化されていない

時間がかかりすぎるのでリファクタリングは断念された

古いコードを使い続けざるを得ない

更にべた書きのコードが増える

以下ループ




まずい書き方をする人が居て、それを止める仕組みがなかった

コードレビュー文化がない時代に書かれていた

コーディング規約もなかった

噂によると初期開発者のレベルはかなり低かったらしい



フィールドへ再代入しまくりで、どれがどのタイミングで変更

されるのか読めない

コンストラクタの中で自クラスのインスタンスを作って何もし

ない

そして対策

1. 設計方針が不明瞭‑> 設計とドキュメント

2. 密結合‑> モジュール化


‑> コードレビュー実施 & コーディング規約整備

設計とドキュメント

設計方針はClean ArchitectureとMVPの間の子依存は一方向に

重視する原則や歴史的経緯をWikiにクラス説明などはJavaDocコメントに

作った本人も、どんなものだったか忘れる

思い出せるので仕事が早い

モジュール化

普通にJavaらしくクラスを使う

ちゃんと役割分担する

情報源

情報の表示

仕様の実行

『何でもActivity (Controller)に書かない』と気をつけるだけでも違

う

処理の抽象度を高めることで、本質的なことだけ考えられる

コードレビュー実施 & コーディング規約整備

gitlabのMerge Request使用チームを跨いでのレビュー

弊社サービスpoiboyのAndroidメンバーと相互レビュー

全員のレベルアップ＋モチベーションアップ

規約を整備

AOSPとクックパッドさんのJavaコーディング規約をベースに

改変しながら

Kotlinの規約も用意考えないといけないことが減って楽に

当たり前じゃないか？

当たり前のことを当たり前にできなくさせる

コード

‑> レガシーコード

人間が当たり前のことをやらない

‑> レガシーを生む

当たり前のことを当たり前に

やっていきましょう

まとめ

当たり前のことをしないとレガシーコードが湧く

当たり前のことをするための環境整備をすべし

よいエンジニアライフを満喫しましょう！

✧＼\ ۹( 'ω' )و /／✧

どうしてコードはレガシーになるのか

Engineering