既存のノードネットワークを変更する際、変更する対象が巨大であるためにどこを変更すべきかわかりにくくなってしまっていたり、ある箇所への変更が他の箇所に影響してしまい、メンテナンスしづらい状況を経験したことは誰にでもあると思います。この記事では、そのような状況を改善・予防するため「リファクタリング」と呼ばれる手法に焦点を当て、筆者の主観をもとに基本的な手法を紹介したいと思います。コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。いくつかのリファクタリング手法の総称としても使われる。十分に確立された技術とはいえず、また「リファクタリング」という言葉に厳密な定義があるわけではない。(Wikipediaより抜粋)※ここでいう「プログラムの外部から見た動作を変えず」というのは、リファクタリング前後で、リファクタリングする対象が行う処理の結果を変えないという意味です。■HoudiniでのリファクタリングHoudiniでの作業はプログラミング色が強く、ノードネットワークを組み立てることはプログラミングすることそのものと言えます。ノードネットワークは、ある種ソースコードのようなものです。HoudiniではVEX/Wrangle/Pythonなど、プログラミングそのものを行う要素も含んでいます。そのため「リファクタリング」手法のいくつかをHoudiniでも比較的素直に取り入れることができます。■リファクタリングのメリットリファクタリングにより、ノードネットワークの構造を整理することができ、結果として以下のようなメリットが得られます。□名前の変更ノード名、パラメータ名、アトリビュート名、Wrangleの変数名など、各種「名前付きの要素」を、誰が見てもわかりやすい形にリネームします。これにより、その要素の役割が判断しやすくなり、時間が経ってから見直したときや、他人へデータを渡したときに処理の内容を理解する助けになります。部分だけでノードごとの基本的な動作が伝わりますその要素が何を行うものであるか判断できるよう、名前の先頭に目的に応じたプリフィクスを追加します。ルールに則ったプリフィクスを利用すると、ひと目でその要素が大雑把にどのような動作をするものか判断しやすくなり、メンテナンス性が向上します。ノード名はそのノードの動作に適した動詞をプリフィクスにします。変数名の場合も同様に、変数の役割がわかるようなプリフィクスをつけます。このようにしておけば、ノードリストなどでノードを検索する際のヒントにもなります。test_・意味のある名前についてaaaaaaaaaaaは最終的に必要?目的は?1年後に思い出せる気がしません・・・プログラミング学び初めの頃によくやってしまいがちなことの一つに、実験用の変数のような「瞬間的にほしい要素」に対し、一見して意味のない名前をつけるということがあります。これは、実験中はいいのですが、実験終了後にこの要素が不要となったにもかかわらず、要素を消し忘れたまま時間が経ってしまった時に問題を引き起こします。このような要素は本来不要であるにもかかわらず、なんとなくまだ必要そうな気がしてしまい、出来上がった仕組みを壊してしまうことに対する恐れも手伝い、消せないまま放置してしまったことがある方は多いのではないでしょうか。実験用に作った要素が最終的に採用され、利用されることになるケースもあります。このような場合も、はじめから意味のある名前をつけておけば、名前を修正する手間が省けて一石二鳥です。miewaaaaaa※ループカウンターで使われる[i,j,k]や、座標を表現する際に使われる[x,y,z][u,v,w]などは、それ単体では意味のないアルファベットですが、一般的な名前として広く認知されているので、意味を持っています。そのため、使用しても何ら問題ありません。いくつか種類があります。目にする主な記法はだいたい以下の3通りだと思います。CalcCutDistancePointNumPrimAreaAddTwoPoints筆者は最近、Pythonのコード規約であるPEP8にならうことが多いです。具体的に言うと以下のようなルールに従っています。・略称について略しすぎると、そのノードの役割が全くわからなくなります名前付き要素に略称を使うことは可読性を損なう一因となります。メンテナンス性を高めるためには、極力名前のパーツに略称を使わないことが望ましいといえます。あるノードを「calc_center_position」という具体的な名前にする場合を考えます。このとき、「position」という言葉が長すぎると感じるかもしれません。そのような場合、略称を使いたくなります。ここで「position」を「p」と極端に略した場合、その「p」がどのような意味合いで選択された名前なのか第三者には瞬時に理解できません。(もちろん前後の文脈から想像はできますが、瞬時に理解するのは難しいでしょう)もしかしたら、数日後の自分ですらその「p」が何なのか即答できないかもしれません。そこで、この「position」という文字列を、一般的によく使われる「pos」という略称に置き換えるのは悪くない考えです。前後の文脈によっては「pos」から「positive」など、別の言葉を連想する可能性もあり得るので、意味をはっきり伝えるという意味では少し確実性に欠けます。いえ名前が長くなりすぎるのも困りものです。実際のところ、若干の読みやすさを犠牲にして、明らかに一般的な共通認識として定着している略称のみを必要最小限の範囲で使用するのが良い落とし所となるでしょう。nm,・長すぎる名前について長過ぎる名前は、詳細はわかりますが不便です適度に略称を取り入れながら、ほどほどの長さに収めましょう名前の文字数は長くても20文字~30文字までといった意見をよく見かけます。確かに長い名前はコードが複雑化すると全体が見づらくなる原因になります。した文章のような長さの名前はおすすめできません。省略しすぎて意味が全くわからない名前よりは遥かに良いです。短すぎる名前を使うくらいなら、意味のわかる長い名前を使いましょう。CodeやSublimeなどに、対応する言語のプラグインをインストールして外部エディタとして利用すると、インテリセンス(コード補完機能)が使えるようになります。Houdini内ではノードパスなどでインテリセンスが利用できます。そのため、多少長い名前を使用していても間違いなく簡単に入力できるうえに、いざ名前が長すぎたと感じる場合でも、エディタの機能で特定の対象だけ簡単にリネームできるので、さほど問題になりません。上記を踏まえた上で、具体的な名付けの例を挙げてみます。point_numベクトルAとBの内積を格納する変数名dot_A_B□アルゴリズムの更新とテストcompare_geometryでunittestを行いながら処理を分解リファクタリングの重要なポイントに、処理の内容を変えずに構造を整理するということを挙げました。そのためには、リファクタリングの前後で結果に差がないことを確認しながら作業をすることが重要です。通常のプログラミングでのリファクタリングは以下のように進めます。リファクタリング対象を複製し、もとのロジックをとっておきます。リファクタリング後の処理がどうなっていれば正解なのか判断できるデータを作ります。このデータを、リファクタリング後の処理結果と常時比較しながら、結果が異なる場合に即座に検知するために使います。この比較は、一般的にユニットテストと呼ばれます。リファクタリング語の処理結果が、リファクタリング前と同じであることを確認しながら構造の修正を行います。リファクタリング対象のノードや一連のノードチェーンを複製、分流。SOPを作成し、分流したノードの出力を接続します。SOPでリファクタリング前後の結果を簡単にスイッチして確認しやすくします。ジオメトリのアトリビュートを比較するユニットテスト用HDAを作成してもいいでしょう。リファクタリング前後で結果が同じであることを確認しながら構造の修正を行います。□関心の分離1つのWrangleに3種類の処理が含まれていたので分解した例1つのノードでは、1度に1種類の処理のみを行うようにします。SOPでは色を設定することのみを行うようにします。SOPでは、色を設定すると同時に法線を設定するように複数種類の処理をさせることはしません。色の設定と別に法線を設定する必要がある場合、2つの処理を切り分けて別々のノードを作成し、それぞれで処理を行います。処理を切り分けることでその処理が影響する範囲が小さくなります。これにより、この処理に対する何らかの変更が必要な場合に気を配る必要にある範囲が小さくなります。これが「関心を分離する」ということです。関心を分離した結果、それぞれの処理に変更を加えたい場合や、ある処理の前後に新たな処理を追加する場合に、変更すべき箇所がわかりやすくなります。ノードを切り分ける場合は、処理のステップが複数のノードに分かれるので、各ノードのVisibilityフラグを切り替えながら、各処理ごとの結果が確認しやすくなります。Wrangleの場合、コード中の特定の行で処理を止めて途中経過を確認するようなデバッグ機能がないので、Wrangleコードとそのコードで使われるパラメータを機能単位のWrangleに切り分けて関心を分離することになります。整理された5つの処理を、1つのsubnetに集約したHoudiniに限らず一般的なプログラミングでは、複数の小さな処理を積み重ねて大きな処理を組み立てていきます。Houdiniでは、複数のノードをSubnetノードにパックしてまとめることができます。複数の小さな処理で成り立つ大きな処理をパックすることで、処理のくくりが明確になり、ノードネットワークの見通しが良くなります。これは一見すると、上で挙げた「関心の分離」に反するように見えます。たしかに、何も考えずにSubnetに複数のノードをまとめてしまうと、むしろノードネットワークが俯瞰しづらくなり、混乱の原因になります。そのため、処理を集約する際は、必ず集約する処理に対し関心の分離を適用します。複数の処理を一つのSubnetにまとめるタイミングは、関心の分離を適用する前でも後でも問題ありません。関心の分離を適用するとノードが増えます。ノードネットワーク全体が膨大なノード数で構成されていて、これ以上ノードを増やすと視覚的に全体を俯瞰しづらくなる場合などは、先に関心の分離を適用する処理の範囲をSubnetにまとめておき、そのSubnet内で適用することで、その他の箇所に気を取られずに作業できるようになります。これもまた、ノードネットワーク全体を巨大な処理と見立てた関心の分離とも呼べます。一心不乱にノードネットワークを作成していると、途中で行ったコピー&ペーストの影響なども手伝い、全く同じ処理を随所で繰り返している事態に陥ることがあります。同じ処理が複数箇所にあり、それぞれの処理に同じ変更を加えたい場合、それぞれに対し個別に同じ変更を加えるのは現実的とは言えません。このような場合、処理を切り出して再利用できるようにします。その後、切り出した再利用可能な処理で各所の重複部分を置き換えることで、その後の処理変更が1箇所で行えるようになります。・HDASubnetにまとめた仕組みは、デジタルアセットに変換することで再利用が簡単になります。Blockを通して、一連の処理を再利用できます。他にも多くのリファクタリングテクニックがあるのですが、ここでは基本的なものに絞って紹介させていただきました。タイムリミットも迫り記事も長くなってしまったので、より実践的なリファクタリングの実例紹介は別の機会に・・・この記事について、なにかご質問や間違いがありましたら遠慮なくツッコミをいただけると助かります。最後に、個人的にリファクタリング関連で参考になったと感じる書籍をいくつか紹介します。Houdiniはそもそもプログラミングツールではないため、これらの書籍で紹介されるすべてのテクニックが適用できるわけではありませんが、多くの点で役立ちます。(今回ご紹介したリファクタリングや、Wrangle、Pythonでコーディングする際など)特に「レガシーコード改善ガイド」の方は、古いコードのメンテナンスに際し起こりうる様々な問題ごとに適用できる、リファクタリングとテストを使うコード改善テクニックが紹介されています。今回紹介したユニットテストを使う安全な開発方法(テスト駆動開発)も、こちらの書籍から着想を得ています。興味のある方はぜひ読んでみてください。