プログラムコードの読解力の鍛え方

質問

お世話になります。

3年目のプログラマですがソース読解力が、かなり低いのが悩みです。
皆様はどのように読解力をつけていますでしょうか？

回答No.4

tachin

自分の場合は、新人教育終了後、OJTを通じて先輩のコードやたまたま請負っていたプロジェクトが、何年も続く大規模なシステムであったため、プロジェクト内容は追加仕様や変更と言った、既にあるコードを存分に見ることが出来ましたので、それで学びました。
　当時やっていた言語は、メジャーな言語でなかったことで、マニュアルもメーカのものや英文直訳したような不親切なものしかなく、当然に市販本もないため、かなり苦労しました。
　その後、何度か転職しましたが、最初に見る他人のコードが汚い、無駄が多いと参考にはならないと感じてます。その点、私は恵まれたと思ってます。　
　また、業務系やWebなど、比較的小さなシステムですと、全体仕様がよくわかりますし、画面主体でもあることで、自ずと何をしている機能かはわかるはずです。仕様を元に解析するという事は可能です（当然、無駄なコードになっている、汚いコードと言う事もわかってきます）。
　ご質問者様は、どのような分野、規模の開発をされているのでしょうか？。
　基本仕様から詳細仕様に落とされた物が、あまりにも粗雑だと、確かに最初はわかりません。それで正しいのか、他人が書いたコードを理解するのは容易で無い場合もあります。
　私の場合、かなり大規模なシステムで、画面もなく、昨今のDBを用いたものでもなかったため、一体このモジュールが、何をするためのものか？という事すら、当時も今もわかってません。それだけ、大規模になると、モジュールが詳細化され、どこで使われるのか新人だとわからないものです（当然、業務知識がないと尚更です）。
　わからないならじっくり時間かけて読み解くしかないでしょう。
　何時間かけて仕事されてますか？。
　私の３年目は、別の部署の不具合プロジェクトに借り出され、しかも数十社協業の数百人体制で、当社のリーダクラスはほとんど会議と言う有様で、私と派遣の子で解析しながら対応してました。２日に一度寝るような感じで３ヶ月続けさせられましたが、結構これで力付いた感じです。

回答No.3

hue2011

あなた、日本語で書かれたものをどう読解していますか。

たとえば労働基準法第２条２です。
「労働者及び使用者は、労働協約、就業規則及び労働契約を遵守し、誠実に各々その義務を履行しなければならない。」

日本語として美しいかどうかなんて考えませんね。ここ、いいですね。

誰かが何かをしなければいけないのです。それはまず理解できます。
じゃ、誰か、と何かは？

労働者及び使用者、が誰、です。

何をするのか。遵守したり履行したりするのです。
何々を遵守し、何々を履行するのかを見ます。

遵守するのは労働協約、就業規則、労働契約という３つです。
ここには具体的に書かれていないからどこかで規定するのだろうと考え、とりあえず意味不明のままそのコトバを覚えておきます。
履行するのは義務、です。どうもこの義務は、いま覚えたコトバに対することのようです。

さて、労働協約とは、就業規則とは、というように他の条文を見ることになります。

この1文をみただけで、労働法の全部が理解できるわけもなく、そんなことを自分に期待していませんね。

頭脳はどう動いていますか。
まず全体の構文の作りを解析していますね。
そして、具体的ではない関係があることまで認識します。
ここで枠が見えています。
枠のそれぞれの役割を具体化します。
誰が、何を、というように明確にしていきます。
どうしてもこの中では解決しないものがあったらそれはあとで解決するための箱に入れておきます。

３条以降に、労働者とは、とか賃金とは、という文が現れます。その中に、今箱にいれた用語があるはずです。
それを読むことで、不明な状態にしたあの用語はこういうことだったか、と理解できます。
そうすると、２条に書かれていたことが実体感をもった意味として現れてきます。

このように文書は読むのですよね。

この条文をみながら、ああ就業規則がわからない、とか労働契約を知らない、などとのたうちまわっていたらバカじゃないですか。
そこにあるわけないのですから。

プログラムを読むのも基本的に同じです。

簡単な例をひとつお出ししましょう。

forというひとつの語にとらわれたらもうだめでしょう。うわ、forがでてきた、どうしよう、と考えたら。
それがでてきたら繰り返し、ループに違いない。そのループは何を回しているのか、と考える読み方をしなければいけません。
最終値が何かのカウントになっているとすれば、たとえば顧客全員を見ているのだな、とか商品をチェックしているのかな、がわかります。
そうしたらforループの中に書かれている記載は何をしようとしているのか、を見るラインが得られています。
顧客を回しているのだとすれば、各自の何かのデータを見ているに決まっています。
全社の売り上げ計画のグラフをつくっているわけありません。
顧客ごとの何かのデータをチェックするなりまとめるなりしているのです。
ループの外で0にしたりしているものがないかを見ます。大体これは初期化ですから、ループの中で更新されるはずです。
その更新は何をしているのか。

そう呼んでいけば、シナリオは見えてくるのです。
どんなにブサイクなプログラムでも、読めますよ。読みにくいけど。

回答No.2

lv4u

>>皆様はどのように読解力をつけていますでしょうか？

私の場合は、米国から購入したデータベースソフトのソースや、Ｃコンパイラ、ＵｎｉｘのＣ－Ｓｈｅｌｌなどのツールを日本語対応して、別のＯＳにのせるための修正作業を通じて読解力を身につけた気がします。
その作業は、やや巨大なソースを解読する必要があって、時間はかかりましたけどね。

たとえば、１０個のソースで構成される１つのプログラムが、トータル行数で２万行のＣソースだったとして、それを時間がかかったとしても読解した経験があれば、５００～１０００行くらいのＣソースで作られたプログラムなら、「これくらい読めないことはないはず」と思えますよね？

つまりは、そこそこ巨大なソースを見つけて、それを読解してみるのが良いと思います。
ネットを探せば、Ｌｉｎｕｘのいろんなツールのソースが無償で手に入りますから、それらを読んでみるのもいいかもしれませんね。

回答No.1

chie65536（@chie65535）

ソースそのものを読むから読解力が付かない。

読むのはソースじゃなくてデータの流れだ。

データの流れを読まないから、ソースも読めない。

読むべき物を間違っているから、２年経っても「読めない」で居るんだと思う。

ソースそのものが「意味不明」であっても「Aっていうデータが入ってきたらBになって出て行く。Cっていうデータが入ってきたらCのまま出て行く」ってのが理解できれば「意味不明だったソース」が、いつの間にか「意味が理解できるソース」に変わっているから。

データの流れが読めれば「ああ、だから、ここで、こういう事をしてるのか」ってのが見えてくる。

データの流れを読まないでいると「ここでこうしてるのが意味不明」のまま、何も理解できない。