新しいプロジェクトの開始
はい、こんにちは、リドルです。
はい、こんにちは、ひびのです。
今日のお題は、新しいプロジェクトのコードベース、どう読めばいいのか。
イェーイ!
新しいプロジェクトのコードベース、どう読みますか?
そうですね。いや、これ大変なんですよね。
最初に入ったプロジェクトの大きさにもよりますけど、まあ、よくわかんないですよね。
なんでこれ出てきたかというと、その若手のエンジニアの方が、しかも今まで経験なかった方が
初っ端入ったところで、何から読めばいいのか全然わからんっていう相談をもらいました。
まあ、それに何か回答したいなという感じですね。
うん。リドルさんは結論、どこから読みますか?
ちょっと、もうAIの時代なので、だいぶAIになっていいんじゃないかと思っていて、
パブリックなリポジトリだったら、ディープウィキみたいなものもあるので、
ディープウィキで作ってもらって、そいつと会話してやるっていうのはありますよね。
ディープウィキの説明をしておくと、
Github.com、ほげほげみたいな感じのリポジトリがあると思うんですけど、
あれのGithubの部分をディープウィキって名前に変えてあげると、
そのリポジトリのコードをベースにしたラグが作られて、
一定時間待つとサイトが出来上がります。
で、そのサイトにはそのリポジトリのまとめた内容が載っていて、
かつその入力ボックスみたいなものもあるので、
そこに教えたいことを入れてあげると、
そのリポジトリの内容に即した回答が返ってくるっていう。
Devin作ってる会社が何か作ってましたね。
Devinと同じ会社なんですね。
そうなんですよ。
DevinにもDevinWikiっていう機能があって、
それを使えばパブリックだけじゃなく、
プライベートな自分のプロジェクトもWikiを作っていくんですよね。
そうなんですね。それ知らなかったな。
DeepWikiは依頼すると裏でDevinが動いてくれるっぽくて、
だから動き終わったらメールが飛んでくるみたいな感じの設定を最初にするんですけど、
メールアドレスだけ登録して。
それによって分かるって感じなので、
パブリックのリポジトリだったらその方法が一番今は簡単だと思います。
確かに。
プライベートだとDevinの話があったので、
Devinがあればそれを使えば良いと。
DevinWikiも使えそうですね。
あと最近話題なのは、
クロードコードにリポジトリ全体を読み込ませて、
チャットで形式で質問する。
それが早いんでしょうね。
っていうのがAI時代のリポジトリ読む方法なんですけど、
ちょっとさすがに新しすぎるので、
今回はAIに頼らずに頑張って読む方法について考えていきたいと思います。
楽しみです。
初めに何見ます?
そうだな。
ちなみにサーバー側の前提で。
そうですね。
変わるのであればそれぞれ別にしましょうか。
フロントとサーバーとインフラも入れましょうか。
3種類ですね。
まずフロントからにしましょう。
フロント、WebFrontEnd、アプリ。
WebFrontEndの前提で話すと、
そうですね。
それこそサーバーもですけど、
WebFrontEndにおいても今よく使われるアーキテクチャ的なものがあると思っています。
そうだな。
僕がよく見るプロジェクトの構成だと、
Next.jsライクに最初のページ全体にあたるコンポーネントの単位があって、
そこからある程度独立したコンポーネントとして動く単位のものを呼び出していて、
あとはUI部。
本当に細かいUI部。
文字だったりボタンだったりテキストボックスだったりみたいなもの。
まずUIのレイヤー構造があって、
あとそれから外回とやり取りするようなコードが共通で呼び出せるようなアクションとして定義されているみたいなケースが多いのかなと思っています。
なのでそれにがっつりと当てはまっていれば、わりと読みやすい気がする。
それに当てはまっていなかったらちょっと困るな。
それは触りながら覚えるかなと思いますね。
バックエンドのアプローチ
先にサービスを触ったりとか、サービスの仕様を調べたりとかはしないですか?
それでいうとやりたい。
確かに一番最初にプロジェクトに入った時はまず、
それこそ僕がMixiで最初に入った部署が美容室を予約するっていうアプリのプロジェクトだったんですけど、
ミニモですね。
ミニモでは一番最初のオンボーディングの中に美容師のアカウントを作って、
それを実際に美容師としてミニモの中で認められるように審査を通して、
美容のメニューを作って、その後にお客さんのアカウントを作ってそこに予約するまでを。
本当にサービスの一連のフローを体験するっていうのが最初のオンボーディングであって、
それはかなり全体を把握する上で大事で。
それめっちゃいいですね。
その通りミニモの大事なところを学べるし、
その裏側どうなってるんだろうって気になったらミンクっていう次のアクションが見やすいので、
それいいな。それなんか次の現場でもやりたい。
次の現場のオンボーディング項目に組み込んであげる。
そこからフロントエンドを見るって感じですかね。
そうですね。確かにそう言われると一番最初にサービスの中でユーザーが触るフローがあると思う。
そのフローに沿って触ってから中の行動魅力が多いですかね。
その時例えばブラウザの開発者メニューとか開いて、
このAPI叩いてるんだなとか見た上で、
Next.jsのAPIのエンドポイントとかルーティングファイル見たりします?
それで言うと自分は最初サービス触るときは見ないことが多いかな。
そのいわゆる通信。どういう通信が行われているかとか。
ただ今思ったのは多分見た方がいいかなと思いました。
ちなみにリドルさんは一番最初新しいプロジェクトに入った時は最初にコードから見ます?それともサービスから触ります?
サービスから触るのと、触りつつ使用書みたいなやつを見ますね。
物によるとは思うんですけど、全然自分が知らない概念のサービスだった時って、
その仕様だったりとか業界知識をつけるところを先にやらないと、
アプリ触ってもよくわからないみたいな感じになると思っていて。
直感的にわかるものだったらいいんですけど、そうじゃない2D向けのものもあったりするので、
そしたらまずこれは何なのかとか、仕様は何なのかみたいなものを入れながら何とか触って、
こんな動きなのかなとか、こう動かないといけないんだろうなみたいなところの勘どころを何となく頭に入れて、
その後、実際に戦われているAPIがどういう順番で戦われているか見て、
その裏側を考えるみたいなことをします。
確かに、それこそビーム向けのサービスだと、
本当にプロジェクトにジョインするまで触れないプロジェクトも多いですね。
ジョインしたところで触れないものとかいっぱいありますからね。
そうですか。
例えばフロントがなくてただバッジサーバーが動いてますみたいなやつ。
何のバッジだよみたいな。
確かに、コアの処理がバッジ処理で動いている類いのサービスは、
本当に全体像のイメージがまずつきづらいですね。
ブロックチェーンのスマートコンテナソフトとかね、無理ですよ。
ああ、わかるな。
それでいうと、リドルさんはメインがサーバーのエンダーじゃないですか。
フロントから見ますか、それともサーバーから見ますか?
フロストのコードをいじる必要がないんだったらフロント見ないので、
バックエンドとか、あとインフラの構成から見ますね。
インフラの構成、それこそテラフォームのプロジェクト?
テラフォームを見ることはほぼなくて、どちらかというと、
システムのアーキテクチャーズみたいなものがプロジェクトにはあるはずなので、
それを見て、そもそも何のクラウドを使っているのかとか、
そのクラウドでどうやってサービスを動かしているのか。
例えばAWSだったらECS使っているのか、EC2なのか、EKSなのか、
もしくはラムダでやっているのか。
データベースはRDSなのか、ダイナモなのか、またまた別のとか。
外部サービスは何を使っていて、メールはこれでとか、
通知通知はこれで、みたいなことを一通り頭に入れてから、
ざっくりアプリが3種類ぐらいあって、
それぞれこういう感じで管理しているんだな、
みたいなオーバービューみたいなものを頭に入れてから、
割とコードを見ることの方が多いですね。
なるほど、インフラエンジニアっぽい発想です。
最終的にどこで動いているのかっていうことが大事になってきたりとか、
ここでこういうことをしているのは、
このAとBのサービスが別のところにあるから、
いざGRPCで接続するためにこういうことをしているんだな、みたいな。
メタ情報が先にあった方が後で読みやすいみたいなのが、
なんとなく自分の勘どころとしてあるので、
そういう方式になっているかもしれないです。
なるほど。
清水野さん、バックエンド側を見るときどうするんですか。
バックエンド側を見るとき、大体プロジェクトに入って、
やっぱりフロントエンドとバックエンドどっちも見ることが多い。
それでいうと、APIのエントリーポイントから見ることが多い。
それはバックエンドのオープンAPIとかで定義されたやつから、
生産されたハンドラーみたいなところですかね。
ああ、です。
それかオープンAPIの、例えばAPI一覧を一通り眺めると、
なんとなくフロントエンドからサーバーにリクエストする。
こういう手順でリクエストすればこういうことできそうなら、
想像つくじゃないですか。
あとはそこまで見たら、なんだろう、やりたいことによって、
ハンドラーを見たり、ドメインインストを見たり。
そうですね。
大体一番上から攻めるか一番下から攻めるかが多いですね。
APIから見るかDBから見るか。
ああ、テーブル設計から見るかってことですか。
です。
でも確かに、自分もMITENEのサービスに関わった時は、
MITENEのテーブルが結構巨大だったりとか、
画像をそもそもどうやって扱ってるんだろうみたいなところを気にして、
MITENEのモノレポ
データベースのスキーマとか見ましたね。
MITENEの場合は、モノレポで管理してて、
すごい数のAPIエンドポイントがあって、
複数チームで開発されてるので、
よくわかんないですよね、どれが自分のチームのやつなのか。
モノレポっていうのは、
ちなみに多分MITENEって
Kubernetesを使ってマイクロサービスを運用してるんですよね。
そのすべてのサーバー側のサービスがモノレポなのか、
それともフロントエンドとか含めてモノレポ。
MITENEは基本的にRAILSで開発されていて、
MITENEの基本的なAPIは全部RAILSの上で動いているので、
まずシングルのPODですべておまかなっていますし、
基本的にMPAが多いので、
それも同じところで管理されてますし、
同じPOD上で動いてますね。
ある程度ページごとにRAILSのコントローラーに付随して、
フロントエンドの情報も含まれている。
そうですね。
こんなに巨大なサービスだと、
最初ギョッとしませんでしたか?
ギョッとしましたよ。だから全然わからないです。
全然わかんないから、読むのを逆に諦めて、
必要な作業が発生したときに一緒なところだけ読むっていう、
あんまり理解することを諦めましたね。
でも確かに僕もそれはわかる気がしていて、
最初に気合い入れて全体像を把握しようとしても、
結局全体像を把握しきれなかったり、
いざ触るときに覚えていないことが多く、
本当にある程度全体像をつかんだら、
あとは触って覚えるが、
一番よく結局そうなってしまう。
そうですよね。
それで徐々に詳しくなっていくみたいな感じなので、
話し方は若干それますけど、
最適なコードのサイズというか、
マイクロサービスみたいなところがやっぱりチームで、
理解をある程度できる範囲にとどめるには必要そうな概念ですよね。
確かに。マイクロサービスか。
それでいうと、僕これまでマイクロサービスライクに、
サーバー側を実装しているプロジェクトって、
まだジョインしたことがないかもしれないです。
弊社だと全然ないですね。
そうですね。
シンプルなものがほとんどかなと思います。
それでいうと、どうですか?
モノリシックなサーバーサイドか、
マイクロサービスライクなサーバーサイドかだと、
やっぱりキャッチアップの方法って変わりますか?
サイズによると思っていて、
要するにちっちゃければモノリスでも問題ないと思っています。
把握できるので。
一方でデカいモノリスはもう把握できないし、
自分の管轄外が増えるので、
もう把握しきれないので無理です。
なのでそうなった場合は、
コードの読み方
かつ把握しないといけなくて、
責任分解点とかを容易に切り分けたりできるようにするためには、
やっぱりマイクロサービスとかモジュラルモノリスみたいな
アーキテクチャを採用する必要はあると思って、
コードベースのサイズによるという感じかなと思います。
とても巨大なモノリス。
モジュラルモノリスみたいな感じにして、
ディレクトリレイアウトで、
ここ、自分の管理範囲って分かるようにしていくのが
多分何なんじゃないですかね。
ディレクトリ、このドメインはよく触るだろうから見ておこうみたいな。
そうですね。
ディレクトリで思い出したんですけど、結構ディレクトリの名前で、
これは見るべき、見ないくていいっていうのを判断できると思っていて、
言語ごとにこういう切り分け方しようよみたいになって、
ある程度固まってたりとか、
クリーンアーキテクチャーとかレイヤードアーキテクチャーみたいなものを採用したら
結構決まってるかなと思うんですけど、
コントローラーとかサービスとかユースケースみたいな
メインの処理は見るけど、
ライブラリーリブ配下とか、
ユーティリティ配下とかは必要な時に見ればいいかとか、
そういうのは経験でカバーできますよね。
そうですね。この辺りはよくさそう。
あと、ドメインの中でも例えば、
ドメインはよく触るだろうなとか、
なんとなく想像できますよね。
フラッタやってた時に許せなかったのは、
全てのコードがリブ配下にあるっていう。
フラッタプロジェクトの文化っぽいですかね。
そうですね。あれはね、ちょっともう意味分からなかったですね。
最初に全部リブ配下にあるんですよね、
と言われて、えー?みたいな。
言われてみると他の言語だとあんまりない構成ですよね。
見たことない、他の言語だと。
あとは、あんまり自分たちは使わないけど、
OSSとか見ると存在してるディレクトリで、
Hack Directoryってやつがあるんですけど、
使ったことないですよね。
あまり見たことないかもね。
それはあれですか、めちゃめちゃ汚い実装だけど、
テンポラリーな感じで置いておくみたいな。
これはね、もう調べないと分からない。
Hack Directoryで一番最初に出てきたのが
Kubernetes Hackでした。
Goの。
なんか正式ではないが、必要なコードを置く場所って出てきた。
正式ではないか。
補助スクリプトとか、ワークアラウンドとか、
プロトタイピングとかそういうものを入れておくみたいな。
なるほど。
いやでもこれ無人像に使えそうな感じですね。
自分の関わるプロジェクトにはあってほしくないですね。
ディレクトリレイアウトで言うと、
ユーティリティって名前のディレクトリを作るのみたいな言語もあります。
話は忘れちゃいましたけど、
ディレクトリの重要そうなところだけ見るっていうのも、
コードベースの量によっては有効な戦略ですよね。
そもそも一つのサービスが複数、
例えば10個以上のリポジトリで構成されてるみたいなのも
だいぶにひょっとしますよね。
ありますよね。
だからその10個を自分が把握しないといけないのかどうかって話、
基本そんなことないことが多いんですけど、
だから徐々に慣れていけばいいように。
あとインフラのリポジトリは、
さっき説明した構成図を見るやり方でカバーできると思っていて、
構成図を見ればどんなインフラが起動しているかわかるので、
基本的にはそれベースで特にコードあんまり読む必要ないですね。
だからインフラを追加するというか変更するタイミングで
AIの活用と慣れ
そう多くないので、
追加するタイミングで本当に数行変更するとか
そういうことはありますけど、
大規模に変える場合はそもそもそのタイミングで時間をとって読めばいいので、
そんなに読むことは多くないですね。
考えるとインフラはそんなに構造になってれば大変なくて、
バックエンドとかフロントエンドは動き見ながら
よしよししそうなところだけ回数まで見ればよし。
ドメインがわからないものはじゃなくて、
使用書を読んだり場合の人に聞いたりしながら
だんだん交換していきましょうって感じなのかな。
論に至っちゃいましたね。
でも結局慣れなところはありません?
分かりますよ、おっしゃる通り。
プログラミングにあんまり慣れてないと
コードリーグリングめちゃくちゃ大変ですけど、
慣れてくるとこの関数の中身を読まなくていいやとか、
このクラスは大体やっていることを名前でわかるから
飛ばしとこうみたいな感じで
とりあえずバーって読んで
なんとなくこういうことやってるのねみたいなことだけわかれば
あと必要なときにつかぼればいいと思うんで
この勘どころを早く身につけるためには
全量読まないといけない。
今回はこんな感じで新しいプロジェクトに入ったら
今言ったような方法でコードベースをたくさん読んで
早くショートカットできるようになってください。
AIには積極的に頼った方がいいですね。
そうですね。AIで聞きましょう。
ありがとうございました。
