はじめに

技術本部 Eight Engineering Unitの山本です。今回はAndroidチームで行っているレガシーコードリーディング会について話します。なお、本記事はSansan Advent Calendar 2024の5日目の記事です。

自分は既に8年近くEightに携わっており、そこそこ古株になります。そのために古くから残っていて最新の設計にできていない古いコードについても知っています。

しかし、新しく入ったメンバーには最近の設計しか説明しないので、古いコードの調査や改修に時間がかかる問題がありました。

新しい設計に書き直すリファクタリングをするのが望ましいとは思いますが、コストが高くすべてをすぐに行うことは難しいです。そのため、古い設計のコードを説明するレガシーコードリーディング会を行うことにしました。

コードの量は多いので1回では終わらないので継続して会を行う必要があります。ここでは会を継続するために意識したことについて書きます。

発表者の準備の負荷を軽減する

一番意識したポイントは”発表者の準備の負荷を軽減すること”です。

このような発表型の勉強会においては、発表者の準備の負荷が大きくなります。準備は業務時間を使っていいと言っても、実際は他のタスクもあり、どうしても優先度は下がります。

その上、コードの説明というのはどこまで説明するかというのが曖昧です。関連コードすべてを説明しようとすればかなり時間がかかってしまいます。

そのため、”発表者が事前の調査にかけていい時間は1時間以内とする”というルールを設けました。それ以上時間をかける必要はありません。

その範囲で調べられたことだけを発表し、質疑応答で話題がなくなれば会は終了します。発表する時間を決めるのでなく、調査する時間のほうを決めたのがポイントです。

機能の分類には以前に作成していたドメインマップを使用しました。これはEightの機能を大雑把に分類した表で、機能の重要性とメンバーの習熟度が書かれています。

ここから説明する機能を決めるのですが、なるべく直近で変更しそうな機能を優先しました。

理由として今回の内容が”古い既存コードの説明”であるのでモチベーションが上がらないという問題があります。この資料を作っても社内の人にしか意味がなく、古いコードなので技術的にも面白みがないです。キャリア的にプラスになる部分がないのです。

そのためすぐに役立つことを優先しました。一方でほぼ変更しない機能についても後半では一通り説明することで、ドメイン知識の偏りを減らすようにしました。

発表時はスライドは作成せずに、Notionのドキュメントを書いてもらうようにしました。

理由として、この情報が必要になるのは今ではなく、この機能の改修や調査をするときであるということです。その際に手掛かりとなるドキュメントを残すのが今回の目的になります。

後から検索、参照することを考えると、スライドは利便性が低いです。そのためスライドは作らずに、Notionのドキュメントを書いてもらう形にしました。

ドキュメントの内容は主に以下になります。

準備期間1時間ではすべてを詳細に調べることは難しいです。しかし重要な手がかりをまとめて、後日の調査をしやすくするという目的からはこれで十分と判断しました。

会は2024年の6月ごろから始まり、ほぼ月に1〜2回のペースで継続されています。主要機能についての説明はおおむね終わったこともあり、もう少しで会は終了する予定です。

Eightの開発では新規開発もありますが、既存コードに変更を加える場合もあります。この会は既存コードの理解に一定の効果があったのではと考えています。

共にSansan / Eightのモバイルアプリ開発していく仲間を募集中です！

選考評価なしで現場のエンジニアのリアルな声が聞けるカジュアル面談もあるので、ご興味ありましたらぜひ面談だけでもお越しいただけたら幸いです！