プログラミング環境とワークフローの再整備(3言語を使うのは大変)
マイナーなZbrushプラグイン開発日記も、だんだん書いてきて飽きてきたw もちろん開発としては日々進んでいるが、ほとんど需要がないというか、読者が1%未満のテーマをnoteでダラダラ綴っていても時間の無駄?🤔な気もするので、Zbrushプラグイン関連の日記はそろそろ頻度が落ちます。
(約 4,200文字の記事です。)
言語ごとのフォルダとファイル配置の縛り
今日1日かけて開発ワークフローの改善を終了。Python、AutoHotkey、Zscriptという3言語を使う上に各言語特有の開発手順がある。それらを組み合わせた上で、いつ・どのフォルダで・どんな処理を、することでプログラミングを前に進めてコンパイルしてexe化してリリースに至らしめるか?を決めた。
さすがに3言語もあると設計から何度も見直しが入る。これが実際に開発しながらだと、
ファイル群をあっちにコピペしたりこっちにコピペしたり、
どれが旧版でどれが最新版?
どれのバックアップが最新?
などなどカオスになる。実際、設計上でもだいぶカオスだったので、せめて論理設計だけでもスッキリさせて、やるべき手順を形式化しておかないとカオスになる。というか1つのZbrushプラグインを完成させて既にカオスなので、ここで立ち止まって整理整頓しておかないと2本目以降の開発で爆発する😱
色々整理整頓するうちに、そもそもプラグインの中身の話以前として、プラグイン開発環境、つまり「どのフォルダに何のファイルを置くべきか」実はこれだけでも3言語特有の仕様があるのでカオスだった。それらをマインドマップで整理した。
結晶がこちら。
考えに考え抜いて「一筆書き」で開発できる仕組みが上記。相当複雑なことが分かるだろう。3言語それぞれの「仕様・縛り」があるのでそれらを回避する仕組みはこんなに複雑になる。だがこの仕組みによって1箇所のフォルダのバックアップでOKだったり、コンパイル後のテストやコード修正もファイルのコピペなどがほぼ不要。結構大変だった。
動作内容の論理構成の見直し
また1つのプラグイン開発で3言語を駆使するので、
各言語の相互関係
1つの処理の中でPythonからどっちを呼び出すか?
Pythonに戻ってくるのか?
処理終了で終わりなのか?
などなど、処理の流れを書き出していったらこれまたカオスに😭そりゃ実装で、
どのpyファイルに何の関数があるのか?
どのpyファイルでどんな内容のZscriptを呼び出しているのか?
py内のahkソースの記載などなど
がもうカオスに。
3言語の関連性と処理の流れ、どう可視化すれば?
なので今日は論理設計を改めてZscript、AutoHotkey、Pythonの3本で整理し直した。結局はZbrushのボタン押下でスタートするので必ずZscriptスタートなのだが、すぐにPythonを呼び出すので内部的にはPythonを主軸にahkに行ったりZscriptに行ったりして、でも最終的にPythonに戻ってきて終了というルーチンだ。これを何とか工夫してマインドマップで可視化できた。
とりあえず思いつきでイメージした図をマインドマップで描けた。この作戦がいいかどうかは謎。今後の運用次第で書き方を変えるかも。とりあえず3系統の縦の流れで分けられたので今は良しとする。
それだけでもだいぶカオスだった。そりゃこれだけ複雑なことを頭の中でやっていたら頭が爆発する。というか実際何度も爆発したw よくアルファ版で正常動作したもんだ。だがメンテや拡張が地獄過ぎる。
なので新たに引き直した論理構成に従って、Zscript、AutoHotkey、Pythonの各ソースの再設計。
言語間の変数の受け渡し、面倒臭いのだ
また3言語を使う上で肝が分かった。共通する変数をどうやって3言語間で共有するか、ということだ。最初にこれを避けたためにカオスになった。各言語で同じ意味の変数を勝手に宣言して使っていたものだから、3言語間で共通化できない。1つの変数の仕様を変更すれば3箇所の変更が必要。
なので色々考えた結果、3言語間で共有できる変数の仕組み作り、これがまず最初だなと分かった。仕組みは考えたのでOK。最初はJSONで受け渡そうかと思ったがZscriptがJSON実装で絶望的だったので変更。結局Valueの並び順に意味を持たせることで3言語間でKey, Valueの共通化を行なうことにした。
あとはプログラムの流れの中で、どのブロックが処理中なのか、これは人なら分かるし、メインのPythonでも分かる。だが呼び出される側のZscriptにとってはこれが分からない。(AutoHotkeyは結局Pythonソースファイル内で呼び出されるのでPython経由でどのブロックで処理中かは分かる。)なのでPythonからZscriptに第Nブロックの処理中だよ、を伝える変数が必要なことも判明。
なので今回はきっちりと3言語の使い分けて呼び出しタイミング、似た処理でも微妙に違うところが明らかになったので、ブロックNo.で処理ごとの条件分岐を与えてあげれば、大枠の関数は使い回せつつ、内部の微妙な追加処理・スキップ処理についてはブロックNo.で判定させれば、スッキリとした実装になる。
使い回せる関数か否か
プログラミングでは「全く同じ処理」ならば関数化して呼び出すことで安定運用できる。だが「処理の1%が状況によって異なる処理」の場合、悩む。今回はその処理内容の変更量が少しなので、例外的にその処理にIFとブロックNo.で実行の有無を決めさせることにした。99%の処理は共有なので、大きな流れとしてはその関数を使い回すように見せる。これなら今後2個3個程度ならその関数内に例外的な処理を追加しても、全体への影響は出ない。
結局ここでもまたZscriptが足を引っ張る。困ったちゃんだ。なのでZscript実装に対して論理設計を大きく変えた。ブロックNo.の受け取りとNo.による処理の分岐を、大枠の関数内に仕込む。
Pythonのファイル分けの再整理
あとPythonについても全体的なプログラミングの流れや癖が分かったので、最初はバラバラにおっかなびっくり実装された関数が散り散りになっているので、これも新たな名前の.pyにまとめ直し。何だかんだで追加・追加で細々とした内部関数が増えすぎてカオスになった。なので関数全体を俯瞰して、今回だけ使う関数、今後も使い回せる「育てるMy関数」などをファイルごとに分けて管理する必要がある。というかそうやって自分の道具を育てられるのがPythonのいいところだ。これはまぁPythonに限らず、ある程度発達したプログラミング言語ならまぁ当たり前の話。
とりあえずPythonについても.py単位で整理整頓。ただしPythonについてはPyCharmのリファクタリング機能がめちゃんこ強力なので、ゴリゴリと移動させてもきちんとその都度整合を取ってくれる賢いツール。これがIDE環境の威力だよ、と。Pythonのリファクタリングは多分めちゃんこ快適に高速に作業できそう。
VS Codeの構文ハイライトと拡張子
ahkについてもVS Codeで色々調べて、ChatGPTに聞いてワークスペース単位でのSettings.jsonの変更の仕方を学んだ。なのでZscriptエディタ、ahkエディタとしてかなり使いこなせるようになったVS Code。これを使って効率的にZscriptとAutoHotkeyを開発していく。シンタックスハイライト万歳である!ZscriptもAutoHotkeyも秀丸エディタで開発していた頃とは雲泥の差。それだけ構文ハイライトと自動補完機能が強力だ。VS Code万歳である。
結局、そこまでして開発環境を整えたのは、PythonにはPyCharmが、ZscriptとAutoHotkeyにはVS Codeが各言語のIDE環境になると分かったからだ。これが大きい。Zscriptだけはコンパイル型なのでZbrush経由でないと動かないが、それでもコーディング時にVS CodeのIDE機能が使えるのは大きい。リアルタイムで構文エラーを潰せるのは強い。AutoHotkey v2についても然り。(拡張プラグインの対応具合で言えば古いv1の方が充実かも知れないが、今後のことを考えるとv2しかあり得ない選択だ。)
というわけで今日もダラダラと書き殴って3,000里の旅であった。そして見直して加筆修正したらビバ4,000文字。昨日も書き殴ったがさすがに今日は見出しくらいを付けて見やすくしますわ。
今日はこれにて終了。
酒が飲みたい。だが飲めない。さよな~ら~、カントリーロード。
今回の創作活動は約45分(累積 約3,868時間)
(1,116回目のnote更新)