エクセル、VBA、プログラミング雑感

ほえほえ＠スプシマン @hoehoe1234

VBAで多くの人に求められる機能（ライブラリ）ってなんなんだろうね。滝LIbは自分が使う機能、あったらいいな。を追求してきたけど、「他人のコードをみるためのインスペクション機能」なんかがホントは必要なのかもね。

ほえほえ＠スプシマン @hoehoe1234

VBAでのパスの扱いは、もともとの作りからすれば変速なんだけどそのかわりに、わかりやすく、使いやすくなってるんだよね。でもドライブの扱いとかいろいろな読み替えは便利だけどコンパチ機能作るの難しいｗｗｗ

ほえほえ＠スプシマン @hoehoe1234

抽象パスの取り扱いは、組み込み関数にはないし、FSOのは機能不足で使いにくいから自作するととても使いやすくなります。 pic.twitter.com/RETtkLV0ju

拡大

ほえほえ＠スプシマン @hoehoe1234

select 項目->filter where->filter odrby->sortby distinct->unique なので、あとはgroup byする関数ほしいっす。 twitter.com/excelspeedup/s…

はけた＠できるExcel2021 @excelspeedup

要はSQLを書ける関数希望という話なんじゃないかと推測。 twitter.com/KotorinChunChu…

2021-06-01 16:34:57

ほえほえ＠スプシマン @hoehoe1234

エクセルのシートは、mallocと同じような感覚で使える優れたヒープ領域＆構造化グローバルデータなんだけど、配列、コレクション、その他のデータ構造が使えるときは後者を優先してつかっている。感覚的には正しいんだけどその理由を言語化するのは難しい気がする。

ほえほえ＠スプシマン @hoehoe1234

違いの羅列 ①シートは揮発性ではない ②取得／開放にプロトコルが必要 ③UIとの混合（un visibleにすればよい？） ④関数の戻り値にしにくい（無名シートは存在できない） ⑤グローバルなので引数としなくても動く ⑥コピーしにくい。 ⑦ローカルでの情報伝達に適していない ⑧やはり「無名」でない。

ほえほえ＠スプシマン @hoehoe1234

⑨配列を返す関数の代わりにシートを返す関数を想定するとやはりいろいろ問題がおきそう ⑩配列、辞書、コレクションはデータ構造が規定されるが、シートは「シート」であるだけでその中の構造は別途規定しなければいけない。（データ構造の不確定）。

ほえほえ＠スプシマン @hoehoe1234

⑪とはいえ、仮に dim sheet : set sheet = new WorkSheet という構文がゆるされるのであればかなり使いやすことが想定され、これと現実の差はやはり、無名性、グローバル性、コピー性ということになるのであろうか？

ほえほえ＠スプシマン @hoehoe1234

関数オブジェクト、関数記述にするとコード密度が５～１０倍ぐらいになるので、アプリ全体についてはわからないけど、局所的には関数型言語を関数型としてちゃんとつかうととても短く記述できるんだな。という実感があるね。

ほえほえ＠スプシマン @hoehoe1234

ソート関数の一番の問題は「どのような基準でソートするか」が都度変わることであり、ソートロジックと比較ロジックを「分離」しなければいけない。この分離にかつては関数ポインタなどが使われていた。この構造と機能を分離することが共通関数を設計する上でのポイント。VBAでは割とむずかしい。

ほえほえ＠スプシマン @hoehoe1234

オブジェクト指向ではこれを多様性を利用して解決している。関数オブジェクトの注入も多様性の一種と理解していいと思う（括弧をつければ呼び出せるものという意味）。本格的な関数型言語がやりたいな。

ほえほえ＠スプシマン @hoehoe1234

これをみながらこつこつと。。。こういうのは関数クラスにラップして・・・というのが正解なんだけど、機能関数を作ってしまってから拡張しているから手間がかかりすぎ・・・機能は交差するから爆発しやすいんだよね。 pic.twitter.com/viihaTqK02

拡大

ほえほえ＠スプシマン @hoehoe1234

