プログラムを読む技術 要約

はじめに

この記事は「プログラムを読む技術」を読んでアウトプットするために要約する記事です。
プログラムを読む技術

なぜプログラムを読む技術を磨く必要があるか

これからプログラミングを学ぶ人も、現在実務に入っている人も、プログラムを読む機会は多いと思う。
プログラムを学習をする際は、本に書いてあるプログラムを読んだり、人のプログラムを読んだりなどでプログラムを読む
実務に入っている人も、実際にコードを書く際に、他の人が作成したメソッドを使用する時や、もはやコードを書くより読む方が多いと思う。比率的には7:3くらいではなかろうか。
よって、読む技術を磨けば仕事が早くなるし、また、読みやすいコードがどんなものかもわかるので、実質的に書く技術も上がるだろう。

他人プログラムが読みにくい7つの要因

他人のプログラムが読みにくい理由は以下の7つである。

1. 設計する際の考え方の違い
2. プログラム作成に使われた言語の違い
3. 関数の作り方の違い
4. 関数名、変数名の付け方の違い
5. 入力と出力の考え方の違い
6. スキルの違い

以下では個人的に気になった部分のみ記載する。

設計する際の考え方の違い

ここでいう設計とは、機能をプログラムに実装する際の設計のことだ。一般に詳細設計と言われる段階の設計のことである。設計で読みにくさが生じてしまうことの例として、どういう処理をどのような順でプログラムないに記述していくかの違いが挙げられる。

プログラムに使われた言語の違い

自分が使えない言語を使用されたらそりゃ読みづらい。それだけのこと。

関数の作り方の違い

このくらいの行数になったら関数に処理を分けようという考え方が人によってはある。
このように個人差がある考え方により、ある人によっては長すぎる、別の人から見たら短すぎるという読みづらさが発生する。また、どのような機能単位で関数を分けるかによっても読みづらさが生じるだろう。
関数に絞った話ではないが、コメントの付け方などでも読みづらさが生じる。

入力出力の考え方の違い

この本では、入力と出力に着目してプログラムを読む方法を紹介している。
例えば、じゃんけんのプログラムを考えたとして、入力(出す手)を数字(0, 1, 2)で扱うか、それとも文字列("ぐー", "ちょき", "ぱー")で扱うか、また出力(勝ち負け)を数字で扱うか、文字列で扱うかなど、人によって変わる。
このようにそれぞれの人の考え方により、入出力に違いが出て、読みづらさが生じる。

スキルの違い

書くまでもないが、読み手が初心者、書き手が経験者だとしたら読みづらい。

入力、出力を探すのがコツ

ここから、プログラムを読みやすくする考え方について記載する。

プログラムの構造は入力→処理→出力

プログラムの構造を突き詰めるとそれは入力→処理→出力に分けられる。もう少し細かく見ると、処理の中にも、入力→処理→出力の構造がある。
こういった入力→処理→出力の繰り返しでプログラムは作られており、最終的にはプログラムの中にそれぞれ入力、出力、処理がある。

プログラムの読み方

プログラムの読み方について具体的に見ていこう。プログラムには

1. 全体を把握する
2. 1行ずつ読み取る

という2つの読み方がある。
全体を把握するというのは、プログラムの目的や、プログラムを書いた人の設計や考え方を読むという読み方である。そのプログラムにはどういう機能が持たせてあって、どのように処理を進めていくのかを読んでいく。
1行ずつ読み取るというのは、文法的に各行を理解し、プログラム全体の中でどういう意味を持って書かれたコードなのかを読み取る読み方である。
どちらの読み方も必要だが、順番が重要。必ず全体の把握が先で、それを踏まえて個々のコードを分析するというのが正しい読み方。

全体を把握するコツ

「プログラムの全体を把握する」という読み方について具体的に見ていく。
全体を把握するのには以下の3つ

1. プログラムが何の目的で作られているか
2. プログラムを書いた人がどのような設計にしたか
3. プログラムのどこでどのような処理が行われているか

これらを明らかにするという目的がある。
この3点がクリアになると、プログラムの細部の意味を理解しやすくなる。
それに役に立つのが入力→処理→出力というプログラムの構成である。

