はじめに
こんにちは文系卒新人エンジニアのyukiです。
この度研修期間が終わり配属され製品の中身を理解するために毎日あたふたしています。
新人エンジニアが製品のコードを理解するためにこんなことをやっているよということをこの記事では主にシェアします。
補足：この記事の対象読者
- 新人エンジニアや未経験からバックエンド開発に配属された方
- 仕様書が少ない現場で「自分でコードを読んで理解したい」と考えている方
- AIツール（GitHub Copilotなど）を使いながらも、自分の力でキャッチアップしたい方(コードを理解するためのプロンプト例を知りたい方）
- コードを読む力を高めることが目的であって早く製品の中身を理解することが第一目的でない方
- ある程度AWSの知識がある方
自分の置かれた環境,状況について
- 配属されたのは製品のフロント部分ではなくバックエンドを担当する部署です。
- 部署はできて1年で製品の詳しい仕様書等が存在しません、自分で製品のこの機能はこうなっているのキャッチアップが必要です。
- 製品の動作はAWS上での実行となるため、部署ではPostmanを使用しAPIをAWSの自分のステージに投げることで動作の検証を行っています。ローカルのdebugモードでコードを追いかけることができない環境です（絶望）
- 難易度は高いが自分のスタンスとしてコードを追いかけて理解するほうが先輩に1から10まで聞くよりよさそうだと感じています
- 筆者のコードを読む力は高くはないです。コードを1から10まで自力で理解することはとてもじゃないけど無理です。（なんでこういうコードになっているんだろうがそもそも製品がこういうことができるという理解が足りてない）
自分の2週間前の状況
debugモードがないことに絶望し、とりあえず何かの助けになるんじゃないかとファイルの中の内容全部AIに解説させてみました。
→わかってはいたけど結果は微妙でした。
理由としてそもそも生成AIは嘘をつくし、実際の製品がどうなってるかなんて1から10まで把握しているはずがないからですね。(特にDBの内容がなにか入ってるかなんてわからない）
ここで製品の機能を理解するためにDBの中身とかログとかの内容を自分で見て理解する必要性を感じました。コードを読むことやログを見ることは時間がかかりますがこれも自分のコードを読む力を高める修行だと考えました。自分のコードを読む目的を早くコードの理解をすることではなく自身のコードを読む力を高めることに設定しました。
偉そうに書いてますがこの時の自分はエラーログの内容を生成AIにぶん投げてエラーがどこにあるかを探してもらっていて、先輩にそれは成長を阻害しているとご指摘も受けていました。（エラーログを自分で読むようになってからどんなエラーが何が原因で起きているかそれがコードのどこにあたるかをある程度あたりを付けられるようになりました。）
結論から言うと全部いきなりコードを全部自分で読むということは力が足りていないため無理でした。ある程度なにやってるかという事前情報があれば理解できるなという風に気付いたのでちょっと事前情報だけAIにもらおうっていうことを思いついた感じです。
現在私がやっていること
一言で書くなら生成AIとレスバしています。（レスバとは口論という意味です）
ファイルをまるっと説明させる→レスバをしかけるという感じです。
0.Githubcopilotにファイルをまるっと説明させる（半信半疑で見る）
GithubCopilotではファイルを指定してからプロンプトを投げることができます。
なおここではコードの内容をいち早く理解することが目的ではないため「変数等でわからない情報があれば聞き返すことをしてください」みたいなプロンプトは投げません。
プロンプト例
「以下のルールに従ってこのファイルの中にあるコードを詳しく解説してください
・どの順番でメソッドの呼び出し処理が行われているかを最初に明記すること
・すべてのメソッドの引数で何をとってきているかを記述すること、その引数が具体的になんであるかを記述すること
・このメソッドで最終的に返り値にあたるものが何か、S3やDBに何が起こるのかを記述すること
」
1.製品の機能のコードを読みどの文が何をやっているか自力で仮説を立てます。
（draw.ioで図を書きながらだと思考の整理がしやすかったです。draw.io使い方まとめはこちら）
2.検証方法として機能を用いたときに実行状況をAWS上のStepfunction、Cloud Watch LogsやDBのクエリを駆使して実際に何の動作をしているのかを自分の目でたしかめにいきます。
3.得られたログ等をGithubcopilotに突きつけレスバを仕掛けます。
自分が投げているプロンプトの例は以下の通り。
「この～というメソッドで～の変数を先ほど～という意味で説明してたけど、この説明はDBのこのテーブルの中身がこういう中身でこのファイルのこのメソッドでDBのテーブルの指定をしているためおかしいと思う。正しくはこの変数は～を表していると思う」
レスバに負けたら自分自身のコードの読み方のどこが間違っていたかがわかります。勝てたらハッピーです。
4.理解した内容を先輩に見てもらって本当にあってるか、調べてもわからなかった点の疑問点の解消をします。
つまりそもそものコードを読む、ログを見ることを時間かかってもいいからやろうぜって話ですね。なにを当たり前のことをと思われるかもしれませんが、そもそも実行情報をどこからどう集めて検証するかがわからなかったため、これが2週間前はできませんでした。
LamdaのCloudWatchLogやStepFunctionの入出力の確認、S3やDBの確認といった方法。これらを自分で調べたりを先輩に教えていただくことでようやく検証ができるようになりました。
まとめ：AIツールでのキャッチアップ
- AIはキャッチアップを多少楽にするくらいの使い方がいいと感じます：全部AIに解説させると強くなれません。
- AIは万能ではない：CopilotやChatGPTはコードの説明はできるが、実際のデータや運用状況までは把握できません。そもそもその説明も間違っていることがあります。
- 仮説を整理するために図を書く：draw.ioはおすすめです！仮説を可視化しましょう。
- 検証をどうすればできるかを考える：DBやログの内容をどうやってもってくるかを考えましょう。検証方法がわからないときは先輩に聞きましょう。いい方法を知ってます。
- AIとレスバしましょう：仮説の検証のためにDBやログの内容を用いましょう。レスバすることでレスバに負けても自分の仮説がどう間違ってたかわかり強くなれます。
- 先輩に本当にわからないものを聞いちゃいましょう：全部自力は無理です。先輩に聞くことで先輩の思考方法ややっている事を盗みましょう。検証も同時にできます。