ComicFestaのレガシーコード改善の現状
では、naminami.fm始めていきます。よろしくお願いします。
うっちー
よろしくお願いします。
swat
今日は、Waveで運営しているComicFestaっていうサービスの、今15年ぐらい、輸出してから15年ぐらい経っていて、
結構、レガシーなコードとかが溜まってきていて、そこを改善していくっていうのをAIを使いながらやるっていうのを今やっているというか、やろうとしているというか、
そうなっていて、そこのお話をしようかなと思っています。
うっちー
お願いします。
swat
コミックフェスタですね。6年前ぐらいに、自分が外部で登壇したシステムリニューアルをやってみたっていうやつがあって、
そこから6年、リリースしてからだと15年経っていって、一回リニューアルみたいなことをしたんですけど、
そこから6年経って、またコードが複雑になってきたり、あとメンバーが入れ替わって暗黙値みたいなのが抜けていったりっていうのがあって、
今結構コードを把握しきれてないみたいなところがあって、そこにどう立ち向かっていくかっていうのを今やってたりします。
うっちー
システムリニューアルがちょうど7年、6年、7年前ですよね。
swat
そうです。
うっちー
そこからまた7年、6年、6年、7年経ってシステムリニューアルして、また6年、7年そこから経ったっていう状況ですね。
AI活用に向けた課題と環境整備
swat
今、もっかい動いているのは、コミックフェスタの中の決済の機能、クレジットカードとかキャリアの決済とかをモジュラーモノリストして切り出すっていうところは、
プロジェクトとしてはもう動いていて、今やってますと。
あとフロントエンドも新しくしようっていうのがあって、システムリニューアルしたとき、7年前とかにビューを一部導入してて、
そこから月日が流れ、フロントエンドをリアクトにしようっていうのがあって、
そこは一部はできてるんですけど、まだ移行しきれてないっていうような状態ですね。
レール自体はモノリスでメインの機能があるっていう感じ。
今の課題感として、15年ぐらい経った中でコードベースが結構大きくなってきて、複雑になってきてっていうのがあって、
新しいメンバーがなかなか全容を把握するのに時間がかかるとか、既存のメンバーでも見落としてしまう影響範囲があったりとかして、
なかなか機能追加をどのしていくっていうのができなくなってきたっていうのがありました。
AIが出てきたので、そこも結構解決できちゃうのかなっていう期待感はあったんですけど、
今のAIの機能だとそこまで手放しで任せて解決っていう感じはないっていうのが見えてきて、
AIが書いたコードを検査するための自動テストというか、勝手に影響範囲が見づらい中でどんどんコードを変えていって、
基地の機能に不具合がないかみたいなリグレッションみたいなところが自動テストが整っているとか、
AIに渡すためのドキュメント仕様が揃っている。
どんどん変更していく中で、不具合があったらすぐ復旧できるようなログの監視とかシステムのアラートとか、
そういうところの監視体制だったりとかっていうところが今十分ではない。
それがないとなかなかAIでどんどん作業を進めていくっていうのができないなっていうのが見えてきて、
そこを何とかしたいなというのを今思っているという感じですね。
AI実装のためのガードレール構築
うっちー
AIに単純に書き方というか、コンテキスト、プロンプトを改善してどうにかなるという問題よりも、
周りの環境、ちゃんとガードレール的にAIを実装させるためのガードレールがないと厳しいねっていうのが分かってきたって感じなんですね。
swat
そうですね。
多分人の手でやるにしても、何か変更、機能1個変更して、それの関連機能全部何となくの自動テストと、
あと手動のシナリオテストとみたいなのをやっていくと、どんどんその影響範囲が広がっていくので。
そこを何かしらガードレールとか何かあってもすぐ普及できるっていうのは体制を整えないと、
多分デカくなってコードベースに対応できなくはなっていくんだろうなっていうところがAIでより分かるようになってきたという感じですね。
うっちー
人の入れ替わりがあるとより顕著に分かりますもんね、そういうのが。
そうですね。あの人に依存してたなんて。
swat
そうですね。なので、人だけに依存しすぎない、システムで叶えるところ、支えられるようなガードレール作れるようなところは、
そこをシステムを作っていこうっていうのを今やりたいなってところで、
今目標としては、コミックフェイサーのメインのコアドメインの機能としては、
本が買えるとか読める、あとサブスクリプションの決済機能であるとか、
あと広告から入ってきてくれるユーザーが多いので、その広告から入会までっていう導線もあり、
読書体験みたいなところのUXっていうところ、
この辺りを変更に強くしたりとかどんどん変更できるような体制にしていきたいんですけど、
その中でも決済であったりとか、広告とかも結構いろんな導線を作ってぐちゃぐちゃになったりとかいうのもあったりするので、
その辺りの影響範囲が分かりやすくする、もしくは分かんないとしても自動テストで見つかる、
本番でエラー検知で素早く復旧できるっていうような状態にしていきたいなっていうのを今目標として考えてます。
なので全部すっきりさせるっていうわけではなくて、メインとなるところ、重要なところっていうのをコントロールできるような状態にしていきたいなっていうのが考えているところですね。
うっちー
メインの場所であれば一番変更の頻度が高いですもんね。
そこがコントロールできるようになってくると全体的にコスパよくやれそうですね。
コーディングルールの文書化とAI活用
swat
今やろうとしているのが、チームではカーソルをメインでチーム使っていて、他のチームだと違うツールを使ってたりするんですけど、
NICフェスタチームはカーソルを使っていて、そこのagent.mdとかルール図ですね、そこにコーディングルールを止めていくっていうのを
今はやってたりしますね。前はそこも結構俗人的になっていったところなので、
ここをドキュメントに起こしていくというか適当にしていく。
それがさらにAIに渡されるようになると、そこに書いたものがすぐ日頃の開発で効いてくるので、
より整えていくインセンティブがあるというか、コーディングルールを整える意味が出てくるので、
このルールのところにコーディングルールを止めてっていうのを今やってます。
うっちー
コーディングルール自体は元々あったやつを文章化してるんですか?
それともここで定義、一から定義してるんですか?
swat
そこもありますね、なんかドキュメントとか自動テストとかはあるはあるんですけど、
どうしても整理が漏れてしまうというか、急ぎの対応したらドキュメントが更新されなくて陳腐化するみたいなのがよくあると思うんですけど、
ウークベストもそんな感じになっていて、コーディングルールが頭の中には足りなかったりみたいな感じですね。
swat
明確にこれが今、このコーディングルール見てやってくださいみたいなものが新版があるってわけではない。
うっちー
そこの頭の中のものをアウトプットするところも必要になってきたってことですね。
swat
そうですね。一応なんかベースのコーディングルールとかは既存のコードをAIに見てもらって、
Railsのベストプラクティスとか標準的な書き方とはまた違う特殊な書き方しているものがあれば、
そこをピックアップしてこのウークベストならではのコーディングルールであるっていうところで文書化してもらうっていうのでバーッと作りました。
ちょっと中はちゃんとは精査してなくて、実装していく中で変なコード出してきたら都度修正するっていう形で、
いったんルールをすべて作りました。それでたぶん新しく作るコードはある程度そのルールにのっとったものになっていくはずなので、
あとは既存のコードをリファクタリングしていく、コントロールできるようにしていくっていうので、
コードベースの可視化とリファクタリング優先度付け
swat
今やってるのがコードベースの付載を定量化するツールを作っていて、ここはデッドコードの計測ですね。
デッドコードはカバーバンドっていうやつがあって、実際に本場で動かしているコードで呼び出されたかどうかっていうのを計測するやつがあって、
それで呼び出されてないっていうやつですね。を集めて、かつそれがすごく倍の変更のもの。
変更してから半年とか経ってるのにもう1回も呼ばれてないみたいなやつはたぶんスクエースにいらないやつなので、
それを見えるようにしてっていうのを今しています。
うっちー
このカバーバンドっていうのはどこに出力されるんですか?本番で動いてるというか、動いてない、呼ばれなかったっていうのは、ログとかに出るんですか?
swat
レディースに書き溜めてる形がすごいですね。呼ばれたやつだけどんどん追加されて、
中の実際のデータ見てないんですけど、呼ばれた行ぐらいまで出るようになってるので、
たぶんどの行まで呼ばれたみたいなデータが蓄積されていて、それと実際のコードベースを突合して呼ばれてないやつが見えるみたいな感じですね。
あと、RubyCriticってやつで、コードの複雑さみたいなのを可視化しています。
うっちー
静的解析ですかね?
swat
そうですね。そっちは静的に複雑さを見ていて、ifの深さとかオード行数とか何個かスコアがあるみたいなんですけど、それで複雑さを見ていて、
複雑さと変更能差ですね。そのファイルのコミットログが何個あるか。
で、さらにそのファイルのコードカバレッジがどれくらいあるか。
で、それを組み合わせてリファクターの優先度を可視化するっていうのを今作ってますね。
うっちー
確かに変更能差とかあると今後も変更を今まで多かったんであれば。
swat
そうですね。コードが複雑で変更もって、コードのカバレッジも低い、ゲストケースのカバレッジも低いってやつは、
最優先でリファクタリングなりした方が多分メンバーにとって嬉しくなるはずなので、っていう仮説でちょっと作ってみました。
ちょっと運用しだしたらまた違う資料で見るかもしれないけど、今そういうのを定量的に見れるやつを作ってみてます。
で、そこらへんの定量化するツールを元でに、コアな機能、多分一番複雑で、
だけどみんなが使っている機能みたいなところにあたりをつけて、テストケースを作っていく。
あと仕様をリバースエンジニアリングして、隠れた機能がないのかというか仕様がないのかって呼び起こして、
そこからテストケース作って、テストができたら中をリファクタリングしていってっていう流れをやっていこうかなっていうのかな。
AIによるリバースエンジニアリングとテストケース生成
うっちー
リバースエンジニアはどうやってやるんですか?
swat
これはちょっとあんま考えてないんですけど、一回AIにこの機能、このファイル、このクラスの機能をストーリーベースで抽出してっていうのを頼んで作ってみるのはやろうかなと思って。
このあたりの流れがうまくいけば、仕様をリバースエンジニアリングして、テストケース作って、リファクタリングしていくっていう流れがAIで実装できるようになったら、
あとはそれを並列にしてやれば、ボツッと回していけば、ある程度綺麗なものができていくのかなっていうのを今目論んでいるという感じですね。
うっちー
この並列にして動かすのはコードラビット的にサーバーで動くんですか?
swat
サーバーのやつも、うちがGitLabをセルフホストして使っているんですけど、そのあたりで設定がちょっとめんどくささがあって、
GitHubとかだとGitHub Actionsでクロードコードアクションとか、Davinとか、ここら辺がすぐ連携できるんですけど、っていうのがあって、
サーバー上で動かすのは今考えてなくて、自分の環境上でクロードコードを今使っているので、それをヒットレスモードで動かしておく。
夜中中午下しておくみたいなイメージです。
うっちー
並列でやるときはどうなるんですか?Gitのブランチがどうなんだろうと思って。
swat
ソースでそこもやってみてですけど、入るごとでブランチ切ってやるか、機能単位ぐらいですかね。
ブランチ1個だけ切ってそこでもうガーッとやっちゃってもいいんですけど、多分レビューがめちゃくちゃ大変な気はしているので。
うっちー
レビューは自分で、人でやるって感じなんですか?
swat
人でやろうかなと思ってますね。最初の何個かやって、結構任せられるね。
不具合あっても監視で発見してすぐ復旧すればいいねってぐらいの品質であればガーッと任せちゃうっていうのはできたらと思うんですけど、
多分最初の方とかはレビューを入れながら品質チェックしてっていう感じになるかなと思うので、そこのやりやすい要領でブランチ切ってやれたらなと思います。
うっちー
並列で動かせるとかなり早く進みそうですけど、そこの人がレビューするとか見たところがあると、そこが今度はポトラネックになっちゃうかもしれない。
swat
しょうがないんですよね。
うっちー
ルール、コーディングルールとかがまとまってくると、手元の開発者が使ってるカーソルとかの精度とかも良くなってくると思うんで、そこだけでもOKはありそうですもんね。
swat
そうですね。このAIの自動化までいかなくても、その途中の整えてたところが多分開発環境を良くしてくれてっていうサイクルになって、ダニアンならないかなと思ってます。
うっちー
はい。この6年、7年経って、やっぱり一回リニューアルしただけじゃまた悪くなっていくというか、良くない方向になっていっちゃうんで、またリニューアルなり、今の引き続きじゃなくて何かを変えるっていうのがまた必要になってくるけど、
そこも模索しながらどういうふうにリニューアルしていこうかっていうのを考えてやってますというとこですね。
継続的な改善と今後の展望
swat
そうですね。じゃあ今日はこんなとこですか。
終わりにします。お疲れ様です。
うっちー
ありがとうございました。
swat
ありがとうございました。
