こんにちは。食べログでAndroidアプリ開発をしている @sada と申します。
この記事は 食べログ Advent Calendar 2021 22日目の記事です。
はじめに
先月、TECH HILLS #1 というイベントで登壇させていただきました。
その時の資料はこちらです。
今回は上記資料でも触れている「レガシーコードと向き合う辛さ」についてお話できればと思います。
イベントにご参加いただけた方は発表やその後のパネルディスカッションなどでお話ししたような内容も含まれるかと思います。その点はご了承ください。
簡単にチーム紹介
私は食べログシステム本部アプリ開発部基盤チームに所属しています。
アプリ基盤チームはリファクタリングや環境改善を専門にしたチームで、以下のような業務を行っています。
- OSバージョンアップ対応
- ライブラリ、ツールの継続的なバージョンアップ・差し替え
- アーキテクチャの選定・差し替え
- リファクタリング
- CI/CDの改善
その中でAndroidアプリに関しては、たまってしまった技術的負債を返済するべく、リアーキテクチャプロジェクトを進めております。
このプロジェクトで行うことは以下の３点です。
- アーキテクチャの刷新
- ソースコードのKotlin化
- Deprecatedとなったライブラリの除去
今回はこのリアーキテクチャプロジェクトの内容についてお話しできればと思います。
それではさっそく本題に移ります。
レガシーとは
書籍「レガシーソフトウェア改善ガイド」ではレガシープロジェクトの性質を次のように述べています。1
- レガシーソフトウェアは大きく、古く、他の誰かから受け継いだもので、碌なドキュメントがない
- テストされていない／テストできないコード
- 柔軟性のないコード
- 技術的負債を抱え込んでいるコード
- コードだけでなく基盤（インフラストラクチャ）も問題を抱えている
- カルチャーが改善を妨害することもある
資料でも簡単に紹介していますが、食べログAndroidアプリは上記にかなり該当してしまっていました、、、
実際に具体的にはどんな負債だったのか聞きたい方は、カジュアル面談などでお話しさせていただきます（笑）
レガシーと向き合う辛さ
レガシーソフトウェアで開発を継続することの辛さは書籍「レガシーソフトウェア改善ガイド」の中でも「恐れとフラストレーション」という形で説明されています。2
今、私たちが推進しているリアーキテクチャでは、各画面ごとにしっかりと仕様調査や既存コードの現状を確認した上で、どのような形で設計し直すか検討した上で、ミニリライトするアプローチ（既存の一部を作り直す手法）をとっています。
そのため、レガシーコードに対しても恐れずに向き合い、実際どう動いているのかを紐解いた上で、どこまで作り直す（リライトする）のか、どこまではそのまま利用しないと他の画面に影響がでるのかなど詳細に調べる必要があります。
また、調査をする際にもレガシーコードとずっと向き合い続けるため、フラストレーションが溜まり、モチベーションが失われていくこともあります。
実際にチーム内のふりかえりでも、辛みなどのネガティブなコメントを見受けられる時が多々ありました。
とはいえ、これらを乗り越えてゆき、負債を返済していかないと、日々の開発が辛いものになっていくばかりです。
レガシーとの向き合い方
レガシーと向き合うための色々な手法は、以下の書籍で紹介されていますので、読まれたことのない方は是非一度読むことをお勧めします。
ここからは書籍に書かれているような内容だけでなく、実際に食べログアプリで発生した悩みポイントやメンタル的なお話したいと思います。
辛み１：仕様がよくわからん問題
実際のコードがどのように動いていて、どう動くのが正しいのかが、コードを読むだけでは判断できないケースがあります。
もちろんすでに動いているコードなので、大きな問題にはなっていないケースが殆どなのですが、調べていくと、「本当は〇〇とすべきだったものが、現状□□のようになっている」というケースも稀にあります。
そのコードもかなり昔に作られたもので、もはやその時の当事者もいないケースもあります。
解決方法
ただでさえ読むのが辛いコードでこんなことがあるとさらに辛いことになりますね。
ここは素直に応援を頼みましょう。
資料でも紹介していますが、食べログアプリ開発部はチーム体制を大きく２種類に分けています。
私の所属している基盤チームと、サービス開発チームです。
仕様の不明点はサービス開発側のチームに適宜質問・相談をして進めることで解決しています。
また、OS間での仕様差分がないものはiOS側を確認することも行なっています。
こうすることでOS間で差異のあったドメイン知識の差分という負債をなくしていくことも重要だからです。
辛み２：個々のモチベーション
正直、こんな辛みのあるコードの調査等を進めていると、かなりネガティブな精神状態になってしまうこともあるかと思います。
ふりかえりの場では以下のような付箋が挙げられていて、かなりフラストレーションが溜まっているのが伺えます。
※画像の中の「基本情報タブ」や「写真詳細」と書いてあるのはアプリ内のある画面を指しています
解決方法
ネガティブな思考を少しでも解消するために、チーム内で勉強会を定期的に開催しています。
単純にスキルアップなどの目的もありますが、それ以外にも新しい技術のキャッチアップを行うことで、レガシーコード（過去）と向き合うだけでなく、新しい技術を導入した姿（未来）をイメージできるようにする目的もあります。
新しい技術を知ると、今認識していた技術的負債がより大きいものになってしまうこともあるかもしれませんが、その技術を導入できるとこういった世界観（メリット）が待っているという具体的なイメージができるようになります。
また、私は技術的負債とは理想と現状のギャップのことだと思っていて、そのギャップを認識できたということはそれだけ学びがあったり、スキルアップができたということに他ならないと思っています。
ですので、負債を認識できること自体をポジティブなものと捉えられるようになると、モチベーションの向上につながると考えています。
そういった「学び」というものをより意識することを習慣づけるために、ふりかえりの手法もKPTAからFun/Done/Learnという手法に変更しました。
その甲斐あってか、徐々に学びというものを意識する傾向は出て来ています。
辛み３：課題が重い
レガシーコードの改善を進めていて課題にぶつかると、大抵解決が難しいもののことが多い気がします。
さらにその課題に1人でアプローチしていると、なかなか解決できず、煮詰まってしまい進捗も悪くなっていくという悪循環になってしまいます。
その結果、先述したモチベーションが低下を引き起こす恐れがあります。
解決方法
課題にぶつかった時は１人で悩まず、みんなで解決しましょう。
こういった時はモブワークが有効です。
モブワークをすることで、課題解決や意思決定のスピードもあがるし、知見の共有もできます。
※去年のAdventCalendarではモブプロに関する記事を書きましたので、参考にどうぞ。
また、モブワーク以外にも定期的にコミュニケーションの取れる場を用意するのも効果的です。
特にリモートワークの環境下だと、コミュニケーションが希薄になり、孤立してしまいがちになるため、雑談でもいいので日頃からコミュニケーションを取れる場があると、いざと言うときに助けを呼びやすくなるし、自分の意見も言いやすくなると思います。
基盤チームではこれまで以下のようなことを実施して、コミュニケーションの活性化に取り組みました。
- 毎日の朝会/夕会
- 朝会は雑談タイム、夕会は進捗確認といった感じ
- 週次ふりかえり
- 先述したFun/Done/Learnを用いたふりかえり
- Learning Session
- 設計スキルや新技術に関する勉強会
- 関係性を深めるワーク
- ドラッカー風エクササイズ（B面3も）
- wevox values card
上記のような取り組みの成果もあり、現在では気軽にモブプロを実施したり、率直な意見を出し合うことができるようになってきたと感じます。
まとめ
いかがでしたでしょうか？
技術的負債やレガシーコードの話は色々な書籍やブログなどで紹介されていたりしますが、今回は実際に進めてみて悩んだポイントやメンタル面のお話をさせていただきました。
実際これだけ大きなことを行うには1人では難しく、チームで解決していくことが重要になります。
そのため、私はチーム力や個々のモチベーションの高さが何よりも大切だと考えています。
最初は私も１人で歩み出したリアーキテクチャプロジェクトですが、今では５人のメンバーで一致団結して取り組んでいます。
まだまだ道半ばではありますが、これからもリアーキテクチャプロジェクトを推進していきたいと思います。
また、もしこの大きな課題に一緒に取り組んでみたいと思っていただけた方や、ご興味を持っていただけた方はぜひお気軽にお声がけください。
カジュアル面談も大歓迎ですので、ご希望の方はフリーテキストに、「カジュアル面談希望」と記載ください。
最後に
明日の記事は @ogino さんによる「アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~」です。
どうぞご期待ください！！！