[ 初めての方へ | 一覧(最新更新順) | 全文検索 | 過去ログ ]
『マクロファイルの作成について』（しのみや）
マクロの記録やインターネットの情報、 こういった質問サイトで教えて頂いて、 マクロファイルを作っています。
こんなの作れないか、と思いつき できるか調べる（質問させてもらう） 試してみる できた（できなかったら、調べなおす） の繰り返しで作ってきました。
その場その場で調べて対応するという状況です。
自分で動かしている分には良いのですが、 人にお渡しするや、期限付きで作成しないといけない場合、 汎用性を持たせる、人に作り方を説明をする、となった場合、 作りながら考えて、その場で思いついたエラー処理をしていくような状態ではなぁ…と 思うようになりました。
もわっとした質問で申し訳ないのですが、 ここから次の一歩をどのようにしたらよいかわからずにいます。
ここのエクセルの学校では１問１答えだけではなく 幅広い知識から回答いただくことが多くあり そういった方々はいろんな経験をされてきたのだろうなぁと感じています。
うまく書けませんが、この状態からどんなふうに進まれたか…等アドバイス頂けると助かります。
＜ 使用 Excel：Excel2010、使用 OS：Windows10 ＞
私の場合は質問に答える かな・・・ 毎回じゃないですけど、回答するときは質問者より調べてる自信ありますよ。 （稲葉） 2019/03/07(木) 12:36
こんな事しているので、ソースコードなんて恥ずかしくて人に見せられません。
「なんでここはグローバル変数なの？」「byrefにしないでbyvalにした理由は？」などと聞かれると恥ずかしい。
なので、極力人に見せないで済む方向で進めています。
ソースコード作成で気を使っているのは失敗談に基づくものです。
例えば、条件分岐で条件には"1"か"0"が入力されるので、１だったらこう、違ったらこう、の式でしたが、
あるとき、読み込みデータから条件に"a"が入力されました。変数をintegerからvaliantに変える事でエラーは出なくなりましたが、処理が0だった時のものになりました。このため、条件にはすべて記述し、1だったらこう、0だったらこう、どちらでもなかったらこう、と記述するようにしました。
また、積極的にコメントを多く入れました。
ある程度ステップ数の多いプログラムになると、あとから変更したい場合や、エラー箇所と違う部分を修正したい場合にその箇所を探すのが大変な為です。
日本語で書かれたコメントを探すのは楽です。検索機能でも探しやすいですし、関数そのものに、どういう事をしたい関数なのかなどの記述をしておけば、汎用性を高めるための修正も楽ですし、修正箇所もわかりやすいです。
どうしても人に説明したい場合は、コメントだけを拾っていって、フローチャート化したものを見せます。
フローチャート化は手間が多いですけど、ソースそのものよりは相手にわかりやすいし、
汚いソースを見せずに済みますので。
自分自身でミスを見つける事もありますよ。（ジャンプ先が無いじゃん！とかジャンプ先は何もしてないじゃん！ここにジャンプしちゃダメでしょ！など。）
（通りすがりのおっさん） 2019/03/07(木) 13:10
私自身、こういうテキストファイルを個人ノウハウとして残していますが、Excel関係で500件くらいありますね。 使うときは日本語部分でも命令でも良いのでファイル検索（grep）すれば、関係するもの全てを一瞬で探し出せます。
こうやってファイルにしておくと、一度見たことのある内容はすべて実現できるようになります。 後になってコードの意味が理解できたときは説明を追記すれば良いし、理解が深まりますよ。
（私はたまにコーディングを料理に例えるのですが、これはレシピをメモとして残しておく事に相当すると思います）
（???） 2019/03/07(木) 13:48
皆さんご親切に回答ありがとうございます。
最初に自力で作ったひどいものとか…突っ込みどころ満載ですね…
私は心配事を事前に考えて埋めるような、そんな感じなのですが、 作りながら考えているのは同じだなぁと思いました。
???さんがおっしゃる料理のように材料を用意して、 全部切ってから始められるといいのですが、 その場その場で「あっこれ必要だ」「あっこれも？えっ買ってない？」という 感じで 効率としてはかなり悪いかなと思います。
そういう意味では自由度が高くておもしろいのですが…
頂いたアドバイスで、コメント管理・フローチャート化がまず１歩かなと 思いましたので始めてみようと思います。
また教えてください。 （しのみや） 2019/03/07(木) 14:11
＞ 自分で動かしている分には良いのですが、
作り手と使い手が同じ人なんですから、当然ですね。 要件は明確だし、実力相応のものを作って操作ミスしないように使えばいいから。
別々だとそうは行かないです。 作り手が考えていなかった要件があったり、想像もしないような使い方をされたりでトラブル発生です。
使い方が悪いというべきか、要求が高すぎるというべきか・・立場で違ってきます。 相手が偉いか、金を払っているなら、文句はどんどん出て来ます。
どの程度の規模の話なのか分かりませんが、個人で作れるシステムなんて高が知れています。 自分で1週間は使い倒して、バグや不満点を解消してから渡す。 (作り手が不満と思うようなことは、大抵ユーザーから追加要求される）
仕様書なんて作らないと思いますが、使い方マニュアルはチャンと書いて渡す。 マニュアルがチャンと書けない様では、プログラムの作りも怪しい。
（半平太） 2019/03/07(木) 14:19
???さんが言った料理って、 ＞料理のように材料を用意して、 ＞全部切ってから始められる 本当にこのような意味なんですか？
私は食材と下ごしらえの方法を書き留めて、必要なときに 見返せって意味だと思ったのですが、、、 （稲葉） 2019/03/07(木) 22:02
>本当にこのような意味なんですか？
???さんのおっしゃったこと = 全部切ってから始めるではないですし、 そのことは理解しています。
「自分の書き方を料理に例えると」を書いてから 話し始めたほうがよかったですね。 失礼しました。 （しのみや） 2019/03/08(金) 09:01
???さんと違ってテキストベースではないのでgrep出来ませんが、その辺はgoogle検索で絞り込みはできるのでおまかせしています。
それよりも「実際に動くサンプルを作ること」を優先しており、著名な方々の記事やブログを読んだ場合も、気になったものは手元で再現します。
そのくらいしないと記憶の片隅にも残らないのと、忙しいときは投稿を解読してサンプルに起こす時間も惜しいので、すぐに動くものがあるというのは心強いです。
幅広い知識は様々なモノをひたすら書き続けるしか無いと思います。
当然、手元にある資料なんてごく僅かなので、基本は都度検索ですけどね。
ちなみにフローチャートも（細かい）コメントも書いたことないです。
私の場合、コメントを読むよりも実際にプログラムをトレースしたほうが深く理解ができるので。
逆に言えば理解しづらかった部分だけはコメントを書きます。
きっとコメントを書けと言う人も全ての行に書くという意味ではないと思いますが・・・。
参考まで。
（ななし） 2019/03/08(金) 11:20
出来る限りサブルーチン化する事を念頭に組み立ててみてはどうでしょう?
・１つのプロシージャを出来るだけ短くする事を意識する。
・同じ処理を２回以上書く必要があれば、迷わずサブルーチンとして外に出す。
・サブルーチンへの値の引継ぎは引数で行う(安易に広域変数に頼らない)
・メインルーチンそのものが長いなら、フェーズ毎にプロシージャを分ける。
こういった事を意識的に(ある程度強引に)やると、
当然コードの全体量は増えるし、変数の総数も打ち込む手間も増えてしまいますが、
デバッグする時に一番ウンザリするは、長～いプロシージャを相手にする時です。
プロシージャのひとつひとつが短い分には、修正個所の発見は容易です。
そうすれば、
サブルーチンに関連する例外処理だけサブルーチン内に書けばよし。
デバッグする時に、相手にするコード範囲がグンと狭まります。
サブルーチンの立場からしても「他の例外処理はメインルーチンに言ってくれ」で済みます。
コメント付けるにしても「○○の処理」「○○を返す関数」など、簡潔に表現し易くなります。
まぁ、要は役割分担ですね。
役割分担が明確になれば、自ずと汎用性は高まるハズです。
後々他のシーンで使い回すことも思い付き易くなります。
あと、これをやっていると、
プロシージャの本数は増えてしまう訳ですから、
今度は各プロシージャ同士のリレーションが煩雑になってきます。
「あちこちでCallしてるけど、それ何処?」みいたな。
そうなると次はモジュール内のプロシージャの並び順(セクションが読み取れる)や、
モジュール間の役割分担(モジュールの汎用性)とかも意識する様になってきます。
これらが意識して組まれているプロジェクトは、きっと
後から見ても分かり易いもの、他人が見ても比較的解読し易いものになっているし、
汎用性が高ければ別のプロジェクトに流用できる「持ちネタ」にもなり得るでしょう。
あ、でも
「じゃあ、あんたが作ったコードはさぞかし解読し易いんだろうな!?」
って言われると、全っ然自信無いですよ ^^;
私はそう心掛けてます。ってだけの話です。
（白茶） 2019/03/08(金) 14:24
[ 一覧(最新更新順) ]
YukiWiki 1.6.7 Copyright (C) 2000,2001 by Hiroshi Yuki.
Modified by kazu.