見出し画像

ディープコードリーディングのすすめ

多分普通の人にとっては当たり前かも。でも自分にとっては、エンジニア人生最高のブレイクスルーなので、自分のメモのためにもブログを書いておきたい。

エンジニア人生の長年の苦しみ

 専門のデベロッパーになってもう4年ぐらい経っている。アメリカに来てから5年だ。しかし、自分がエンジニアとして一人前になれたという感覚はついぞ持てていない。最高に優秀なメンターとストラテジーのお陰で何とか首にはなっていないが、自分がちゃんとしたデベロッパーになれた感覚は全然なかった。理由は、自分はどう考えても開発スピードが遅い。いやくっそ遅いと言っていいだろう。

もうダメだ。これダメならエンジニア辞めて日本に帰ろう

 そんな時に決定的な事件が起きた。自分が新しい役割に移って早数か月、自分のアウトカムは0なのだ。いや、0に戻ったと言えよう。今はいろんなものが、移り変わっていて難しい時期ではあるが、たまたま趣味で書いていたAIアプリが認められて新しいポジションになった自分は成果を出そうと一生懸命がんばっていた。自分は自分のチームではないところに一時的に貢献しないといけない。
 ここしばらくやっていた自分のアプリを Deprecated にすることを決めて、皆がアップデートしている基盤に機能をマイグレートすることに決めた。しかし心中は穏やかではない。なぜなら、この時点で自分のアウトカムは0リセットしたから。だから、小さな機能でもまず成果を1にしようと頑張った。反応は普通だったけど偉い人にデモもしたし、プルリクエストもマージされている。それの機能強化をするようなプルリクエストを1週間ぐらいかけけて用意して、本番化してやろうと思っていた。ようやく成果が0から1になるぞと。
 ところが、本番化のためのテストの手順をあるエンジニアに教えてもら手いたら、そのエンジニアが言った。「君のコードは、デッドコードの上に書かれているから、新しいアーキテクチャの方に移動しなあかんよ」と。ちょっとまて、わしのプルリクエストでレビューの人なんも言ってへんかったけど。マジ、という事は、マージされたやつもふくめてまた成果0に…しかも全く新しいアーキテクチャから、知識も0リセットである。
 さすがに自分の駄目さに嫌気がさした。自分才能ないのはわかってたつもりやけど、ここまで間抜けやとは思わんかったわ。自分は一生懸命頑張ってアホみたいに時間使ってきたけど、これはもう「あきらめる」ときなんやろうかと思った。こんだけ頑張ってやってもアカンならしゃーないし皆に迷惑かけたら申し訳ないから。

最後のトライ

 でも、5年もアメリカでアホみたいに頑張って来て、ちゃんとしたエンジニアになるという自分の夢を全く達成できるのも辛いので、心に決めた。次にストラテジーを決める。心の健康を保つためのギター以外のすべてを切り捨てて仕事にフォーカスしてそれをやる。それでもだめならもうあきらめようと決めた。

最後のストラテジー

 この最後のストラテジーと思って考えたことが「ディープコードリーディング」だ。今回の問題は、自分が別チームで情報がほぼ入ってこず、自分が慣れてないリポジトリの事は部分的に(しかもデッドコードになった部分のみ)しか理解できてなかったことにある。そして、自分がそういった情報をキャッチアップできてなかった。そのリポジトリはアホみたいに変更が早い。その対策として思い出したのが、昔一緒に仕事をしたことがあるめっちゃくちゃ優秀な近永さんというエンジニアの事だった。彼は ruby のコミッタだが、彼がずっとやってたことに、ruby の trunk の変更を毎日ブログにしていた。どうやら今もやってるっぽい。

 もしかして、コテコテに出来るエンジニアって他人のPR読みまくってたりする?自分のFBで聞いてみると、このブログにも良く出てくるクッソ優秀なKenさんもしょっちゅう読んでる様子。もしかして、これ?

ストラテジーの実施

 私はマネージャに0アウトカムの絶望的状況を説明して、これにフォーカスさせて欲しいと話した。もうだめならどうでもいいや。と思いながら思いついた戦略は次の通りアホみたいに単純である

  • 自分に特に関係ある主要開発者のすべてのPRを読む

  • 1週間に、2回ほど時間を予約して、他の人のPRを読む時間を作る

とは言え、これは簡単ではない。なぜなら、自分が技術者として一人前と言えない理由は、他の人と比べて、理解の把握の弱さと、他の人の圧倒的なスピード、自分のPRのマージの遅さ。時に沢山のPRがマージされないまま残るつまり、頑張ってるんか知らんけど、意味ないことに頑張っている。
 こんなので、自分がちゃんとしたエンジニアとはとても言えない。よく首にならないものだ。
 そんな自分だから、このストラテジーがワークするかもわからない。レビューとかで1つのPRを読むのも大変やのに全部とかできるんやろか?いや。自分で決めたんやから、何時間かかってもやってみる。ダメなら会社辞めるだけやしな。