モジュールの一覧 プロシージャの一覧 モジュール定義 プロシージャ定義 ・・みたいにきちんと階層＋木構造でモジュール木をつくっておかないと機能ごとに同一コードが何回もでてくるんだよね。アノテーション対応で適当につくってきただけにつらい。。。

ほえほえ＠スプシマン @hoehoe1234

解析技をつくっておいてから、必要なアノテーションとか条件で関数をフィルターするのが正解だと最初からわかっていたけど手抜きしてたら案の定・・・というかなしみ。機能集約はよく破綻するｗｗｗ。

ほえほえ＠スプシマン @hoehoe1234

このあいだちゅんさんが投稿していたように、帳票の話も同じ。機能はn:m問題が多発しやすい、一度データ構造に整理しなおしてデータ集約しないと複雑さはもちろんだけど、同一コードが多発する。機能に着目した分割はよくうまくいかないんだよね。

ほえほえ＠スプシマン @hoehoe1234

filter関数は配列を返すのでレンジでないので、一方通行なんだよね。これがレンジだったらfilter->削除。とか一発でできるのにね。まあいろいろあるんだとおもうわ。

ほえほえ＠スプシマン @hoehoe1234

リフレクションで（わかっていたけど） ①アノテーションを指定して関数定義を取得 はよくなくて設計時には ②関数定義一覧からアノテーションでフィルターする みたいな設計にしないと拡張性がないし、複雑になるんだよね。この辺の感覚はオブジェクト指向の勉強だけではちょっと身につかない感じ？

ほえほえ＠スプシマン @hoehoe1234

①複雑データ->②整理統合データ のあとに ②->さまざまな利用関数 ってなるんだけど、オブジェクト指向ではこれらを「統合」はしてるけどデータの整理統合フェーズがおなざりになりそうなきがするんだよね。

ほえほえ＠スプシマン @hoehoe1234

C言語などのモジュール型の言語をまなぶ、コードをよむ。オブジェクト指向を学ぶ、データ構造をまなぶ、設計方法論を学ぶ、雑誌とか書籍をたくさんよむ。ということを通じてやっとこのごろまともな関数分割とその理論がわかってきたけどめちゃくちゃ時間かかったな。

ほえほえ＠スプシマン @hoehoe1234

これ、手っ取り早く修得するにはきついけど、①OSのコードをよむ（精緻な構造）②アルゴリズムとデータ構造（基礎知識）、③方法論（壺のような本）、④オブジェクト指向の本を１ｍぐらい読む。これに現場での良い仕事があると息をとめてかけぬけると最速２～３年で到達できる可能性はありそう。

ほえほえ＠スプシマン @hoehoe1234

集合論、モジュール分割、その他の設計方法論も多分書籍１ｍぐらコースだから、色々合わせると５～１０ｍぐらい読んでやっとそれなりの理論と経験をつめそうな感じなんですよね。適性しだいでしょうけど。

ほえほえ＠スプシマン @hoehoe1234

簡単な方法論としては「つねにデータの整理統合をこころがける」でいけるかも。ER図もモジュール設計もぜんぶそのあたりに帰結します。ただ、周辺技術と概念がそれぞれ違うので個別に勉強が必要ですが。

いちか　かあき @ichika_khaki

私は一時的な読み書きの場所としては、シートはなるべく使わないようにしてます。 昔、ループでガンガン「セルに値を入れた」時に「一部セルに値が入ってない」事があって 発生の有無も発生セルも実行毎に変わってしまい 結局「値を入れた後にセルを参照して照合&リトライ」にした事を思い出して…。 twitter.com/hoehoe1234/sta…

いちか　かあき @ichika_khaki

「セルのペースト」だからかな？と代入文に書き換えたのですが、 それでも起きて「なんでや！」と。 数年使われてて(時間はかかっても)シンプルなループ文でコード見ててもおかしくなりそうな部分が見当たらず。 照合&リトライのコードを追加して発生時ブレークでウォッチみてもおかしくなく諦めました