Rettyの松田です。普段はプロダクトマネージャーとしてSEOに関わっていることが多いですが、今回はエンジニアリング寄りのブログです。
元々Webエンジニアをしていたのである程度はコードを読むことができ、現実的にプロダクトの改善につながるものがあったため、週1時間ぐらいを確保してコードリーディングするのを半年ぐらい続けていました。
一定の区切りがついたのと、実際にいくつか不要なコードを削除することができたので、その取り組みについてまとめてみます。
きっかけ
プロダクトの主要なページについて、現状を把握することが難しくなってきていることが課題として存在していました。
主要なページは数多くの施策が行われている分コードの変化も多く、ユーザーさんに価値を提供し続けられなくなってしまったものも取り残されてしまっていました。
他の施策の実行に合わせてリファクタリングできるレベルであればよかったのですが、腰を据えて慎重に取り組まないといけないぐらいに積み重なってしまっていたので、メインの施策実行とは切り離した体制で改善を少しずつ進めていきました。
実際にやったこと
EMの方と協力して2人で週に1時間を確保して、少しずつコードリーディングを進めていきました。
取り組み始めた段階では、あらためて現状を把握するということを目的にして進めていましたが、読み進めていくうちに削除しても良さそうなコードが明らかになってきました。
そのため、途中からはコードリーディングと並行して、使われなくなったコードを削除するのを行なっていきました。
コードを削除するためにやったこと
何をどこまで消すか判断する
コードが綺麗になるに越したことはないのですが、削除することによってもたらされる影響を考慮して、実際に削除する範囲を決定しました。
今回は、サービスを利用しているユーザーさんに対して何も影響を与えていない、かつプロダクトを改善していくにあたってノイズになっているコードを削除することにしました。
ユーザーさんへの影響がなくエンジニアが読む回数が少なくなりそうなコードについては、削除しても実際のサービスの価値や業務に影響がほとんどないため、そのまま残すことにしました。
本当に消して大丈夫なのかちゃんと確認する
起きていることや当時なぜそのコードが書かれているのかを把握できたとしても、現時点でその前提となった情報が変わっていないのかまで含めて確認するのは意外と大変です。
コードを読んだりIssueを読んだりすることに加えて、実際の画面を見つつエッジケースについてはアクセスログで実際に発生しているのかを確認して、最終的に削除して良いかを判断していきました。
サービスの特性上ページのパターン数が多く、ページ数も1000万以上ありコードだけで追いきるのは難しかったため、データを活用して慎重に確認しました。
継続するために考えていたこと
この手の仕事は、やることはシンプルですが継続するには気合いが必要です。
もともとリファクタリングは苦手ではないですが、それでも大変ではあったので、なんとなく考えていたことを言語化しておきます。
いったん現状あるものとして理解する
誰もが最善を尽くした結果、今のシステムが出来上がっています。
現時点では価値を提供できなくなってしまっていたり最適化の余地があるコードだったとしても、当時はそれでリリースする判断に至っているはずです。
コードに限らず、いったん今あるものを受け取って、次の人に渡すために少しでも良くしていこうという気持ちを持つようにしています。
完璧に理解できない前提で、可能な限り理解する
どうしても情報がなく意図がわからないコードは少なからず存在するものです。
追えるところまではなんとか追って、最終的にわからなければわからないものとして諦めるのも重要だと考えています。
まとめ
プロダクトマネージャーへの転向に伴ってコードを書く仕事をやらないようにしたので、逆に息抜きになるという側面もあり楽しんで続けることができました。
引き続き、これまでの経験を活かしてプロダクト改善につながることはなんでもやっていこうと思います。
