無料ブログはココログ

« 2017年6月 | トップページ | 2017年8月 »

Node-REDで品質の高いソフトウェアを開発する

開発者へのアンケートによると、Node-REDを用いると高品質なソフトウェアが開発できることがわかりましたが、そこには注意点がありました(Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -)。

Node-REDで開発する際にはNode-REDに合わせた設計やテストが必要です。順に説明しましょう。

データ設計

Node-REDのノードは関数ではなく、msgオブジェクトを加工しながら処理を進めますので、msgオブジェクトのデータ構造をきちんと決めておかないと、混乱してバグの原因になります。

msgオブジェクトと同じ様に処理館の共通データであるフロー変数やグローバル変数、データベースも同様にデータ構造をきちんと決めておきます。

構造設計

フローをどのように構成するか、非同期並行処理(コールバック地獄よさようなら。Node-REDで非同期処理を使いこなせ! )か順次処理かを検討します。非同期処理は処理が速く効率的です。一方の順次処理はメモリーをあまり消費しないので、大量データを扱う際に有利です。メモリー消費が多いとシステムやDBノードが止まることもありますので、注意深く検討してください。

システム間連携

前回(Node-REDでより大規模な開発を - モジュール化とフロー・システム間連携 - )に書いた様に様々な連携方法があります。それぞれの長所短所を検討して方式を決めてください。

いずれの場合もなるべく早い時期から結合すれば、信頼性を高めることができます。

モジュール設計

いわゆるモジュール強度(凝集度)や結合度を考慮してモジュール化します。なるべく単機能のノードやサブフローになる様に、インタフェースのデータ構造が単純になる様に設計します。

また、ノードの出力するオブジェクトがが参照なのか、データのコピーなのか、あるいは新しいオブジェクトにするのかを検討します。新しいオブジェクトにすると、渡していないデータは破壊されます。特にhttpレスポンスには多くのデータが必要ですので注意してください。

逐次開発・テスト

いわゆるxunitはカスタムノードでないと利用できません。改造する際はデグレが生じ易いので気をつけてください。良いモジュール構造にして、逐次開発とテストを並行して行います。

少しずつ開発しながら随時テストすることで、信頼性の高いソフトウェアを増やしていきます。常に追加した部分を動作確認すれば、まとめてテストした場合よりも抜けが少ない様です(Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -)。

機能テスト

機能テストを行う際は、機能の観点だけでなく、データの網羅性に注意すると良いでしょう。いわゆる界値に注目してテストデータを決めます。

Node-REDはスタブやモック、ドライバなど、いわゆるテストダブルの開発にも向いています。実機の利用が難しい場合に検討すると良いでしょう。特にDashboardを利用すると、使い易いテスト環境が実現できるでしょう。

非機能テスト

デバッグノードなどを不用意に繋ぐと、フローの二股に分かれたところでデータがコピーされ、メモリー負荷や、処理速度の低下に繋がるので注意してください。

Node-REDはNode.js上で非同期に動作しますので、スレッドによる実装よりも線形に性能が出ますが、残念ながら上限性能は存在します。小規模なテストで安心しないで、想定される負荷を実際に与えてテストしてください。

おわりに

Node-REDを使うと簡単に動くプログラムができます。しかし、ある程度規模が大きくなると、設計やテストの戦略が必要になります。

ここに挙げた方法は一例に過ぎません。開発対象や環境に合わせて実施してください。

このエントリーをはてなブックマークに追加

Node-REDでより大規模な開発を - モジュール化とフロー・システム間連携 -

Node-REDはマルチユーザ対応に向けてバージョンアップが進んでいますが、現在のエディタは基本的に一人でしか使えません。しかし、モジュール化やフロー・システム間連携を使えば、複数人で連携してより大規模な開発ができます。

1.  機能モジュールの作成方法

(1-1) エクスポート/インポート

エディタ上の任意のフロー/現在のタブ/全てのタブをJSONでエクスポートして人に渡したり、エクスポートしたJSONを受け取ってインポートすることができます(もちろんバックアップや複製にも使えます)。

エクスポートはフローを選択した後に、
 右上のハンバーガー(3本線)メニュー ⇒ 書き出し ⇒ クリップボード
を選択すると、 エクスポートのダイアログが表示されますので、選択したフロー/現在のタブ/全てのタブ、 それをコピーします。インデントのないJSONフォーマット/インデントのあるFOMAとを選択し、クリップボードに書き出します。

インポートは、
 右上のハンバーガーメニュー ⇒ 読み込み ⇒ クリップボード
を選択すると、 インポートのダイアログが表示されますので、現在のタブか新規のタブを選択して、エディタにコピーします。

(1-2) サブフロー

フローが大規模になると、同じフローが何度も出てくるなど見通しが悪くなりがちです。フローの一部をサブフローと呼ばれるモジュールを定義して扱うことができます。

右上のハンバーガーメニュー ⇒ サブフロー ⇒ サブフローを作成を選択すると、左ペインにサブフローが追加されサブフローのタブが開かれます。プロパティを編集するとサブフロー名や情報タブに表示される詳細情報を編集できます。入力(最大1つ)や出力(0以上)を設定すると、inputやoutputが表示されます。

