🍣

GEAR.indigo:新機能リバースエンジニアリング

2024/10/04に公開

GEAR.indigoとは?

これは以前記事にまとめているので割愛
https://zenn.dev/mafukuda/articles/c2cb5900111b59

リバースエンジニアリングモード

どんなにモダンなアプリケーションが早く、低コストで作れると言われても、IT部門が普段の業務で関わっている大半は既存システムであろう。
その際、常に問題になるのはドキュメンテーションである。
このドキュメントが1つのテーマであり続けているのは
システムの実態 ≠ ドキュメント
となるからである。

システムは生き物のように多くの変更が行われるため、こうした差分が生まれてくる。
今回のGEAR.indigoの新機能はこの論争に終止符を打とうというものである。

これにより多くのアプリケーションモダナイゼーションの戦略を取ることが可能になる。

実際に利用してみる

今回、新機能のトライアル用に10クレジットが配布されている為、誰でも試してみることが可能になっている。
GEAR.indigoのリンク

・LLMを使っているので正確なドキュメントというよりは概観を把握する目的でご利用ください。
・コードの量が多くなればなるほどクレジット消費が大きくなります。
・LLMで学習されている言語であれば対応できると思いますが手元で試しているのはNext.js、fastAPIのみです。

基本的にはNext.js/supabaseの構成の3層アプリケーションの方がいいだろうなと思いつつ、今回は雑にヘッドレスな店舗情報APIのドキュメンテーションに挑戦してみる

リポジトリを読み込みドキュメント生成

プロジェクトモードでReverse Engineeringモードを選択する

1

新規プロジェクトで名前をつける。そのほかの部分は基本的にデフォルトでOK
2

リポジトリのオーナー名とリポジトリ名を入力して、リポジトリと連携する。
3

ファイル一覧が取得されるので、不要なファイルのチェックを外しドキュメントを生成!
4

5

5分ほどで生成が完了する
6

ドキュメントの確認

ファイル説明

ファイル説明には各ファイルごとの解説が生成される
ちゃんとFastAPIのアプリケーションと理解してくれている
7

もちろん編集して変更が可能
9

システム概要

全体の概要をサマリしてくれる。
もちろん編集して変更が可能。
10

アーキテクチャ

アーキテクチャはmermaidで書いてくれる。今回はヘッドレスAPIのリポジトリなのだが、
フロントエンドも想定して記載してくれている。そしてなかなか正しい...やるな。
もちろん編集して変更が可能。
12

機能要件

ここは創造性を発揮して書いてくれている。フロントエンドを想定しての記載の部分と
さらにエンドポイントにはないレビューなどの機能も記載されていた。気持ちはわかる。
とはいえ、これを0ベースで書くのか、不要なものを削除するだけでいいのかは雲泥の差であろう。
もちろん編集して変更が可能。
13
14

テーブル定義

実際のDBはFirestoreを使っており、スキーマ自体は少し異なっている部分があった。
また存在しないテーブルの記載も生成されたが、よくよく見ているとこの設計の方が良い気持ちになってくる。
リプレイスの検討などでは、リプレイスしつつ新規要件を差し込むこともできそう。
もちろん編集して変更が可能。
15

ER図

定義に則り作成されている。バックエンドをそのままRDBに載せ替えられそうなくらいである。
もちろん編集して変更が可能。
16

画面一覧

これも既存には画面がないのでいじわる問題ではある。しかしこういったドキュメントでユースケースのイメージも湧く。
もちろん編集して変更が可能。
17

バックエンド処理

ここまで画面が存在しないため、少しクリエイティブな生成になっていたが、バックエンドの処理は完璧なドキュメンテーションであった。
実在するエンドポイントのみの処理の記載が正しくされている。あえていうならデータベースがsupabaseと記述されていることくらい(実際はFirestore)
もちろん編集して変更が可能。
18

シーケンス図

こちらは存在しないエンドポイントも含めて生成された。また存在するエンドポイントでも削除シーケンスが追加されているといった部分もあり、この辺りは再度Next.jsのプロジェクトでも試してみたいと感じた。
もちろん編集して変更が可能。
19

まとめ

ピッタリハマるユースケースでもなく雑な検証であったが、それでも十分にパワーを感じることができた。
「引き継いだリポジトリでドキュメントが全くない!」や「急いで作って!と言われてドキュメントを後回しにした本番で動いているこれ」など、すぐにでも役立つケースがある(ん?そんな適当なのは弊社だけなのか...?)

ただ、あくまでまだ始まったばかりなのである。巨大なコードベースが理解できるように、構造や骨子のみを小さいトークンで抽出/解析したり、
コアインプットをユーザーから取得する、アーキテクチャへのチューニングなど、こうしたアプローチがレガシーのリプレイスのリスクやコストを引き下げてくれる日はそう遠くはないと感じる。

・生成AIを用いたモダンでローコストな新規アプリケーション開発
・既存のレガシーをモダンに置き換えるためのリバースエンジニアリング

この2つが揃った時に起こる爆発力はきっと世の中の課題をより迅速により素晴らしく解決できるようになる...はず!

参考

開発者はRinteさん
https://x.com/rinte0321

Rinteさんの記事
https://zenn.dev/rinte/articles/e908d88342e9d0

GitHubで編集を提案

Discussion