@MIXI Androidエンジニア新年会 2025.01.16 可読性の低いコードを生み出してしまった時 の反省記録 with レガシーコード 1

©MIXI 2 2 ⾃⼰紹介 ● ばやすてぃー（髙林明⽇美） ○ X: @bayastea ● Androidエンジニア @株式会社MIXI ● サロンスタッフ直接予約アプリ「minimo」開発

©MIXI 3 3 minimo について

©MIXI 4 4 ⽬次 1. やらかしに⾄るまで a. 背景 b. いざ実装 c. 何が起きたか？ 2. 原因 a. 負債に対する向き合い⽅がわかっていなかった b. 良い設計⽅法に対しての知識が⾜りていなかった 3. まとめ

©MIXI 5 5 やらかしに⾄るまで - 1 実装内容 ● 検索画⾯に特定の条件を満たす掲載者をピックアップして表⽰ ○ すでに似たような機能あり ● 「OOの場合はXXX」といった仕様が多く複雑 開発までの経緯 ● 次の施策までのスポット施策として対応 ● ちょうどキリがいいので年内までにサクッとやりたい

©MIXI 6 6 やらかしに⾄るまで - 2 プロダクトについて前提 ● 10年以上続くサービスのため負債が多い ● 検索機能は核となる機能のため、特にコードの量が多く複雑 ⾃分について ● プロダクトにジョインして半年未満 ● 前職では新規開発を主に対応 ○ ⻑く保守するプロダクトは少なかった

©MIXI 7 7 いざ実装 などと思いながらなんとか⾃分なりに実装 変に触ってバグったら 怖いな 空気を読んで既存コードに 倣って書いていこう 軽い施策らしいしサクッと 作りたいなあ ただでさえif分岐多いのに さらに増えるのか...

©MIXI 8 8 何が起きたか？ ● レビュー時になって可読性の悪さ‧拡張性の低さを⼤量に指摘された ○ ⾃分ではわかりやすいコードを書いたつもりだったのに... ○ 可読性が低いことでレビューを難航させてしまった ● 条件分岐が増えたことで、レアケースで仕様漏れが発覚 その結果レビュー修正 & バグ修正で⼿戻りが増えてしまった

©MIXI 9 9 原因 負債に対する向き合い⽅がわかっていなかった & 良い設計⽅法に対しての知識が⾜りていなかった

©MIXI 10 10 原因 負債に対する向き合い⽅がわかっていなかった & 良い設計⽅法に対しての知識が⾜りていなかった

©MIXI 11 11 原因 - 負債に対する向き合い⽅ BAD ● 早く実装したいから⼤⽅雰囲気を掴めたら実装に⼊る ● レガシーコード = 開けてはいけないパンドラの箱だと思っている ● なるべく既存コードは触らず、前例に倣って実装する

©MIXI 12 12 原因 - 負債に対する向き合い⽅ 既存コードに追加するだけだとどこかで限界が来る 例） ● 当初予定していなかった変更が追加されることで 条件⽂がどんどん⻑くなる ○ 既存の if ⽂に今回追加した「特定基準の掲載者」を追加してごちゃごちゃに ○ もし今後「星5掲載者」のような区分が追加されたら...？ ● 変数名と中⾝が⼀致しない

©MIXI 13 13 原因 - 負債に対する向き合い⽅ 既存コードに追加するだけだとどこかで限界が来る 例） ● 当初予定していなかった変更が追加されることで 条件⽂がどんどん⻑くなる ○ 既存の if ⽂に今回追加した「特定掲載者」を追加してごちゃごちゃに ○ もし今後「星5掲載者」のような区分が追加されたら...？ ● 変数名と中⾝が⼀致しない レガシーコード = 触ってはいけないと思い込むのはやめよう 既存コードを雰囲気だけで理解するのはやめよう ⾃分なりの設計を考えて⼀次レビューやペアプロを依頼しよう

©MIXI 14 14 原因 負債に対する向き合い⽅がわかっていなかった & 良い設計⽅法に対しての知識が⾜りていなかった

©MIXI 15 15 原因 - 設計に関しての知識不⾜ ● オブジェクト指向やリーダブルコードなどあらかた勉強したつもり ○ 命名はそれなりに意識しているつもり ○ カプセル化もなるべく意識しているつもり ○ if⽂分岐が増えると⾟いからコメントをつけてはいる ○ メソッドが⻑くなったら改⾏したり切り出してはいる

©MIXI 16 16 原因 - 設計に関しての知識不⾜ ● オブジェクト指向やリーダブルコードなどあらかた勉強したつもり ○ 命名はそれなりに意識してはいる ○ if⽂分岐が増えると⾟いからコメントをつけてはいる ○ メソッドが⻑くなったら改⾏したり切り分けてはいる これだけでは全く⾜りていなかった 何がいいコードなのかを知っており、かつそれを実践できないと レガシーコードとは向き合えない

©MIXI 17 17 原因 - 設計に関しての知識不⾜ 良いコードとは？ ● ⼀つのメソッドには⼀つのことを⾏う（責務を持たせすぎない） 1. ● 名前は誤解がないようにする ● ● メンバ変数などスコープの広い変数は気軽に追加しない ● ● 疎結合に保つ

©MIXI 18 18 原因 - 設計に関しての知識不⾜ アンチパターンを踏みまくっていた ● ⼀つのメソッドには⼀つのことを⾏う（責務を持たせすぎない） ○ 既存コードのメソッドに追加したためメソッドが巨⼤になってしまった ● 名前は誤解がないようにする ○ 既存と被らない命名を考えた結果、⻑くてわかりにくい名前をつけてしまった ● メンバ変数などスコープの広い変数は気軽に追加しない ○ 実装の楽さを優先し、メンバ変数を多く追加していた ● コードは疎結合に保つ ○ 事前に他の箇所でデータが⼊っていないとバグるコードを書いてしまった

©MIXI 19 19 原因 - 設計に関しての知識不⾜ アンチパターンを踏みまくっていた ● ⼀つのメソッドには⼀つのことを⾏う（責務を持たせすぎない） ○ 既存コードのメソッドに追加したためメソッドが巨⼤になってしまった ● 名前は誤解がないようにする ○ とんでもなく⻑くてわかりにくい名前をつけてしまった ● メンバ変数は気軽に追加しない ○ 実装の楽さを優先し、メンバ変数を多く追加していた ● コードは疎結合に保つ ○ 事前に他の箇所でデータが⼊っていないとバグるコードを書いてしまった 同じ失敗をしないためには過去から学ぶことが必要 →デザインパターンやオブジェクト指向など、先人が編み出した対応策 は数えきれないほどある 実践できるまで名著を読んで勉強しよう

©MIXI 20 20 まとめ 1. レガシーコード = 触ってはいけないと思い込むのはやめよう 2. レガシーコードと向き合う際にはきちんとコードリーディングをしよう 3. その上で設計を考え、必要に応じて⼀次レビューを依頼しよう 4. 良いコードの書き⽅は過去から学ぼう