ディープコードリーディング

 自分はディープブルースが好きで、最近はよく上達のために誰も見ない動画を上げている。しかし、今回のディープはちょっと意味が違う。

 ディープコードリーディングは、めっちゃディープなコードリーディングの事だ。リポジトリが最近統合されたばかりなので、私が観るべき主要開発者の最初のPRから見始めた。さすがにもう5年もいたらC#の文法で分からないとかは無いが、どういう構造になってるのか、なんのためにこのコード書いているのかから含めてなんもわからない。いつもなら、自分のエリアにフォーカスして、そこだけでもなんとか理解するようにしているが、今回は正反対のストラテジだから。この最初のPRを「完全に」理解すると決めた。

 一つのアドバンテージは、我々には「GitHub Copilot Agent」がある。なんでも聞ける。この最初のPRを理解するためだけに2日使ったが、すべてを理解した。というか、何か少しでもわからないことがあったらすべて Agentに聞いた。この設定ファイルがどのように読まれて、どこで使われているのか?コントローラーから、1つのチャットメッセージのライフサイクルでどういう挙動になっているのか、なぜこのクラスは、こういうネーミングではなく、こういうネーミングなのか?少しでも疑問が浮かんだらすべて聞いてをそれを OneNote に書いていった。
 私が参考にしている勉強法の YouTuber の人が、新しい事を学ぶときはインデックスつまり、概要をざっとつかんでから本とかでも読むと良いと言っていたので、同じストラテジをとった。自分がゆっくり読んだらちゃんとわかりそうであっても、まず、チャットにこのメソッドやクラスは何をしているのか、どういう目的で作られているのかを聞いて、サマライズさせて、そのサマライズをさせている間は、自分はどこかのコードを読むようにした。自分がこのシステムの挙動で知りたいことを質問にして、それを一つ一つチャットに聞いて、その概要を読んで、実際にコードを1行づつ読んで理解していった。わからないこと、疑問もすべてつぶした。

 結果たった1つのPRを理解するのに前述したとおり、2日かかった。しかし、1つのPRを完全に理解した結果、そのリポジトリの主要なアーキテクチャはすべて理解できている感じになった。これは今までの自分だったら時間の無駄だろうと決してしてこなかった選択だった。

まともなエンジニアになるための最後のピース

 最初の1つのPRが理解出来たら後はめっちゃくちゃ簡単だった。最初のPRからさかのぼってその主要エンジニアのPRを読んでいくと他のは速攻で読めた。もちろん飛ばし読みとかではない。もうアーキテクチャが分かっているので、PRの差分を眺めるだけでほぼほぼ理解できる。たまーに、意図がわからないときだけ、ローカルにチェックアウトした最新のコードを読んだり、リファレンスを追いかけたり、チャットに聞いたりもしたが、ほとんどそれも必要ない感じだった。ついでにいうと、変更の履歴をおっかけていると、負荷がとても少ない。状況が理解できるからだ。私はその主要技術者のすべてのPRを半日もかからない間に読みえて、もう一人の主要開発者のPRも全部読んだ。つまり、私はこのトランジションに3日使ったが、自分がかつて感じたことのない「コンフィデンス」を感じていた。どのPRを観ても全然簡単に理解できるし、時間もかからない。これが、技術イケメンの皆さんが観てた風景なのか。

開発に取り掛かる

 さて、私が自分の Deprecated したアプリにあった特殊な機能をこちらの自分が3日前まで全く知らなかったアーキテクチャへの実装を考えるときの効果はすごかった。全然把握できてるので、こんなアーキテクチャでいけばええんちゃうか?思いつくし、自分が既存機能をよくわかってないために、無駄なコードを書くこともない。
 PR読みは高速化されているので、最新のPRのタイトルを眺めたり、コードを読んで、「あー、この機能は誰もやってないな」じゃあ、わしやるか。でも、あの部分は既に実装されているので、自分もそれに乗っかろう。みたいな感じですべてが楽になった。こんなことを感じたことはエンジニアになってから初めてのことだった。自分が長年求めていた最後のピースがはまった感覚がした。ギターの時もそうだったが、上達は、リニアではなく、突然ブレイクスルーがある。それは連続して起こせないけど、それに気づいたらぐっと上達するポイントがある。ギターの場合は、シャッフルの解釈の仕方だったが、ソフトウェア開発の場合だと、もしかすると、自分の場合これが、長年問題だったので、上達している感がなかったのでは?

