初心者のソースコードの読み方

Question

プログラミングの仕事を始めて半年くらいの人にソースコードの読み方を聞かれたのですが、どう答えたらいいでしょうか？
とりあえず以下は私が普段から意識してることなのですが、他にもいい読み方があれば教えてください。
（初心者に限らずのお話しだと思いますが。）

よろしくお願いします。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

・その変数に何がはいっているかデバッグする
それがmodelのインスタンスの配列なのか、IDの配列なのかなどを見る
また自分の想定通りの値が入っているかを都度確認する

・そのメソッドがどこに定義されているのか探す
またはどこから呼ばれているのかを探す
そのメソッドの返り値はなにかも意識しておく

・変数名やメソッド名から機能などを想像する
コードに記載されてるコメントからも同様に想像する
たまに全然違う名前の場合があるので注意

・git blameでコードのgitログを見る
何故その変更をしているかをコミットメッセージから知る
またチケット番号と紐づいている場合はそこから確認する

・複雑なコードは最初は細部を読まない
見当違いの場所を読んで時間を消費するのはよくないので
問題の切り分けが出来て読む必要が出てきてから詳しく読む

Answer 1

たとえば、幸か不幸か Apache HTTP Server のソースコードを読むことになったとします。
（初心者にそんなシナリオあるか、とも思うが、あるかもしれないw）

1.読む前に、読む目的を定めておく。

目的もなく httpd 本体のコードを展開して読み始めたところで、
「なーんかいっぱいファイルあるなー、いっぱいコードかいてるなー」
と死んだ魚の眼でテキストを延々スクロールするだけで終わります。

なにを知りたくてそのコードを探索するのか。ゴールははっきりしておきましょう。

「すべてを知りたいから写経のために全部読んで書くよ」
…無茶ですが、まぁ本気でそう考えているならそれも目的です。

2.読む前に、それが何をするものなのか理解しておく。

ApacheがWebサーバであることは誰でも知ってることですが、
じゃあWebサーバってそもそもなにするのか？とか、
もうちょっと潜ってApache のモジュールってどうやって設定しているか？とか、
外部仕様を正確に理解していることは、そのコードを読む上で非常に役に立ちます。

Comments

[momon-ga]

> 読む前に、読む目的を定めておく。
これ大事。目的が調査なのか学習なのか、何がわかればソースリーディングが終わったことになるのか、
ソースがいっぱいある時に何を読まなくていいのか判断する材料にもなります。

Answer 2

こんにちは

その人のレベル感がわからないので、学び始めたばかり、くらいの人を対象に書きますね

初心者の方は、言語の標準関数などの基本的な知識が浅いため、
細部の理解に時間が取られて全体を見失う傾向が強いかと思います
ある程度の経験があれば、それこそ初めて扱う言語でも何となく読み進めることができる人も多いかもしれませんが

僕としては
全体から細部に入る方が何事も理解しやすいかと思います

まずそのコード(クラスやメソッド)が何をしているか、何を目的としたものかを把握してから
実装の詳細を理解していくとよいのではないでしょうか

このメソッドは「とある目的」を達成するためのメソッドである→そのため、「ある標準関数」や「あることを達成するクラス」を用いてこのような実装をしている

というような感じです(我ながらざっくりし過ぎですが)

初心者にとってのコードリーディングは、勝手がわかるまではよくわからない英文のような文字の羅列でしかないので、
暗闇の中をあてどもなく彷徨うようなものだと思います
なので、最終的な目的地を理解してから進めるようにすると、心理的にもよいかな、と

もちろん、細部を理解してから少しずつマクロな視点でコードを見ていけるようにするのもよいですが
上手く設計されたクラスやメソッドは、一度に複数のことをせず、一つのことをうまくこなすように設計されていることが多いので
早めに良い設計感覚を養うためにも有用かと思います

まあ、良い設計がなされたコードをリーディングの対象にしないと、頭が混乱しちゃうかもしれませんが...

Answer 3

ソースコード読んだら負けかなと思っています。

• リファレンスマニュアル、ドキュメント
• 設計関連の文書・資料

自然言語で書かれた素晴らしいものがたくさんあるはずなので、まずはそちらを読みましょう。

そういったものがあまり頼れないとき、そういったもので解決しないときは、しょうがないのでコードを読みます。それでもコメントや識別子の命名を重視して、まずはできるだけ意味的に解釈してみます。

コメント皆無、変数名適当……というケースでは、仕方ありません。他にどうしようもないので、コードロジックを見ていきましょう。

---

読むのは面倒くさいので、できればやりたくないことの筆頭です。できるだけやらないで済ませる方法を考えます。