どのようなプログラムにも入力があり、その入力を処理した結果、出力がある。読むプログラムが何であって、何が入力で、どういう処理をしていて、最終的な出力が何かを見つけ出すことが最初にすることである。
その次が、部分を読んでいく段階である。延滞の処理を分解して、入力→処理→出力となっているところを探し、さらに細かく処理の中身を見ていって、、、とやることで、プログラムを書いた人が考えた設計を読み取ることができる。プログラムがどのように設計されていたのかが分かれば、プログラムのどこにどのような機能を持たせているのかがわかる。特に大きいプログラムになればなるほど、細部に渡って全てを読み込むのは難しい。流用できるコードはどこか、変更しなければならないのはどの部分かなど、重点的に読み込まなければならないところをより早く的確に見極めるために、どういう設計になっているのかを見つけることが「全体を把握する」ことなのだ。

プログラム全体を把握する

プログラムを読む前にすること

プログラムをいきなり読むのではなく、その前にすることがある。それを以下に記載する。

1. ドキュメントを探す
2. プログラムを書いた人に聞く
3. コードを実行してみる
4. プログラムの目的に合わせて、実装つまり入力、出力、処理を想像する

ドキュメントを探す

プログラムに関するドキュメントを用意できると、プログラムを読む前にあらかじめその内容を把握していくことができる。具体的に特に重要なドキュメントは以下の2つ

1. 外部仕様書
2. 詳細仕様書

外部仕様書には、主にシステムの外部とのやりとりがまとめられている。例えば、システムの利用者に対して、どのような入力画面を提供するか、どういう項目の入力してもらうか、入力するときのデバイスや方法は何かなどだ。既存のシステムやWeb上のシステムなど、他のシステムと通信する場合は通信方法や通信内容などについて、外部仕様書により決められている。外部仕様書を読むことにより、プログラムの入力、処理、出力のうち、入力と出力を効率よく正確に把握することができる。何が入力で、どういう出力かがわかっていけば、実際のコードの中でどこがそれに当たるのか、見当がつけやすくなる。
一方、詳細設計書には、主にプログラムの処理の部分が書かれている。プログラムをどのように設計したか、どのようなモジュールで構成されているか、どのようなクラスを作るか、クラスの相関がどのようになっているかなど、プログラムに求められる機能をどのように実装するかについて事前に検討した結果を整理したものが詳細設計書だ。詳細設計書を読むことで、プログラム内の入力、処理、出力の構造がより具体的に把握できるほか、入力やすつ力がどの変数で扱われて処理されているかなどの情報を読み取ることができる。

実際にどこ読むの？

外部設計書の場合は、機能要件、インターフェース要件。全体を把握したい場合はシステム概要も読めるといい。
内部設計書はシステムアーキテクチャ、モジュール設計、データベース設計、インターフェース設計。
それぞれの項目で、入力、処理、出力に着目して読む。

プログラムを書いた人に聞く

そりゃそう。聞く人の時間を取ることになるので、ドキュメントでわからない部分のみ質問しよう。
つまり、先にドキュメントを読め。

実際にプログラムを実行する

これもそりゃそう。実際に動かした方がわかりやすいに決まってる。

プログラムの目的から実装をイメージする

プログラムの目的がわかっている場合は、ある程度入力、処理、出力を予想した後にプログラムを読むことで、どこをどのように読めばいいかをあらかじめ考えることができる。

プログラムを読むときにすること

プログラムを読む前にすることは「できるだけ情報を集めること」である。
そしてある程度仮説を立てて、入力、処理、出力がどのように行われているかを具体的に想定することで読みやすくなる。そしてそれを確認するために実際にプログラムを読んでいく。
プログラムを読む順番は以下の通りである。

1. メイン部を読む
2. データ構造を読む
3. 部分、部分を読み解く

まずはメイン部で、全体の処理の流れを読み、その後部分部分を読めということだ。

データ構造を読む

メイン部の分析によりプログラム全体が把握できると、プログラム全体の入力と出力がわかる。
処理を追いながらプログラムの全体を理解しようとする目線と同じように、入力から出力までの間、どのようにデータが受け渡されていくかを見るという目線もプログラムの理解に役立つ。入力も出力も、多くのプログラムでは変数として保持される。プログラムが得た入力を変数に格納し、変数という形でさまざまな処理へと受け渡され、出力に使うことを想定した変数に格納され、プログラム自体の出力になるというわけだ。このため、プログラムにはどういう変数が用意されていて、どこの処理でどのように使われているかを明らかにするのも、プログラムの把握には重要である。

まとめ

今回はプログラムを読む技術という本の中で、自分が必要に感じた部分を要約した。
他にも紹介していない部分もあるので、気になった人は手に取って読んでみてほしい。