副次的発見

 このようにPRを追いかけていると、副次的な効果もあった。それは、他の開発者がどんな感じでPRを作っているか、他の人が Approve しているかが分かったことだ。
 自分はいつも、PRが遅いし、なかなかマージされない、そもそも観てもらうのが一苦労というのがずっと悩みだった。
 PRを小さくというものよく聞くけど、自分なりに小さくしているけど、全然効果が無かった。
 ところが、このPR完全理解&全部読み(名付けてディープコードリーディング)をやることで、他の人のPRが、ホンマしょーもないぐらい小さくて簡単で、必要な機能すら満たしていないレベルであるとわかった。
 自分はPRを小さくとよく聞いていたので、最小の1つの機能で完結して、しっかりテストをしてPRを作っていたがこれは、「でかすぎ」たのだ。
 他の人のPRを見ていると1つの機能で全然完結してなくて、その機能を将来実現するための1つのパーツぐらいでもPRを作っていた。だから、レビューがクッソ簡単だからみんなApproveしてくれるという流れだとわかった。
 自分が長年、遅い、遅いとか思ってたけどそうではなかったのだ。実は自分は、めっちゃ速いとマネージャや一緒に働いているエンジニアに言われることがあって「何言ってるねん?」と心の底から思っていたが、確かに私の機能レベルをがっつり早くだしてきたら確かに速いのかもしれない。(まぁ、Vibe Coding してるけどな)
 今までは自分は漠然とめっちゃ遅いと感じていたが、今は高速なエンジニアでも、これぐらいのPRを日にこれぐらい。というのが正確に理解できたのは大きな収穫だった。

PRを分割する技術

 でも、自分には、PRを適切に分割するセンスがない。AIに頼ろう。というわけで、新しい機能を作るときに Vibe Coding する際に、単に一気に機能を作るのではなく、ask モードでアイデアとどういう実装にするかという相談をする際に、既存のコードを壊さないように、小さなステップでPRを分けて実装したいという言葉もつけて相談すると、どのようにPRを分けるかのアイデアをくれた。AI様様である。例えば、先にみんなが使うドメインオブジェクトに、項目を足すだけ、皆が使わない新しいプロバイダを作るだけでPRを書いたりする。そうすると、安全なので、多分レビュワーも Approve しやすいのだろう。他にもAIがどういう風に段階的にPRを書いたらよいかの案をだしてくれるので、気に喰わない部分は、修正を指示する必要があるが、そうしながらやってくと、自分のPRは瞬間でマージされたのだった。単に自分のPRは「でかく」「リスキー」だったのだ。だから、Approver は 観るのも大変だったのだ。

初めて得た「コンフィデンス」

 これをやって、自分は、自分のやった変更に対して他人に聞くことなく自信を持てるようになった。もうコード読んで100%理解しているからわかっているからだ。もう人に聞かなくてもコード読んだらわかる。

 一旦これを体験してしまうと、他の全く知らないコードベースでもこれにたった3日時間をつかうだけでこうなれるとわかったので、同様にすればよいだけなので、知らないコードベースに対する恐れもなくなった。多分自分のエンジニアとして足りなかったのはこれだったのだ。「他人のPRを読んで100%理解する」

Vibe コーディング時代の必要スキル

 Vibeコーディングを今はしょっちゅうやってるが、自分が書く方がはやいのか、Vibeの方が速いのかわからなくなる時がある。結構 Vibe は勝手にやってくれるけど遅い。遅いけど勝手にやってくれるので、嬉しさもある。こうやってVibe をしながらブログもかける。

 だけど、絶対的に重要だと思うのは結局「理解」なのだ。Vibe コーディングは単なるツールだが、理解こそが必要で、これがあると、すべてが速くなって、コンフィデンスが持てる。これに使う時間はたった3日だ。理解があれば、AIに適切な指示が出せるし、AIがアホなコード書いたときも「ちゃう」と言い切れる。昔だと、「理解」にめっちゃくちゃ時間がかかるので、途中で妥協せざるをえなかったかもしれないが、今はAIがあるので、本当に、最後まで完璧に理解することが短期間で出来るのはまさに最高である。
 勝手にやってくれるのも最高だが、それより、完璧に理解できる環境が出来たのが最高である。これが「ディープコードレビュー」というわけだ。

最後に小さな Tip を

GitHub Copilot Agent でこの設定絶対。デフォルトは 25 だから、しょっちゅうボタン押さんといけないけど、これぐらいにしとくと、ほんと勝手にやってくれる。だから、昼飯前に指示してあとやってもらったり、やってもらってる間に家帰ったりしてる。マジ最高。

画像
これ最高

まとめ

 自分のエンジニアとしての能力に悩んでる人、是非「ディープコードリーディング」やって、他人のPR読みまくってみてな。マジで視界変わるで。さて、本日3つ目のPRを投げて今日は寝るか。


ちなみに、本は11万部も超えたし沢山読まれたし、もう満足やけど、よかったらどうぞ。


いいなと思ったら応援しよう!

コメント

ログイン または 会員登録 するとコメントできます。
note会員1000万人突破記念 1000万ポイントみんなで山分け祭 エントリー7/8(火)まで
ディープコードリーディングのすすめ|牛尾 剛
word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word

mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1