ダチョウの首のように長いコードを書くのはやめて、プログラムは小さく分割しよう
プログラムは自分で作るより他人のを解読するほうが難しい
他人が書いたプログラムコードを読むのって難しくありませんか? 先日、昔誰かが作ったエクセルVBAのプログラムを使って、うまく動作しなかったので修正することになりました。ところがそのプログラムが長くて何をやっているのか解読するのに苦労しました。これだと自分で1から作るほうが楽だったかもしれません。
処理が難しくても、その部分で何をしようとしているのかが分かれば解読できます。でも、長いコードでこの部分で何のために何をしたいのかがパッと見でわからないと読み進めるのが苦痛になります。長~いコードはかんべんしてほしい。サブルーチン化やモジュール化するなどして短くしてほしいと思います。
プログラムは小さく分割しよう
例えば、営業担当者ごとに売り上げの表があるとします。上島さんの売上表、寺門さんの売上表、肥後さんの売上表、などといった具合に。これをかき集めてから、商品ごとの売り上げ表を作るとします。商品Aの売上表、商品Bの売上表、商品Cの売上表、など。
この場合、まず上島さんの売上表、寺門さんの売上表、肥後さんの売上表のデータをかき集めて一つの大きな表を作ります。私だったらここで処理を止めます。そしてもう一つのプログラムを作って、この大きな表を商品ごとの表に分割します。それほど複雑ではないエクセルVBAのプログラムでも、私は全部の処理を一度にやらずに2つに分割するようにしています。
プログラムを小さく分けるメリット
十分ご存知のかたが多いとは思いますが、プログラムを小さく分けることには、次の3つのメリットがあると私は思っています。
(1) 間違いに気づきやすい
大きな表ができた段階で、その内容を確認できます。プログラムにバグがあった場合やデータに不備があった場合はここで気づけます。特に最初のうちは、1つめのプログラムで作った中間データの表が正しくできていることを確認するまで2つめのプログラムの開始ボタンを押してはいけません。「絶対に押すなよ!」
(2) 例外データにも対応しやすい
入力されるデータが必ず正しいとは限りません。たとえば上島さんの表だけ別の列が追加されていた。そんな「聞いてないよ~」という状況があったとしても、この時点で気づいてデータを修正してしまえばいいのです。全部処理してから誤ったデータを探すよりも効率的です。
(3) プログラムを修正しやすい
あとになってから、仕様変更で編集プログラムを修正する必要が出てきたとします。そんなとき、分けてあったほうがここだけ直せばいいと分かりやすいのです。作った人がいなくなって、担当がクルリンパと替わっていても修正箇所がすぐ分かるのです。
私、あべっかんは、このような方針でエクセルでプログラムを作る方法を教えています。エクセルプログラミングVBA入門勉強会は初心者歓迎です。やってみませんか。
「俺がやる」
「俺がやる」
「じゃあ、俺も...」
どうぞ、どうぞ。みなさんお越しください。あべっかんでした。詳しくはこちら。
コメント
仲澤@失業者
職業なのですっかり慣れましたが、他人はおろか自分のコードですら
時間が経つと読むのにヒマがかかります。
自分は「手順をわかりやすくする」ためにコードを小分けにし、
「意味をわかりやすくするする」ために命名とコメントに十分な手間をかけてます。
そして「全体構造をわかりやすくする」ために仕様を書きます。
ちゃとらん
相変わらず、キレがあって、いいですね。
なぜ、ダチョウ??? と思いましたが、「つかみはOK」でした。