社員リレーブログVol.13「LabVIEWプログラミング　アンチパターン集」

ブログ2023.04.24

はじめに

ちゅおっす！

(↑弊社ゆるキャラ「ちゅうでんちゃん」の挨拶です。これだけでも覚えて帰ってくださいね♪)

ソフトウェア技術本部のSです。
今回は、LabVIEWプログラミングにおけるアンチパターンについて考えてみたいと思います。

アンチパターンとは？

“ある問題に対する、不適切な解決策を分類したものをアンチパターンと言う。”

引用元: [アンチパターン -Wikipedia]

やらかしがちなミスやよくある勘違いを一般化してまとめた「反面教師集」、といったところでしょうか。
ソフトウェアの世界はアンチパターンの研究が盛んでして、それを見るに先人の方々の苦労は察するに余りあるのですが、それはさておき…

本記事は、私が実際にLabVIEWでアプリケーション開発をしていて、(見たことまたはやらかしたこと)がある事例を紹介し、逆説的により良いプログラミングのためのtipsを得られるものにしたいと思います。

アンチパターン例

その①：スパゲティコード

“スパゲティプログラム（spaghetti program）またはスパゲティコード（spaghetti code）とは、
コンピュータプログラムの状態を指すための表現（俗語）であり、
命令の実行順が複雑に入り組んでいたり、遠く離れた関連性の薄そうなコード間で共通の変数が使われるなど、
処理の <<流れ>> や <<構造>> が把握しにくい見通しの悪い状態になっているプログラムのことである。”

引用元: スパゲティプログラム – Wikipedia

ロジックが一貫しておらず構造が必要以上に複雑で、さながらスパゲティのようにあちこち絡まっているコードのことをこう呼びます。
ハードウェアの配線でも同様のことが起きてしまうことがありますね。

ところで、LabVIEWはビジュアルプログラミング言語です。
ノード間をワイヤで繋いでプログラミングするわけですが、この配線を適当にやってしまうと…

引用元: [LabVIEW Smells – Anti-patterns – NI Community]

こうなります。
こちらはNIのフォーラムに投稿されていた画像ですが、これを作った方が今までしてきた苦労は察するに(以下略)

「とりあえず動けばいい」という心構えではなく、後からの可読性・保守性を考えながらプログラミングすることが、スパゲティコード化を防ぐ第一歩となるでしょう。

その②：マジックナンバー

“プログラムにおけるマジックナンバー（英: magic number、魔法の数字）とは、
何らかの識別子もしくは定数として用いられる、プログラムのソースコード中に書かれた具体的な数値である。”

引用元: [マジックナンバー (プログラム) – Wikipedia]

開発初期にとりあえず定数で置いたものが、見直されずに最後まで残ってしまった結果発生したりします。(実体験)
こちらも動作はするのですが、後にプログラムを手直ししようとした際に問題になりやすいものですね。

LabVIEWの場合、定数にもラベルを付けることができます。
よほど自明な場合を除いて、ラベルにその定数の意味を書いておくだけでも「その定数が何を指しているのかが分からない」という問題は回避できますね。

その③：状態遷移図なしのステートマシン

前2つはソフトウェア開発一般に通ずるアンチパターンでしたが、こちらはLabVIEW特有かつ設計寄りのものになります。

LabVIEWには「ステートマシン(State Machine)」と呼ばれるデザインパターンがあります。
状態ごとの処理とイベントをこのパターンに沿って定義していくことで、状態遷移図をそのままコードに落とし込むようにプログラムを作れる優れモノです。

アプリケーションデザインパターン:ステートマシン – NI

さて、当然ですが、このデザインパターンを基にコーディングをする場合、設計がきちんとなされていて状態遷移図が書かれていることが前提になります。
さもなくば、第三者からみてフローが分からず、まるで手出しできないプログラムになってしまうということです…。

こうならないための対策としては、「きちんと設計してから実装に取り掛かる」ということに尽きます。
UMLについての知識を付けるのも良いでしょう。

当たり前の話ですが、改めて大事なことだと感じますね。