【エンジニアが教える】実務で活かせる!ソースコードの読み方
「ファイルがたくさんあってどこから読めばいいか分からない...」
「調査でソースコードを追う必要があるけど、処理の内容を理解できない...」
経験の浅いエンジニアだと、こんな悩みを抱える人は多いです。
しかも周りの人にアドバイスを求めても、
「場数を踏んで経験を積んでいけば、そのうちだんだん読めるようになるよ!」
と言われて困っている、という人もいるのではないでしょうか?
経験を積むことによって、簡単にソースコードを読めるようになります。
それは、回数をこなすことで、ソースコードを読むときのポイントを押さえることができているからです。
本記事では、10年間エンジニアを続けてきた筆者が、
「ソースコードを読む上で押さえるべきポイント」を紹介します。
ポイントを理解し、ソースコードを読む力を身に着けて、実務で活躍できる1人前のエンジニアになりましょう!
「ソースコードを読むのが難しい」と感じる理由
では、なぜ「ソースコードを読むのは難しい」と感じ、つまづいてしまうのでしょうか。
大きく分けて、2つの理由が挙げられます。
理由1:ファイルが多くて、どこに何が書いてあるか分からないから
実際に稼働しているシステムのソースコードは、多くのファイルで管理されています。
システム規模や使用しているフレームワークによって変わりますが、
数百ファイル管理されているのは一般的です。
個人の学習で、ここまでのファイル数が必要になる開発を行う人は少ないです。
そのため大量のファイルを見て、「どこから目を通せばいいのかわからない」と感じてしまうのです。
理由2:ズラッと並んだソースコードを見て、「複雑」だと感じてしまうから
業務に使われているシステムは、業務要件を満たすためにたくさん処理が書かれています。
大量の行数で書かれているソースコードを見ると、「とても複雑なことをやっているんだ...」という印象を受けてしまうため、
ソースコードを読むことに対する苦手意識に繋がります。
ソースコードを読む前に押さえておきたいポイント3つ
この「難しい」と感じてしまう理由に対して、どのように対処すればよいか。
大切なのは、「ソースコードを読む前に意識するべきことを知る」ということです。
いきなりソースコードを読むではなく「事前にポイントを押さえてから読む」ことで、
頭の中を整理しながら読めるようになり、作業効率が上がります。
そのシステムの概要を知る
システム開発に携わる際の前提として、「どういった業務要件を満たすためのシステムなのか」を知っておくことは大切です。
「業務システムなのか、ポータルサイトなのか」によって必要な機能は変わりますし、
同じ業務システムでも業界によってシステム化される機能は異なります。
「これはECサイトのシステムなんだから、『ユーザ・注文・在庫・売上/請求』を管理するような機能があるんだろうな」
とアタリを付けるだけでも、ソースコードを読む作業の効率・理解度が上がります。
使用しているフレームワークを知る
「どのフレームワークを使って構築されたシステムなのか」も把握しておきましょう。
フレームワークを使った開発であれば、システムが異なっても、実装方法やディレクトリ構成が大きく異なることはありません。
つまり、他の事例を参考にすることができるのです。
「フレームワーク名+調べたい内容」で検索すれば、大半の疑問は解決することができます。
(ex. 「springboot データ取得」「laravel ディレクトリ構成」)
また、ソースコードに書かれている実装が、
「元々の言語仕様によるもの」なのか「フレームワーク特有のもの」なのかを区別するのは、最初のうちは難しいです。
(※言語仕様、フレームワーク仕様いずれの知識も必要になるため)
こういったときにも「フレームワーク名+調べたいキーワード」で検索することで、答えを見つけやすくなります。
ただ「読む」のではなく、「目的に合わせた読み方」をする
「ソースコードを読む目的」は、大きく2つに分類されます。
- 「全体の流れを把握する」
- 「細かい仕様を確認する」
たとえば、プロジェクト参画直後は、(1)「全体の流れを把握する」ために読む必要があります。
改修が必要になったとき、「他の機能ではどういう実装になっているのかな?」と参考にする際にも、
処理の流れをざっくりと理解することを目的として読んだりします。
一方、不具合調査を行う際には、(2)「細かい仕様を確認する」ことが求められます。
「具体的にどういう処理をして、どこが不具合の原因になっているのか」を調べる必要があるので、
じっくりと細かく読んでいくことが求められます。
このように、目的によって「求められるソースコードの読み方が変わる」ということを意識しておきましょう。
ソースコードを読むときの流れ
ソースコードを読むときには以下の流れで行います。
- ディレクトリ構成/ファイル構成を確認する
- 処理のトリガーとなる場所から読み始める
- 読む前に処理をイメージする
- メソッド名や変数名から推測しながら読む
ディレクトリ構成/ファイル構成を確認する
最初は、全体を把握するために、「ディレクトリ構成/ファイル構成がどのようになっているか」を確認します。
これにより、
「どこに何の処理が書いてあるのか」「どういった設計思想(MVC/MVP/MVVMなど)で実装されているか」
をある程度想定することができます。
- 画面(UI)となるファイル
- リクエストを受け取るメソッドが実装されているファイル
- ビジネスロジックが実装されているファイル
この3つの構成を押さえておくだけでも、ソースコードを読む際のハードルは下がります。
ディレクトリ名からある程度推測することはできると思いますが、どうしても分からない場合は以下のようなアプローチをしてみましょう。
- 「フレームワーク+ディレクトリ構成」で一般的なパターンを調べてみる
- 画面に表示されている固定メッセージの文言で、プログラム内を検索する
- これにより、画面(UI)のファイルがどこに格納されているか分かる
- URLからControllerのクラス名を推測して、プログラム内を検索する
- たとえば「/user/list」のURLであれば、 「『UserController』というクラスがありそうだな」という推測を立ててプログラム内を検索する
処理のトリガーとなる場所から読み始める
システムにおける処理は、「ユーザが操作してから処理が実行される」というものが大半です。
(※バッチ処理など、一部例外はあります)
たとえば「アンケート入力フォーム」であれば、ユーザが入力して「送信」ボタンを押したら、登録処理がサーバ側で実行されます。
「送信ボタンを押す」という操作がトリガーとなり、登録処理が行われるのです。
プログラムの処理を追うときも、
- 「処理のトリガーとなる場所」はどこか
- どこの処理が呼び出される(リクエストされる)か
という流れで読み始めるようにしましょう。
読む前に処理をイメージする
「この機能はいったいどんなことをしているだろう?」と先にイメージしてから読み始めるのもポイントです。
どんなシステム、フレームワークを使っていても、基本的な処理の流れは変わりません。
「データを表示する機能」「入力データを登録する機能」「ファイル取込機能」はどのシステムでも存在する機能です。
ソースコードを読まなくても、それぞれ以下のようなレベルで処理を予測することはできます。
①データを表示する機能(一覧・詳細画面など)
- 一覧画面なら、画面で指定された検索条件を受け取って表示データをSELECT
- 詳細画面なら、リクエストに含まれるキー(ID)をもとに表示データをSELECT
- 画面に表示する
②入力データを登録する機能(登録・編集画面など、フォームがある画面)
- 画面で入力された値を受け取る
- 入力値のチェック処理を行う
- DBへのINSERT/UPDATE
- 登録後処理(集計など)
③ファイル取込機能(CSV,PDFなど扱うファイルはさまざま)
- ファイルをアップロードする
- ファイルを読み込み、処理を行う
- CSV取り込みであれば、1行ずつファイルを読み込みながら処理を行う(入力チェック、DB取込、件数カウントなど)
- 後処理
- 取込結果(処理件数、エラー内容)の表示など
どんな処理を行っているか全く想像がつかない状態で見るよりも、事前に処理の流れをイメージをしておくことで、
「この行はきっとこういう処理をしているんだろうな」
という推測を立てながら読むことができるため、より理解しやすくなります。
メソッド名や変数名から推測しながら読む
呼び出したメソッドの中身まで全部読み、処理を追っていると時間がかかってしまいます。
全部を読まなくても、メソッド名や変数名からある程度処理を推測することができます。
たとえば、こんなソースコードの場合。
$user = $this->userRepository->findByMailAddress($mailAddress);
呼び出しているメソッド名、引数として渡している変数名、格納先の変数名を見れば、
「メールアドレスをキーに、ユーザ情報を取得している」
という推測が立てられます。
わざわざ「UserRepositoryのfindByMailAddress」の処理を見に行く必要が無くなります。
このようにメソッド名や変数名を見て、
「これはこういう処理をやっているんだろうな」
「変数名を見るかぎり、きっとこういうデータを取得してきているんだろうな」
と推測をして読むことにより、効率的に処理を理解できるようにしましょう。
「読む行数が増える」ということは、その分「頭の中で覚える行数も増える」ことになるので、すぐに疲れてしまいます。
「いかに読む行数を減らすか」という意識も大切です。
ソースコードを読むときに使えるテクニック
デバッグする
「デバッグしながら動かす」と、実際の処理の流れやデータ(変数)の状態を確認できるため、処理を理解するうえで非常に効果的です。
主な方法としては以下の2つです。
- デバッグツールを使う
- 簡易的にログやコンソール出力
デバッグツールを使う
処理を確認したいところにブレークポイントを置き、1行1行ステップ実行しながら処理の流れを追っていきます。
簡易的にログやコンソール出力
「ここを通っているか確認したい」「この時点でどういう値が入っているか確認したい」という場所に、ログ出力のコードを埋め込んでおきます。
実行後にログを確認して、埋め込んだ文言が出力されていれば、その箇所を通っていることが分かります。
メモする
「頭の中で全て記憶しながら作業をする」のはとても疲れますし、一度理解しても「少し時間が空くと忘れてしまう」ことも多々あります。
一度読んだ箇所については、テキストベースで良いので処理の流れをメモしておくのがおすすめです。
「理解した内容の整理」や「もう一度調べ直す二度手間を防ぐ」うえで、非常に重要なテクニックです。
文字列で検索する
ここでも少し挙げましたが、
「どこに実装されているか、記載されているか検討もつかない」ような時に「特定の文字列で検索する」のは効果的です。
これは私自身の経験ですが、「実行するSQLは.sqlファイルに外出しする」方法で実装されているプロジェクトに参画し、
「このSQLファイルどこにあるんだ...?」と、大量のファイルの中から見つけ出すことができなくて困ってしまい、
結局findコマンドでディレクトリ内を検索することで解決したことがあります。
こういった「地道なテクニックを駆使しながら解決する」のは実務においてよくあることなので、
テクニックの1つとして頭に入れておくと良いです。
まとめ: ソースコードを読む力を身につけて、1人前のエンジニアとして成長しよう
「ソースコードを読む力」は、エンジニアとして必ず求められるものです。
この記事で挙げたポイントを理解しながら何度も経験を積んでいくことで、着実に身に付けることができます。
「もっとこういうところも意識した方が良いな」と気付けた時、それはあなたが「エンジニアとして成長できた証拠」です。
たくさん知識を吸収しながら、現場で活躍できるエンジニアを目指していきましょう!
「後から見ても読みやすいコード」を書こう
「ソースコードを読む苦労」を知っている人は、「読みやすいソースコードを書くことの大切さ」を理解することができます。
- メソッド名・変数名は、処理の中身が推測できるようにした方が読みやすい
- 処理が長すぎるメソッドは、ひと目では処理が分かりづらく読みにくい
といった基本的なことを知っているからです。
自分で開発するときにも、「後から見ても読みやすいこと」を意識して実装するようにしましょう。
「読みやすいコードとはなにか」を体系的に理解するうえで非常に参考になるのが、この『リーダブルコード』という書籍です。
エンジニアであれば誰もが耳にしたことのある有名な書籍なので、
これからエンジニアとして更に成長したい人は、ぜひ一度読んでみることをおすすめします。