【コードリーディング】実務経験が浅い内に、最速で成長するためにはコードリーディングが最適解だと考える理由とは？

バートリーのさいとうです。

今回は

実務経験が浅い内に、最速で成長するためにはコードリーディングが最適解だと考える理由とは？

というテーマでお話ししていきます。

皆さんも、こんな経験ありませんか？

• 期限が差し迫っているけど、開発が終わらない
• 何度もやり直しを迫られて、開発に時間がかかる
• なるべくミスなく実装を行いたいのに、結局余計と不足がたくさん…
• 結果的に、成長できている感覚が薄い…

など、辛い思いをしている方が、絶対いることと思います。

僕もそのうちの1人です。

そこで、同じような悩みを抱えている人に（自分への戒めも含めて）、この課題を解決するためのtipである

「最速で成長するために、コードリーディングをやるべきだと言える三つのメリット」

についてお話ししていきたいと思います。

この記事を読めば

• コードリーディングで確認するべき箇所がわかる
• やり直しが減り、開発の余分や漏れもなくなる
• コードリーディングに意味を見出し、コードを読みたくなり、最速で成長できる

と思いますので、エンジニアとして最速で成長したい！と考えている方は一緒に成長していきましょう。

そもそも、コードリーディングをする目的とは？

そもそも、まず初めに、なぜコードリーディングをするのか？について触れておきましょう。

理由は、コードリーディングをする理由が明確になっていると、後述する3つのメリットもスッと入ってきやすいだろうと思ったからです。

僕個人としては、こちらの記事に書かれている表現が、非常にしっくりきました。

コードリーディング===本を読むこと

この表現が示す意味合いとしては

本を読むように、この作者は何を考えながらこのディレクトリに、このファイル名で、こういったコーディングをしているのかなどの背景をしっかり掴みながら読むことだ。

とされています。

本を読む時、「この著者は何を言おうとしているのだろう？」と考えながら本を読むと思いますが、エンジニアリングにおいてはそれがコードリーディングなんだよ、ということですね。

つまり、なぜコードリーディングをするのか？への答えは

そのコードを書いたエンジニアやプログラマの「意図や背景」を読み取るためである。

とまとめることができそうです。

最速で成長するために、とにかくコードリーディングをするべきだと言える「三つのメリット」

では、ここから本題のコードリーディングをする3つのメリットをまとめていきたいと思います。

先に結論から言うと

• 技術の知識が、自然が広がる
• 開発するサービスやプロダクトの「色」が見えてくる
• （運用保守の場合は特に）跳ねる範囲を理解できる=バグを減らすことにつながる

という三つのメリットがあると思います。

一つずつ解説していきます。

技術の知識が、自然が広がる

一つ目は、技術の知識が自然と広がっていく、ということです。

少し抽象的なので、具体的に説明します。

エンジニアリングという世界に一度足を踏み入れたからには、日々勉強することが出てきますよね。

具体的には、開発言語のことから、ミドルウェア、インフラ、設計手法…などなど、本当に毎日が新鮮です。（飽き性の自分にはぴったり）

その中で、すべての知識を「理解」するのはほぼ不可能ですが、「認識」することは可能だと思います。

ここで、理解と認識の言葉の定義をはっきりさせておくと

• 理解 = 使い方を知っている、具体的にどうすればいいかがわかっている状態

• 認識 = それがあることがわかっているけど、具体的にどうすればいいかはわかっていない（曖昧な）状態

となります。2軸でとらえるならこうなります。

エンジニアは、ググったり技術書を読むなどする、いわば「カンニング」がOKの世界で生きています。

だから、とても極端なことを言えば「こういうやり方・技術があるんだ〜」と認識しているだけでもなんとかなる場合もあります。なぜならやり方は、カンニングOKだからです（もちろんその知識をどう使うか？を考えられる応用力は必要です）。

では、その認識を広げるためにはどうすればいいんでしょうか？

その答えが、「コードリーディングをする」ということになります。

例えば、僕は最近cssの疑似要素という概念を認識しました。

技術の詳細については本題と逸れるので割愛しますが、少なくとも今扱っているサービスのソースコードを読んで認識できたことです。

もっと言えば、実際にサービス内で使われているのでその様子を見ながら「こういう風に使えるんだ〜」と理解することもできました。

このように、コードリーディングをすることで知識を広げられる、更にはその理解も深められます。

これが一つ目のメリットです。

開発するサービスやプロダクトの「色」が見えてくる

2つ目は、開発するサービスやプロダクトの「色」が見えてくる、ということです。

すでに開発ローンチされ利用されているサービスには、そのサービスで使われている色があると思います。

サーバーサイドには（railsの場合）

• ビジネスロジックの切り分け
• ディレクトリの切り分け
• 命名規則

などがありますし

フロントエンドには

• フォント
• カラーリング
• ボタンの形
• jsの挙動

など、目に見えている部分で共通点がたくさんあります。

もし、これらを踏まえていない実装をしてしまうと、どうなってしまうか考えてみましょう。

考えられる弊害として、例えば以下の三つが挙げられます。

• サービスのUIが統一感を失う
• （次にn後述しますが）影響が跳ねて、バグが発生する
• ソースコードがグッチャになる＝技術負債が蓄積し、運用コストが高まる

僕が思いつくだけでもこれだけやばい弊害があります。逆に言えば、しっかりコードリーディングの結果が踏まえられた実装ができれば、その結果も評価され、サービスの質も向上し、運用コストも下がるということです。

個人に焦点を当てれば、 PRを潜り抜け早くリリースまで漕ぎ着くことで、どんどん開発の経験を積み成長していけるという意味合いで、みっちりとコードリーディングはする価値があると思います。

（運用保守の場合は特に）跳ねる範囲を理解できる=バグを減らすことにつながる

先述の通り、特にサーバーサイド側では複雑にデータ構造が組まれており、いきなり開発に取り組もうとすれば自分の知らないところでバグが起こりかねません。

これはcssの指定をしたら、違うところのレイアウトも変わっちゃったみたいなことが起きるフロントでも同様です。

このように、思いがけないバグや不具合を作ってしまうと、その分コストが発生します。

かつ、修正するのは、新しく作るくらい大変です。

影響が跳ねる範囲をしっかりとコードリーディングで理解し、それを踏まえて開発をしたいものです（自戒）。

まとめ：でも結局、設計が一番大切

ここまで、コードリーディングをするメリットを三つ紹介してきました。

では、コードリーディングをしてその結果をどう活かすんでしょうか？

それが、設計です。

チェリー本でお馴染みの伊藤さんも、こちらの記事で設計の重要性と具体的な手順を解説されておられました。

コードリーディングが「ヘ〜」で終わるか

「であれば、こうしてああして、この可能性もあるな…」などとその結果を活用できるか

その違いが、設計をきちんと行うかに現れる気がしています。

なので、コードリーディングをしたら必ず上記のqiita記事を参考に

設計をしましょう。（自戒）

このように、月に15本目標で、Ruby, Ruby on Railsを中心に技術ブログを更新しています。

もし参考になったなと思ったら、ブックマークをお願い致します。

最後まで読んでいただき、ありがとうございました！

それでは。