なぜ、他人の「プログラムコードが理解できない」の？

「文法的には理解できるけど、コードの意味が理解できないです」

膨大なコードじゃないです。わずか、10行程度のプログラムコードが理解できない人って少なくないようです。

あなたは大丈夫ですか？

もっとも本質的な問題

あなたの「プログラミングに対する心構え」に問題有り！です。

• 文法書など、何となくわかったつもりになっていませんか？
• 簡単なコードを書いて、結果だけで判断していませんか？
• デバッガを使ってコードの振る舞いを確認しましたか？
• プログラムコードを理解する努力を怠っていませんか？

コードが理解できない人の共通点があります。それは、なぜ自分が理解できないのか説明できないと言う点です。わかるための努力をしていない点も共通しています。

まず、初見でわからないのが普通なんです。
わかる人は、理解したいと様々な努力をする。
しかし、わからない人は、地道な努力を避け、安易に答えを求める。

文法を勉強した、ロジックを勉強した、デバッガでプログラムの振る舞いを勉強した。でも、プログラムが理解できない・・・。なぜ？

自分で考えて書いたコードも人が書いたコードも、すぐに理解できないのが普通なんです。

自分で書いたコードも、1週間も間をおけば他人のコードです。コメントがなければ尚更です。

初見のプログラムコードは、ピンとこないのが普通なんです。どんなベテランのプログラマーも同じです。

自分でピンとくるように工夫して努力しない限り、永遠にピンとこないのです。つまり、簡単に理解できる方法は存在しないのです。

非常に残念ですが、これが現実です。

単純なロジックなら、コメントが有効ですが、ちょっと複雑なコードになるとコメントだけでは不十分なのです。

もし、この先で説明するシミュレーションなんかできない！という事なら、きれいさっぱりプログラミングと縁を切りましょう。

非常に面倒なのです。アルゴリズムだから面倒だということではありません。プログラム作りとは、こういう面倒なことをしないといけないのだと理解してもらうためにアルゴリズムで解説しただけです。

逆に「シミュレーション作業を行えば必ず理解できる」ということです。

理解するための努力を惜しまない人だけが、プログラミングすることを許されるのです。本当の努力をしないで、本を読んで解ったつもりの人には永遠に理解できないかも知れません。

シミュレーションとは？

シミュレーションとは、プログラムにデータを与え、コンピュータが実行するであろう事を机上で擬似的に人間が行う作業のことをいう。

コードを読みながら行う方法が一般的だが、初心者の場合はフローチャートを書いて、フローチャートで検証する方法が望ましい。

ピンとくるための考え方と方法
『プログラムは動的な命令の集まり』

プログラムは、静的な文章じゃなくて、動的な命令の集まりだと言うことです。変数値は状況に応じて変化するのです。変数値によって処理も変わるのです。プログラマーは、コードの実行と変数値の変化を意識してコンピュータと全く同じ手順でシミュレーションしなければなりません。

検証のためのデータを用意して、変数の変化あるいは変数値を計算しながら、コード通りの振る舞いを一通りシミュレーションして、処理の流れや仕組みや考え方を理解する努力をしなければなりません。

特に、繰り返し文と判定文を組合せたコード群は要注意です。

丁寧に、瞬間瞬間、どういう状態になっているのかをつぶさに見ていく必要があります。

複雑な繰り返し処理などは、Excelなどを使って表にまとめると、繰り返し回数毎の変化がよくわかります。

例題を使ってシミュレーションする

例えば、数値データを検索する「二分探索」というアルゴリズムがあります。

「二分探索」の前提条件

2個以上の数値が昇順（小さい値から大きい値へ順に並んでいる）にセットされている配列を対象とします。

二分探索の基本概念は、検索対象の両端の中点の値との比較を繰り返すことで対象値が存在していれば、配列要素番号を取得。見つからなければ、なしを取得する方法です。

サンプルコード（C#）とシミュレーション結果のまとめ

このプログラムは、配列を横並びにしたイメージで変数名を命名しています。シミュレーションする場合は、手作業で検証できる程度のデータ量で行います。

ループ毎に変数の値や条件判定を表にまとめてみます。念のために書きますが、自分で納得できる方法で整理すればいいのです。下表は一例です。

机上で表を作り、デバッガでその通りの振る舞いになるかどうかを検証すればいいのです。

ロジックの検証をフローチャートで行う

フローチャートの目的は、図式することが目的ではありません。ロジックやアルゴリズムを机上で検証（シミュレーション）することが目的です。どうも、誤解している人が少なくないため、ここに付記しておきます。

実際のデータを使って検証する

実際のデータを使って、手動デバッグでチェックしてもいいですが、もっと簡単な方法があります。

それは、手動でチェックする変数値をコンソールやデバッガの出力ウィンドウに表示する方法です。

データ量が多い場合は、出力結果をコピーしてExcelに貼り付けて整理するとわかりやすくなります。

変数名を日本語に置き換えてみる

おすすめはしませんが、変数名を日本語に置き換えてみるのも一つの工夫です。

「コードが理解できない」のは、あなたの怠慢！？

なぜ、コードが理解できないのか、その理由がわかりましたか？

今まで何を勉強してきたの？と言われても返す言葉もないでしょう。

当塾でも、言語基礎、ロジック、デバッグ、問題の解き方を基本にした解説とトレーニングを行っていますが、どうしてもピンとこない人がいます。

ソフトウェアは、これまでとは異なる世界ですから、指摘されない限りなかなか気が付かないんですよね。あるいは、何となく気が付いているけど、面倒だからやらないという気持ちがあるのでしょうか？

だけど、こういった地道な努力を怠ると、何処かで必ず破綻するんです。そして、どうすればいいのかわからなくなるのです。

プログラミングは、コードを暗記するものではなくて、問題を分析し、ロジックを考え、実装して要求通りの結果になるかを検証する総合力が必要です。コードを眺めるのではなく、シミュレーションしたり実際に動作させて、途中経過をつぶさに調査し結果をチェックして理解する努力が不可欠なのです。