初心者だと読解力不足で捗らないということも多々あるでしょうし、よほどの必要性に迫られていなければ「コード読むのは、もう少し上達してからでいいよ」なのでは。

Answer 4

昔、読んだ(正確には見たか?) Unixソースは汚かった。
MS さんのは、時代時代によって書き方が変わっている。
これを全て追跡するのは大変ですね。

特定のターゲットがあれば、別ですが、単に読みたいだけってのは、何も残らなかった気がする。

---

hayataka2049さんにコメントのつもりで書いていたのですが、回答に書いていました。
申し訳ありません。

仕方ないので、追記。
何のためにソースを読むのか、目的を明確にしてから、読むべきだと思います。
書き方を学びたいのか、ソースの設計思想を知りたいのか?
細かなテクニックを初心者が人のコードから学ぶのは、難しいと思います。

Comments

[hayataka2049]

今更ですが、質問文を読み返してみて、読まないと仕事にならないみたいなパターンの気が薄々しています
＞・複雑なコードは最初は細部を読まない
の記述を見ると、debugやっているような雰囲気・・・

Answer 5

私個人的な意見で一部分なものですが、コーディングの際に名前の決め方のルールがあれば、
それを教えてあげるだけでも読みやすさ・理解のしやすさにつながるかと思います。

また、初心の頃はコードソースを読むだけでは人の話を聞き流すくらいしかないと思います。
英語を勉強する時と同じように、実際にクラスを使う場面に直面して、
わからないことがあればその都度、調べるようにしなければ、連れて来るメソッドの存在も
知ることができないかと思います。

Answer 6

いろいろあると思いますが、ぱっと思いついたものを。。

(1) どのレイヤー向けに書かれている関数かを意識する

基本的には関数を1つのまとまりとして読むと思いますが、その関数がどのレイヤーのものかを意識します。レイヤーというのは例えば、業務処理（業務ロジック）、その中の小さな業務処理、業務共通の汎用的な処理（文字列処理や、値チェック処理）、ミドルウェアやプラットフォームに対する処理、DBに対する業務的でない処理、関連システムに対する処理、などが考えられるかと。ここらへん意識して書いてあると読みやすいんです。

だいたいは、業務処理を表す関数の中にさらに細分化された業務処理を行う関数や、汎用的な処理を行う関数があり、さらにその中にコンピューターの都合的な処理があります。レイヤーが人の考えや手続き的な処理から、コンピューターの都合的なものへと下がっていくので、それを意識しするといいかなと。

自分の関心がどこに向いているかを忘れないためにも、いいかと思ってます

(2) 自分で同じようなシステムを構築することを意識して読む

構築まではいかなくとも、アプリの画面を追加するつもりで読むなどでもよいです。

これをやろうとすると、(1)のような読み方になると思います。
初心者が陥りがちな言語の文法・構文に終始してしまうといったことを避けられるかと思います。

結局は、やりたい何かを実現するためのプログラミングですので、
その実現方法も合わせて学ぶ必要があるかなーと。

(3) 動機付け

実際構築してみる。
コード以前にまず環境を整える段階で奮闘することになりますが。。。ｗ

(4) 読みづらいコードへの対策

資料があったり、綺麗にまとまっているコードだといいのですが、そうでない場合は初心者かどうかにかかわらず読み辛い場合もあるかと思います。そういった場合は、どう読めば読みやすいか考えるよう気を付けています。

たとえば資料がなく、やっていることがごちゃごちゃしていたり、コードが長いかったりする場合には、とりあえず印刷します。やっていることを部分部分要約する感じでメモを取ったり、わかりやすいようブロック分けしたりします。
ホッチキス止めはしません、ばらせるようにクリップです。
また、紙で奮闘すると眠くならなかったりします。

Answer 7

質問者さんが意識していることや@daisuke7さんが仰っているように「目的をもってソースを追う」ということは私も大切だと思います。

他の方が書かれていないこととしては、「ノートに絵を描く」のが個人的に有効だと思っています。何かをモデル化しているのならそのモデルを絵に描いてみたり、プロジェクトのファイル群がどういうファイルなのか機能ごとに箇条書きにしてみたり、ファイルの依存関係が複雑ならば清書したり、常に意識しないといけない恐ろしいグローバル変数があればそれが読み書きされるタイミングの関係図を書いたりといった感じです。

自分の担当箇所がどのようなときに実行され、どこのプログラムを経由して実行され、何を返し、どこへ処理が返っていくのか、というようなことは理解する必要があります。そういったことをノートに絵を描きます。