ソースコードの追い方、読み方の方法やコツをまとめておく

ソーソコードの追い方読み方がまるでわからない。

基本的なことを含めほとんどプログラム知識がないのに、それでもソースコードを読んで改修などをしないといけない……らしい。

自分のような知識なしの人間がどうやって追っていきソースコードを効率よく読み解けばいいのか、その方法を調べたり試行錯誤したことをまとめていこうと思います

ソースコードを読めなくて困っている状況

私は右も左もプログラミングのことをわかっていない人間です。
「ソースコードを読んで改修をして」と言われると、そこで試合終了してしまう人間です。

思考できない自分の頭が悪いという絶望。
わからずに時間ばかりが進んでいく絶望。
ドキュメントの場所さえわからない絶望。
誰も教えてくれる人がいないという絶望。

絶望だらけのそんな状況を変えられたらなということで、的を外したことを書きまくっていても、とにかくこの記事を書いておこうと思った次第です。

 

ソースコードを読む上での心構え

まず、ソースコードを読むうえで、以下のことは大前提として常に意識しておくようにするように心掛ける。

自分にとって必要な部分に集中して読むようにする。
(完璧にすべてを細かく読もうとはしない。必要に迫られたら、そのときに読めばいい)

自分の携わっているシステム、部分の役割や流れを把握しておく。

そのプロジェクトでの書き方の決まりがあればそれを頭の片隅に意識しておく。

そのソースコードを書いた人が何を思いながら書いたのか想像しながら読む。

楽しみながら読む。

そのソースコードの行き着く先、役割はなにか。
(なんのためのソースコードなのか。扱うデータ(構造)と処理フローを意識する)

 

ソースコードの解析方法の分類

ソースコードを読んで追っていく方法は大きく分けて2種類に分かれる。

動的にソースコードを追う方法

デバッガなどを使って実行時の動きを追う方法。

 

静的にソースコードを追う方法

ソースコードそれ自体を読んで追う方法。

 

ソースコードを追う手順

できることなら、ソースコードを読むときの手順は以下がよい。

動的にソースコードを追う方法 → 静的にソースコードを追う方法

静的な解析は、あくまでプログラムの動作を予想することになる。
対して、動的な解析で見るのはプログラムの動作の事実。

プログラムの動きがわからない状況なら、まずは実際の動きの事実を見ておいたほうが、当然にコード読解の予想の方向付けがしやすいので、速く正確にできる。

 

ソースを追うときに起こりうる問題

 

関数やクラスなんかが多くなってくると、それぞれの部分部分では読めても、全体としてどんなことをするプログラムなのかが把握できない。

コードを上から読むと、関数などを読むことであちこちに飛び回ることになって頭が混乱する。

どの行を読んでいたのか、あるいは、なんのために読んでいたのか忘れる。

読んだはいいけれど、処理するデータのイメージが湧かない。

このつらい状態が続くと……

  • ボーっとしてしまう
  • 暇になる
  • 眠ってしまう
  • 泣きたくなる

上記のようになります。

こういった事態をどうにかするための対策方法として、ソースコードを読むときは以下のことをするようにする。

なぜソースコードがわからないのか把握する

「あー、読んでもソースコードがわからない。頭に入ってこない」みたいな状態になったときは、まず、なぜソースコードがわかないのかを把握しましょう。

コードリーディングには段階があります。たぶん。

  • 文法
  • 概念・フレームワーク
  • 暗黙の作法(ルール)
  • 業務知識・担当機能への理解
  • 理解はできるけど記憶できない

どの部分でつまずいているのか把握して、それを補うように下記のことをやってみればいいんじゃないでしょうか。

静的なソースコードの読み方

状況によって最適な方法は変わってくるのかと思いますが、今、調べて出てきた方法を書いておきます。

メモを取る

フローチャート、クラス関係図、関数呼び出し関係図、データ構造図、コードの行番号とその該当処理など、とにかく自分が必要だと思ったことについては簡潔にメモを取っておくようにする。

追記:やはりメモを取ることは重要だと思いました。

私のようなショボイ奴だと、興味のないコードを見ているときや集中していないときは眺めているだけだと頭がボーッとして頭に入ってこない。

また、なにかで作業が中断したときに内容を思い出せなくなるなんて事態も防げる。

さらには、実装完了してから1か月後とかにプロジェクトマネージャーから、内容を詳しく教えてとか言われても、忘れてしまっていてすぐに答えられないなんて事態も防げる。

読解レベルが上がるまでは、時間があればたとえそれに関する設計書がすでにあったとしても、自分の手で自分がわかりやすいように軽くでもメモを取っておく。理解しやすくなるし記憶にも残りやすい。

ツールのショートカットを使って読む

IDEやテキストエディタなど、ソースコードを読むときに自分が使っているツールのショートカットは使えるようにしておく。知っているかどうかで効率が違ってくる

ドキュメントを読む

仕様書や設計書、コード規約など、ソースコードを読むときに役に立つ資料は読む。

ディレクトリ構造を読む

どういう方針でディレクトリが分割されているのかを見て把握する。
それぞれのモジュールがどういう関係にあるのか確かめる。
そのプログラムがどのように分割され組み立てられ作られているのか概要を知る。

ファイル構成を読む

ファイル名も含め、ファイルの中に入っている関数(名)も合わせて、どういう方針でファイルが分割されているのか見る。 

システムの各機能の流れを書いてみる

