可読性の低いコードを生み出してしまった時の反省記録 with レガシーコード

2025/01/16に行われたAndroidエンジニア新年会の5分LT枠にて発表したスライドです。

Transcript

1. @MIXI Androidエンジニア新年会 2025.01.16 可読性の低いコードを生み出してしまった時 の反省記録 with レガシーコード 1
2. ©MIXI 2 2 ⾃⼰紹介 • ばやすてぃー（髙林明⽇美） ◦ X: @bayastea • Androidエンジニア @株式会社MIXI • サロンスタッフ直接予約アプリ「minimo」開発
3. ©MIXI 3 3 minimo について
4. ©MIXI 4 4 ⽬次 1. やらかしに⾄るまで a. 背景 b. いざ実装 c. 何が起きたか？ 2. 原因 a. 負債に対する向き合い⽅がわかっていなかった b. 良い設計⽅法に対しての知識が⾜りていなかった 3. まとめ
5. ©MIXI 5 5 やらかしに⾄るまで - 1 実装内容 • 検索画⾯に特定の条件を満たす掲載者をピックアップして表⽰ ◦ すでに似たような機能あり • 「OOの場合はXXX」といった仕様が多く複雑 開発までの経緯 • 次の施策までのスポット施策として対応 • ちょうどキリがいいので年内までにサクッとやりたい
6. ©MIXI 6 6 やらかしに⾄るまで - 2 プロダクトについて前提 • 10年以上続くサービスのため負債が多い • 検索機能は核となる機能のため、特にコードの量が多く複雑 ⾃分について • プロダクトにジョインして半年未満 • 前職では新規開発を主に対応 ◦ ⻑く保守するプロダクトは少なかった
7. ©MIXI 7 7 いざ実装 などと思いながらなんとか⾃分なりに実装 変に触ってバグったら 怖いな 空気を読んで既存コードに 倣って書いていこう 軽い施策らしいしサクッと 作りたいなあ ただでさえif分岐多いのに さらに増えるのか...
8. ©MIXI 8 8 何が起きたか？ • レビュー時になって可読性の悪さ‧拡張性の低さを⼤量に指摘された ◦ ⾃分ではわかりやすいコードを書いたつもりだったのに... ◦ 可読性が低いことでレビューを難航させてしまった • 条件分岐が増えたことで、レアケースで仕様漏れが発覚 その結果レビュー修正 & バグ修正で⼿戻りが増えてしまった
9. ©MIXI 9 9 原因 負債に対する向き合い⽅がわかっていなかった & 良い設計⽅法に対しての知識が⾜りていなかった
10. ©MIXI 10 10 原因 負債に対する向き合い⽅がわかっていなかった & 良い設計⽅法に対しての知識が⾜りていなかった
11. ©MIXI 11 11 原因 - 負債に対する向き合い⽅ BAD • 早く実装したいから⼤⽅雰囲気を掴めたら実装に⼊る • レガシーコード = 開けてはいけないパンドラの箱だと思っている • なるべく既存コードは触らず、前例に倣って実装する
12. ©MIXI 12 12 原因 - 負債に対する向き合い⽅ 既存コードに追加するだけだとどこかで限界が来る 例） • 当初予定していなかった変更が追加されることで 条件⽂がどんどん⻑くなる ◦ 既存の if ⽂に今回追加した「特定基準の掲載者」を追加してごちゃごちゃに ◦ もし今後「星5掲載者」のような区分が追加されたら...？ • 変数名と中⾝が⼀致しない
13. ©MIXI 13 13 原因 - 負債に対する向き合い⽅ 既存コードに追加するだけだとどこかで限界が来る 例） • 当初予定していなかった変更が追加されることで 条件⽂がどんどん⻑くなる ◦ 既存の if ⽂に今回追加した「特定掲載者」を追加してごちゃごちゃに ◦ もし今後「星5掲載者」のような区分が追加されたら...？ • 変数名と中⾝が⼀致しない レガシーコード = 触ってはいけないと思い込むのはやめよう 既存コードを雰囲気だけで理解するのはやめよう ⾃分なりの設計を考えて⼀次レビューやペアプロを依頼しよう
14. ©MIXI 14 14 原因 負債に対する向き合い⽅がわかっていなかった & 良い設計⽅法に対しての知識が⾜りていなかった
15. ©MIXI 15 15 原因 - 設計に関しての知識不⾜ • オブジェクト指向やリーダブルコードなどあらかた勉強したつもり ◦ 命名はそれなりに意識しているつもり ◦ カプセル化もなるべく意識しているつもり ◦ if⽂分岐が増えると⾟いからコメントをつけてはいる ◦ メソッドが⻑くなったら改⾏したり切り出してはいる
16. ©MIXI 16 16 原因 - 設計に関しての知識不⾜ • オブジェクト指向やリーダブルコードなどあらかた勉強したつもり ◦ 命名はそれなりに意識してはいる ◦ if⽂分岐が増えると⾟いからコメントをつけてはいる ◦ メソッドが⻑くなったら改⾏したり切り分けてはいる これだけでは全く⾜りていなかった 何がいいコードなのかを知っており、かつそれを実践できないと レガシーコードとは向き合えない
17. ©MIXI 17 17 原因 - 設計に関しての知識不⾜ 良いコードとは？ • ⼀つのメソッドには⼀つのことを⾏う（責務を持たせすぎない） 1. • 名前は誤解がないようにする • • メンバ変数などスコープの広い変数は気軽に追加しない • • 疎結合に保つ
18. ©MIXI 18 18 原因 - 設計に関しての知識不⾜ アンチパターンを踏みまくっていた • ⼀つのメソッドには⼀つのことを⾏う（責務を持たせすぎない） ◦ 既存コードのメソッドに追加したためメソッドが巨⼤になってしまった • 名前は誤解がないようにする ◦ 既存と被らない命名を考えた結果、⻑くてわかりにくい名前をつけてしまった • メンバ変数などスコープの広い変数は気軽に追加しない ◦ 実装の楽さを優先し、メンバ変数を多く追加していた • コードは疎結合に保つ ◦ 事前に他の箇所でデータが⼊っていないとバグるコードを書いてしまった
19. ©MIXI 19 19 原因 - 設計に関しての知識不⾜ アンチパターンを踏みまくっていた • ⼀つのメソッドには⼀つのことを⾏う（責務を持たせすぎない） ◦ 既存コードのメソッドに追加したためメソッドが巨⼤になってしまった • 名前は誤解がないようにする ◦ とんでもなく⻑くてわかりにくい名前をつけてしまった • メンバ変数は気軽に追加しない ◦ 実装の楽さを優先し、メンバ変数を多く追加していた • コードは疎結合に保つ ◦ 事前に他の箇所でデータが⼊っていないとバグるコードを書いてしまった 同じ失敗をしないためには過去から学ぶことが必要 →デザインパターンやオブジェクト指向など、先人が編み出した対応策 は数えきれないほどある 実践できるまで名著を読んで勉強しよう
20. ©MIXI 20 20 まとめ 1. レガシーコード = 触ってはいけないと思い込むのはやめよう 2. レガシーコードと向き合う際にはきちんとコードリーディングをしよう 3. その上で設計を考え、必要に応じて⼀次レビューを依頼しよう 4. 良いコードの書き⽅は過去から学ぼう