プログラムの書き方

ITサポーターTsuchidaの土田です。プログラムの読み方を書くときに、読み方と書き方を両方書こうと思ったのですが、読み方と書き方って一緒にかけないと思い、分けて書くことにしました。

プログラムの読み方って、完成して出来上がっているプログラムを読むので、正しいプログラムを読んでいるようなものです。作家の作った小説を読んでいるようなものです。私も若い頃、人の書いたプログラムを読みましたが、読みやすさの違いはありましたが、どのプログラムも動作するプログラムなのです。

プログラムを書くということは、読むこと同じで上から下に書けばいいわけではありません。上から下に書くという感覚は完成しているプログラムを写す感覚に近いので、新しいプログラムを書けません。こういう感覚の人は、プログラムを暗記して覚えようとする傾向にあり、暗記ではプログラミングを身につけることはできません。

ではどうやってプログラムを書いているかというと、全体の流れのあらすじを描きます。まずはラフにあらすじを描き、徐々にあらすじを細かく描くようにします。あらすじがある程度出来上がったら、抽象化→分解→組立でコードを書きます。実はあらすじと抽象化ってプログラム言語にあまり関係なく、どのプログラム言語にも共通しています。プログラム言語の制約でできないこともありますが、基本的な考え方は一緒です。

ExcelVBAであらすじを描くときに最も障害になるのが、操作をそのままあらすじにしようとすることです。操作をそのままあらすじにすると、マクロ記録になってしまうのです。マクロ記録で記録したものだけでは、実用的なマクロになりません。操作があらすじにならない理由は、操作では抽象化ができないからです。操作というのは実際のデータをみて、そのデータに合わせているからです。例えば範囲選択という操作は、手動で人が判断して行うもので、Excelが判断するものではありません。VBAで記述したマクロを実行する際に、Excelに範囲選択を同様な指示を与えることをします。どのようにすれば範囲選択と同じことができるかという考え方が抽象化なのです。

よくある操作として、表全体をコピーして、別のシートに貼り付けや数式は値貼り付けをして不要な列を削除し、必要な行を抽出するためにフィルタをかけて、フィルタで抽出した行をコピーして別なシートに貼り付けして、加工に必要なデータを抜き出す処理があります。あらすじをそのまま操作で考えてしまうと、この操作をそのままVBAで記述しようとするかなり難しいです。私だったら音を上げてしまいます。

抽象化を意識したあらすじとなると、操作は関係なく元のシートと出来上がりのシートから、どうやれば出来上がりのシートになるか考えます。そこで、1行ごとにその行は対象かは対象外かを判断します。対象の行のうちどの列かを決めます。必要な入力シートの列を出力シートの列に値を代入します。この入力シートをデータの最終行まで繰り返します。こうすれば結果として手動でコピーペーストした結果と同じになります。この場合においても、タイトル行が1行なのかを確認したり、入力シートの行の読み飛ばしがあるので、入力シートの行数と出力シートの行数が違うので、それぞれの行数をカウントする変数が必要だったりします。まあこれは、抽象化ではなく分解の段階になりますが・・・

あらすじと抽象化ができれば、あとは分解して組み立てて、実行して結果が正しくなるまで、分解と組み立ての見直します。分解と組み立ての見直しの作業がデバッグなのです。VBAで分解と組み立ての時に、繰り返しやプロシージャを呼び出すブロックを意識することです。

私も新人の頃プログラム作成でコンパイルエラーができるのが嫌でした。コンパイルエラーが無くなっても、実行エラーがでて、エラーつぶしに時間を費やしていました。でも慣れてくるとコンパイルエラーや実行エラーって苦にならないのです。何故かというと、イージーなミスって、どんなに慣れてもついやってしまうのです。むしろ正常に実行できた後に正しい結果になっているかどうかの確認が重要なのです。VBAで自動化するのに正しい結果にならなくては意味がないのです。コンパイルエラーや実行エラーは、ワープロソフトのスペルチェックやグラマーチェックみたいなもので、自分の間違いを教えてくれる機能だと思っています。

ちなみに私が今まで出会った人で、プログラマーとしてできるなと思った人って几帳面な人はあまりいなくて、どちらかというと大雑把な人の方が多かったです。大雑把ってがさつみたいな印象ですが、どうすれば楽をできるか考えているのです。毎回同じことって面倒くさいと感じ、どうやれば面倒くさくないかを考えます。几帳面な人は毎回同じことをきっちりやるタイプなので、きっちりやることが合理的とは相反することになりがちです。もちろん几帳面な人がきっちり分類してくれるとありがたいこともあるので、大雑把な人の楽をする考え方と組み合わせると最強なのかもしれません。

いろいろ書いてしまいましたが、プログラムを実際にコードを書いてみないとスキルが身に付きません。でもプログラムを実際書いてみるとうまくいかないと挫折しますよね。挫折しそうになるときは質問したくなります。そんな質問したいときはぜひ掲示板をご利用ください。

https://note.com/it_supo_tsuchi/circle/boards/7fcf9b7cba2d/posts/304e601878bc