自分が調べたい箇所に関係するシステムの全体の流れについて、図なりにして書いてみる

略語の調査

わかりにくい略語があればリストアップしておいて早めに調べる。
英語だと単語の頭文字をとったり、母音をなくすとかが多い。
また、対象プログラムの分野で有名な略語は説明なしで使われている。

関数の呼び出し関係を把握する・関数を読む

関数同士がどのようにつながっているのかを把握する。
関数の動作、内容を理解する。

データ構造を知る

プログラムは、あくまでデータを処理するためにある。(らしい)
なので、どんなデータが入出力されるのか、どう変化していくのかに着目しておくようにする。

Javaなどオブジェクト指向言語のソースコードの読み方

変数(≒オブジェクト)のスコープ(可視範囲)を意識すること。
オブジェクト指向言語のコードは「上から下に」読む物ではない。(らしい)

私はコードの一行一行を読むときは「上から下に」読むのですが、処理単位で読むときは「多方向に」関係を読むイメージをしています。

(たしか)オブジェクトは関連した処理とデータをまとめた存在であり、オブジェクト指向言語は各オブジェクト同士の相互影響で成り立つ世界です。

日本語のような自然言語みたいに、上から下のように順々に読んでいくものだという認識がおかしくて(最初の頃はこの認識だった)、ネットワークのように張り巡らせた状態の言語だと思って読むのがラクです。

クラスの設計パターンやフレームワークの設計パターンをしっておく

こういう優れた、よく使わられる定石や公式といったものを知識として蓄えておくようにしていく。

動的なソースコードの読み方

動的にソースコードを解析してくれるデバッガツールを使いましょう。

プログラムを動かしてみる

実際に動かしてみて、どんな動きをするのか見てみる。

メジャーなプログラミング言語なら、IDEなどの開発環境には、たいていはデバック実行・ステップ実行ができるようになっていると思います。

デバッグツールの使い方を知る

デバッグツールの使い方を最低限知っておくとよいです。

極端に言うと、開発ツールの機能のうち、最も初心者が知るべき機能だと思います。

また、極端に言うと、ほとんど文法を知らないプログラミング言語で、フレームワーク知識のない状態でも、一行一行の処理をデバッグで止めて、その都度データの状態を確認することができるなら……

朝から晩までひたすらコードをデバッグし続ければ、どのような記述のときに、どんな処理がされるのか、ある程度は推測できるようになると思います。
(知らないプログラミング言語を読まないといけない状況になったら実感できるかと)

なのでデバッグは必須知識です。
デバッグはGoogle検索と並ぶプログラミングの先生です。

好きに操作して動かしてみる(推測の確認)

デバッグをするときは、「ある処理(行)のときに・データ状態はこうなっているはず」という自分の推測を確かめる、仮説検証の行為だと思っています。

自分の推測と実際の処理動作が正しいのかどうか。
推測と実際のズレはどこにあるのか。

それを考えながらやっていくのがオススメです。

処理の途中で値を変えてみたら、動作にどんな影響を与えるのかを見ながら動かしていくとか。(デバッグ中に値を変えられる機能です)

自分の着目したタイミングでのみコードを見たいから、条件付けして止めてみたり。(特定の条件のときのみ処理を止める機能です)

詳しくないですけど、フィルターをかけてみたり、REPLで確認したり、インスペクトしたり、監視したり。。。

自分の開発環境でできるデバッグ機能を使って、好きに操作していきましょう。

ソースコードを読むということ

ソースコードを読むということは、誰にとっても瞬きでできるようなことではなく、たぶん誰にとっても多かれ少なかれ手間がかかるものなのだなと感じました。

現時点で軽く調べたことを慌てて書いてしまっただけなので、この記事は勉強用のくせにまとまっていなし、レイアウトもかなり読みにくいですが、ひとまず直近はこの記事で書いた内容でソースコードを読み解けるのかどうかを試してみようと思います。

そして、ソースコードを読むに当たって助けとなる方法の情報があれば、随時書き加えていけたらなと思います。

1年後の追記

この記事を書いてから、1年ほど経って見返してみると、見にくいしまとまっていないけれど、書いてあること自体はそんなに的は外していないんじゃないかなと思いました。

ソースコードを読解するのに知っておきたい前提知識などで勉強したり、少し開発経験を積んだあとに見返してみると、「ああ、なるほど、これは意識したい」と思えることが書いてありました。

またいずれ、徐々にきちんとまとめ直そうと思います。

(メソッド呼び出しの流れを追っていると、途中でインターフェースに行き着いてしまって、その先の実装コードが気になってモヤモヤはするけど、どうすればいいのかわからないなんてときにどうするといいのか、など具体的なこともそのうち書き加えていきたいです……少し具体的な内容を書きました。→ コードリーディングやコーディングの効率を爆上げしてくれる機能のまとめ

1年半後の追記

この記事を読んでいる人には早いのかもしれませんが、フリーランスエンジニアのエージェント会社のサービスをまとめて比較するの記事の最後の部分は読んでおくと良いかもしれません。

また、エンジニアの人月単価はどのように決まるのか単価収入を上げる方法については知っておいて損はないと思います。勉強のモチベーションにつながります。

振り返って見ると、私がもっと早くに意識しておくべきことだったと思うことです。コードリーディングやコーディングといった開発スキルだけでなく、他にもエンジニアとして知っておくべきコツはあるのではないかという内容です。

タイトルとURLをコピーしました