またはサブフローにしたいフローの部分を選択しておいて、ハンバーガーメニュー ⇒ サブフロー ⇒ 選択部分をサブフロー化を選択するとその部分がサブフローになり、左ペインにサブフローが追加されます。左ペインのサブフローをダブルクリックするか、エディタ上のサブフローをダブルクリックして「フローのテンプレートを編集」をクリックすると、サブフローのタブが開かれます。

サブフローのタブを閉じてもサブフローは消えませんので、サブフローのタブを開いて削除します。

(1-3) カスタムノード

ユーザが独自のノードをJavascriptとHTMLで書くことができます。requireもできますので、様々なノードを 作ることもできます。 詳しくはCreating Nodesを見てください。

2. フロー・システム間連携

機能モジュール毎に担当者を分けて開発し、それらを以下のような方法でつなぎ合わせれば、より大きなシステムを作ったり、外部のシステムと連携することができます。

(2-1) デバッグノードの出力をインジェクトノードで送信

別の担当者のモジュールと接続する部分にデバッグノードをつないで、その出力のJSONをコピー(取り出)して担当者に渡します。担当者は受け取ったJSONをインジェクトノードに設定すると、異なるNode-RED間を直接つながないで、JSONデータを介してフローの続きを開発することができます。

(2-2) 異なるタブをリンクノードでつなぐ

機能ごとにタブを分けて、それぞれに担当者を決めておくとマージが容易になります。各タブのフローを繋いで大きなフローとするには、出力と入力のリンクノードを使います。

リンクノードは複数への出力や、複数からの入力の設定が可能です。リンクノードにわかりやすい名前をつけておくと良いでしょう。

(2-3) グローバル/フロー変数結合

取得したデータをメモリーやストレージに保存し、それを一定のタイミングで取得することも可能です。インジェクトノードで繰り返しを設定すると、一定間隔や指定日時、あるいはその組合せで処理を実行して、いわゆるポーリング処理やタスク処理を実現できます。

最も簡単な方法はグローバル変数やフロー変数を用いる方法です。グローバル変数は全てのノードから参照・更新が可能で、(いまのところ)Node-RED起動時に初期化されます。フロー変数は同じタブ(フロー)内のノードから参照・更新が可能で、デプロイ時に初期化されます。

(2-4) 処理間連携

httpノードやwebsocketノードを使えば、他のシステムと連携することができます。http inノードで要求を受けたら、同じ処理のフローにhttp responseノードを入れないと呼び出しが終了しないので気をつけてください。また、http requestノードは出力形式を文字列、バイナリバッファ、JSONを選ぶことができます。

他システムのデータをタスク処理やポーリング処理をするなら、ファイルやデータベースを使うと良いでしょう。ファイルは入出力のほかwatchノードで更新を検出することができます。また、カスタムノードをインストールすればPostgreSQLやSQLiteなどのデータベースを利用することができます。

3. おわりに

Node-REDで開発する際のモジュール化とフロー・システム間連携についてまとめました。

ここに挙げた方法を用いれば、複数人でNode-REDを用いてより大規模なシステムを開発することができます。みなさんも色々と工夫してください。

開発者へのアンケートによれば、大きなシステムを開発する場合はここにあげた方法だけでなく、設計やテストを工夫することで高品質なソフトウェアを短期間で開発することができます(Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -)。設計やテストの工夫もいつかまとめたいと思います(Node-REDで品質の高いソフトウェアを開発する)。

このエントリーをはてなブックマークに追加

[#TiDD] プロジェクトを成功させるチケット管理

QuaSTom高品質ソフトウェア技術交流会 2017年度第2回例会で講演させていただきました。

Redmineの勉強会ではないので初心者の方が多いかと思いきや、9割の方がチケットシステムを使われていて、そのうちTracが24%、Mantisが8%、残りがRedmineを使われていました。

幹事の松谷さんに用意していただいたグループディスカッションも、みなさんのお悩みや経験で盛り上がりました。やはり、メンバーにきちんと理解してもらえないとうまくいかないようです。

同じような議論は、90年代後半以降のプロセス改善ブームの頃にもありました。みなさんの意見をうかがっていると、やはり「ツールの導入はプロセス改善である」という思いが強くなりました。

ディスカッションへのコメントで「ゴールはプロジェクトの成功」とお話ししたことや、講演のおまけでお話しした「サーバントリーダーシップ」もリーダーシップの議論をされているとのことで喜んでいただけました。

久しぶりに大いに刺激を受けることができました。ありがとうございました。

おまけ

講演の仲であまり詳しく説明しなかったチケット駆動開発のレフトウィングとライトウィングのお話は、以下の発表が元になっています。

[#redmineT] 裾野が広がるRedmine「チケット駆動開発導入のヒント - 自律と規律 -」

(今回はお話ししませんでしたが、改善にはフィードバックやタイミングも重要だと思っています)

この発表の際にも使わせていただいた乗松さんの資料(PDF)の23ページ「SPIモードの遷移」は認証の罠を標準化の罠に読み替えるとツール導入にも同じような問題が起きると思いますので、参考にしてください。

このエントリーをはてなブックマークに追加


« 2017年6月 | トップページ | 2017年8月 »