私はクラウドのプロダクトチームで働いているが、何を隠そう一番苦手で克服できていないことが、コードリーディングだ。ものすごーく時間かかるし、時間かかったうえに読み間違えたりするし、しかもめっちゃ頭使うのに他の人はずっと速いので敗北感しか残らない。先日もマネージャの Pragna に相談したら、最初は２時間かかるけど、３か月もしたら５分で終わるわよ。って言われたけど、いや、そもそも俺４時間は最低かかるねんけどな、、、って感じ。

技術イケメンの皆さんのアドバイス

　よくよく私のキャリアを考えると、OSSにコントリビュートとかしていることはあったが、めっちゃくちゃ巨大でややこしいコードベースを読んで理解する必要が無いことが多かった。１からコードを書くのは得意だが、他の人のを読んでがっつり理解してとか、どうやったら出来るのかわからない。

当然自分の周りの技術イケメンの皆さんにコツを聞いていたのだが、どうも要領を得ない。多分息を吸って吐くようにコードリーディングが出来ているのかもしれない。

クーパーの一言

ある時ふと思い立って、最近入ったとても若い同僚に聞いてみようと思い立った。彼は私が複雑すぎてうんざりしていた巨大なアーキテクチャに怯むこともなく、着実にコードでコントリビュートしてて、ものすごく速いなぁ、すごいなぁと感心していた。

そのクーパーに思い切って話を聞いてみた。「自分は DevOps チームに居て、コーディングが上手くなりたくてこのチームに来たんだ。１から書くのはいいんだけど、コードリーディングが苦手なんだけどどうしたらいいかな？」

コードリーディングのコツは極力コードを読まないこと

めっちゃ好青年のクーパーは、こんなことを言ってくれた。「コードリーディングのコツは、極力読まないことですよ。他のデベロッパーのことを信頼して、実装はちゃんと動くと思うんです。」えーーーって内心思っていたが、彼は続けて「だって、たくさんコード読むと、圧倒されちゃうでしょ？(本当に彼が言ったのはOverwhelmで、そっちの方が本来の感覚だと思う）

コードをたくさん読むと疲れる

確かに。自分はいつもコードを端から端まで読もうとして、細かく読んでいると、自分がどこにいるのかわからななくなったり、忘れたり、何より疲れてげんなりする。これは、自分が低レベルだからだと思っていたがそうではないようだ。自分のことを過小評価する性格だが、「自分が出来ないからこうなのだ」という分析は大抵において誤りを生むことに最近は気づいてきた。すごいやつも人間なのだから、能力に対して差は無いのだ。

実装ではなくインターフェイスと役割を理解する

次に彼が言ったのは、「実装は極力見ないようにして、インターフェイスと構造を理解するようにするんです。ダイヤグラムや、関係のグラフを書いたりして。実装はちゃんと出来ていると信じて、読んでいるメソッドやクラスのインターフェイスの役割やパラメータをしっかり理解するようにするんです。そっちの方が、実装を見るよりずっと楽ですよね。」そして、「もちろん、必要があるときは実装を観ますが、極力見ません。Javadocとかあるじゃないですか？あれをしっかり理解する感じ」

あああああ、、、と自分は思った。自分は理解するために端から端まで実装を読んでいたが、それをすると脳みそのCPUを消費しちゃうんだ、そして、本来理解しないといけない構造やインターフェイスと、実装の両方に資源を使うので、疲れる割に頭に入らないんだ、、、。

読むことを減らすと、脳に余裕が生まれる

確かによくよく考えると、コードを読めばいいのは本当に必要な時だけで、それよりクラスの役割やパターン、インターフェイスの理解が重要だ。自分がクラスライブラリを使うときと同じ感覚だ。だから、コードの実装を極力読まずにCPUの地力を残して、構造や、パターン、役割、インターフェイスの理解に注力する。そもそも、読む個所を極力減らす。

クーパーメソッドの実践

そんなアドバイスをもらって、そのアドバイス通りにコードリーディングしてみた。本来構造的にややこしいはずだが、余計なコードは極力読まず、読むポイントだけに絞って、使っているメソッドのインターフェイスだけを理解しようと努めてみた。そして、２時間もたたないうちにこう思った。

「楽勝じゃね」

まったく新規のコードベース、そのプロジェクトともう一つのプロジェクトがどうインターフェイスしているのかもわからない。ほとんどの箇所は理解していない。

　しかし、それでいいのだ。新規のコードベースと、もう一つのプロジェクトとの関係や、どこら辺を修正したらよさげかは、素直に人に聞いた。なぜなら、０から理解するのは難しいと思ったから。もちろん一部の実装コードは読んだが、普段と比べて疲れが全然ない。そして、読む個所が少ないのでつらくもなんともない。多分正確に読めてる。多分読む個所が少ないから。

才能がないのではなく、何かが間違っている

　今回の学びは、「自分にとって難しすぎるもの」と感じるものには２つのケースがある。一つは、自分の基礎的な学力が足りていないもの。これは１つ１つ積み上げるしかない。例えば私は証明書の実装を自分で書くとなると、証明書のRFPの勉強から始めないといけないだろう。でも、こんなケースはプロダクトチームでも少ないし、CSを出てない自分の場合手を出さなければ良いだけだろう。

　だが、２つめのケースは、自分が無理をしているケース。私の長年にわたるコードリーディングの思い込みがこのケースで、「自分に何かが足りない、才能が足りないから、こんな大変」と思い込んでいるケース。大抵は自分にとって難しすぎることは、何かが間違っているのだ。

　コードリーディングのコツは自分にとって衝撃過ぎて感動したが、正直みんなは才能あるからと思っていた。同じ人間なのに「才能」で片を付けると見誤るようだ。つらい、難しいと思ったときはきっとあなたに才能がないのではなく、何かが間違っているサインと思うことにしよう。

クリスでもコピペをする衝撃

　確かに相当技術イケメンのクリス（Azure Durable Functions を作った他に、さまざまなプロダクトを０から開発している）に相談したときも、「自分はあまり理解していないよ。自分の知らないコードベースの場合、コピー＆ペーストして改造するよ。そっちの方が理解できてなくてもアウトカムが出るよね」と聞いて、一流の人でもコピペするんや！って思ってびっくりした思い出がある。続けて彼は「でも、自分が作った Durable ならどこになにがあるかすぐわかるよね。」と言っていた。確かに自分が０から作ったコードなら全然すぐに理解できる。つまり技術イケメンであっても、複雑なものは複雑なのだ。そして、人間の脳の力にはそんな違いがない。

おわりに

これは自分にとってとてつもないブレークスルーでした。多分出来る人は基本的に空気を吸うようにこんな感じでやっているのだろうなと思いました。私のようにそうでなかった人でも、この仕組みを理解すると、いろいろ楽できそうです。これでコードリーディングが相当楽しくなってきたのでこれからめっちゃ楽しみ。

ハッピーコーディング！