توسعه اسکریپت اختصاصی Dynamo دقیقاً چه چیزی را جایگزین می‌کند؟

Dynamo یک محیط برنامه‌نویسی بصری است که همراه رویت ارائه می‌شود. هر گراف از نودهایی ساخته می‌شود که هرکدام یک کار مشخص انجام می‌دهند، مانند جمع‌آوری تمام شیت‌ها یا تنظیم یک پارامتر، و از سیم‌هایی که داده را از خروجی یک نود به ورودی نود بعدی منتقل می‌کنند. گراف از طریق همین نودها به Revit API دسترسی پیدا می‌کند و در نتیجه، کاری که هر بار با همان کلیک‌ها انجام می‌شود، یک‌بار تعریف شده و بارها اجرا می‌شود.

آنچه این ابزار جایگزین می‌کند، زمان تکرار دستی است، نه قضاوت فنی. کسی که می‌داند شیت‌ها باید چگونه شماره‌گذاری شوند، همچنان باید این را بداند؛ گراف فقط او را از تکرار دستی همین کار در هر پروژه بی‌نیاز می‌کند. گرافی که قاعده را درست ثبت کرده باشد، آن را در پایان یک روز طولانی نیز به همان شکلی اجرا می‌کند که در ابتدای روز.

همین نکته، مرز کار را هم مشخص می‌کند. گراف فقط تصمیمی را تکرار می‌کند که پیش‌تر به‌روشنی گرفته شده باشد. اگر دفتر نتواند قاعده را مکتوب کند، گراف همان نسخه‌ای از قاعده را اجرا می‌کند که سازنده‌ی آن در ذهن داشته است.

مرتب‌سازی شیت‌ها، نام‌گذاری ویوها، جانمایی لجندها و پرکردن فیلدهای کادر نقشه معمولاً نخستین جاهایی هستند که دفتر نتیجه‌ی خودکارسازی را در آن‌ها می‌بیند، زیرا این کارها مدام تکرار می‌شوند و قاعده‌ی روشنی دارند: یک شیوه‌ی شماره‌گذاری، یک ترتیب و یک قالب مشخص. همین وضوح، ریسک خودکارسازی آن‌ها را از کارهای طراحی‌محور کمتر می‌کند و به همین دلیل، خودکارسازی مرتب‌سازی شیت در رویت برای بیشتر دفاتر نقطه‌ی شروع مناسبی است.

داده‌ها دومین نقطه‌ی شروع هستند. Dynamo می‌تواند از Excel بخواند و در آن بنویسد، در نتیجه پارامترهایی که امروز یک نفر آن‌ها را میان اسکجوال و فایل Excel جابه‌جا می‌کند، با یک گراف در هر دو جهت منتقل می‌شوند. قاعده همان قاعده‌ی شیت‌هاست: اگر بتوان ارتباط میان ستون‌ها و پارامترها را مکتوب کرد، می‌توان آن را خودکار نیز کرد.

ارزش این بخش فقط در سرعت نیست. مستندسازی‌ای که با گراف انجام می‌شود، هر بار از یک قاعده‌ی ثابت پیروی می‌کند و به برداشت فردی که آن روز کار را انجام داده، وابسته نیست.

گراف می‌تواند نقش یک بازرس خودکار را داشته باشد: المان‌ها را جمع‌آوری کند، پارامترهای خالی، درهای بدون تگ یا ویوهای بدون View Template را مشخص کند و در برخی موارد آن‌ها را اصلاح کند. این همان منطقی است که کنترل‌کننده مدل رویت به کار می‌گیرد، با یک تفاوت: گراف اختصاصی دقیقاً قواعدی را بررسی می‌کند که استاندارد داخلی دفتر شما تعریف کرده است.

ریسک این بخش، گراف کنترلی است که خود آن تست نشده باشد. با هر هشدار نادرست، اعتماد به گزارش سریع‌تر از هر هشدار جاافتاده کاهش می‌یابد، زیرا پس از چند مورد، افراد دیگر گزارش را نمی‌خوانند. گراف بازرسی پیش از آنکه کسی به آن تکیه کند، باید روی چند مدل واقعی و متفاوت اجرا شود، نه فقط روی مدلی که برای آن نوشته شده است.

جانمایی خودکار فمیلی‌ها در امتداد محیط اتاق، ساخت والپست‌ها بر اساس نوع دیوار یا اعمال نازک‌کاری بر اساس اسکجوال اتاق‌ها، همه از یک الگو پیروی می‌کنند. قاعده از پیش در داده‌های پروژه وجود دارد، مانند نوع اتاق، نوع دیوار یا نازک‌کاری موردنیاز، و فقط باید یک‌بار به‌صورت منطق نوشته شود. خودکارسازی فمیلی والپست در رویت و خودکارسازی نازک‌کاری دیوار، دو نمونه از همین ایده هستند.

در این بخش، فاصله‌ی میان یک گراف آزمایشی و یک ابزار واقعی بیشترین اهمیت را دارد. جانمایی‌ای که در یک اتاق مستطیلی درست کار می‌کند، ممکن است در اتاقی نامنظم یا اتاقی با چند بازشو با خطا روبه‌رو شود. گرافی که فقط حالت ساده را پوشش می‌دهد، پس از هر اجرا به یک بررسی دستی نیاز دارد و در نتیجه، زمانی که قرار بود صرفه‌جویی شود، دوباره صرف همین بررسی می‌شود.

بیشتر گراف‌ها در مرحله‌ی تحویل با مشکل روبه‌رو می‌شوند، نه در منطق. سازنده می‌داند پیش از اجرا کدام نود باید تغییر کند، کدام ویو باید باز باشد و کدام هشدارها اهمیتی ندارند. دیگران این موارد را نمی‌دانند و هیچ‌کدام از آن‌ها روی صفحه‌ی گراف نوشته نشده است.

در رویت، ابزار این کار از پیش وجود دارد. Dynamo Player گراف‌های یک پوشه‌ی مشترک را فهرست می‌کند و آن‌ها را از زبانه‌ی Manage، بدون بازکردن ویرایشگر Dynamo، اجرا می‌کند؛ اگر گراف ورودی لازم داشته باشد، Player آن را از کاربر می‌پرسد و طبق راهنمای Autodesk، نتیجه‌ی هر اجرا با Undo در رویت قابل‌بازگشت است. برای آنکه گراف به این شکل کار کند، باید از ابتدا برای آن ساخته شود:

• فقط ورودی‌های نام‌گذاری‌شده. هر مقداری که کاربر ممکن است تغییر دهد، یک نود ورودی با نام روشن است و هیچ چیزی نیاز به ویرایش در داخل گراف ندارد.
• گروه‌بندی و یادداشت. نودها بر اساس مرحله گروه‌بندی می‌شوند و هر گروه یادداشت کوتاهی درباره‌ی کار خود دارد تا فرد بعدی بتواند منطق را دنبال کند.
• نتیجه‌ی قابل‌پیش‌بینی. گراف گزارش می‌دهد چه چیزی را تغییر داده و از چه چیزی گذشته است تا بتوان اجرا را بدون مقایسه‌ی چشمی مدل بررسی کرد.

گراف‌هایی که مدل را تغییر می‌دهند نیز باید در حالت اجرای Manual ذخیره شوند، نه Automatic، تا هیچ اجرایی بدون درخواست کاربر انجام نشود.

نودهای بصری برای بیشتر منطق‌های خطی کافی هستند. اما وقتی گراف به شرط‌های پیچیده، حلقه‌های تودرتو یا بخشی از Revit API نیاز دارد که نود آماده‌ای برای آن وجود ندارد، یک نود Python در همان گراف سریع‌تر نوشته می‌شود و نگهداری آن از زنجیره‌ی بلندی از نودهای بصری ساده‌تر است. فصل Python و رویت در Dynamo Primer این الگو را نشان می‌دهد.

این به معنای کنارگذاشتن Dynamo نیست. گراف لایه‌ی قابل‌مشاهده، یعنی ورودی‌ها و خروجی‌ها، باقی می‌ماند و منطق اصلی در چند خط کد زیر آن قرار می‌گیرد. تیمی که هم برنامه‌نویسی بصری و هم Revit API را می‌شناسد، می‌تواند برای هر بخش تصمیم بگیرد که نود کافی است یا Python با نگهداری کمتر همان کار را انجام می‌دهد.

کتابخانه‌ی گراف‌ها نیز مانند کتابخانه‌ی فمیلی‌ها به‌تدریج نامرتب می‌شود: نسخه‌های تقریباً یکسانی از یک گراف با نام‌های نزدیک به هم، پکیج‌های شخص‌ثالثی که سال‌هاست به‌روزرسانی نشده‌اند و گرافی که فقط سازنده‌ی آن می‌داند چه ورودی‌ای لازم دارد. همان اصولی که در استاندارد مکتوب کتابخانه‌ی رویت مطرح است، این‌جا هم کاربرد دارد و سه مورد این وضعیت را قابل‌کنترل نگه می‌دارد:

• یک الگوی نام‌گذاری ثابت برای هر گراف که هدف و نسخه‌ی آن را نشان دهد.
• فهرستی از پکیج‌های شخص‌ثالث مورد استفاده، مانند Clockwork یا archi-lab، همراه با نسخه‌ی دقیق هرکدام، برای روزی که یک به‌روزرسانی مشکلی ایجاد می‌کند.
• یادداشتی کوتاه همراه هر گراف که ورودی موردنیاز و خروجی آن را مشخص کند.

پایداری هر گراف به پکیج‌هایی بستگی دارد که از آن‌ها استفاده می‌کند. هر نسخه‌ی رویت با نسخه‌ی مشخصی از Dynamo ارائه می‌شود و پکیج‌ها باید با آن هماهنگ شوند. روشن‌ترین نمونه‌ی اخیر، Revit 2025 است: این نسخه با Dynamo 3.0 ارائه می‌شود که بر پایه‌ی .NET 8 اجرا می‌شود و راهنمای خود Dynamo تصریح می‌کند پکیجی که به .NET 8 منتقل شده، در نسخه‌های قدیمی‌تر Dynamo بارگذاری نمی‌شود. دفتری که Revit 2024 و Revit 2025 را هم‌زمان استفاده می‌کند، ممکن است به دو نسخه از یک پکیج نیاز داشته باشد.

قاعده‌ی عملی از همین‌جا به دست می‌آید. نسخه‌ی Dynamo و پکیج‌هایی را که هر گراف با آن‌ها تست شده ثبت کنید، پیش از انتقال دفتر به نسخه‌ی جدید، کتابخانه‌ی گراف‌ها را در یک پروژه‌ی آزمایشی تست کنید و گراف‌های نسخه‌ی قبلی را برای پروژه‌هایی که در همان نسخه می‌مانند، نگه دارید. نوشته‌ی هزینه‌ی توسعه پلاگین رویت همین تغییر .NET 8 را از سمت افزونه‌ها بررسی می‌کند.

گراف تا زمانی ابزار مناسبی است که اجرای دستی آن از یک پوشه‌ی مشترک قابل‌قبول باشد. زمان این تغییر را می‌توان از سه نشانه تشخیص داد:

• تعداد زیاد کاربران. وقتی کار هر روز توسط افرادی اجرا می‌شود که هرگز Dynamo را باز نمی‌کنند و نسخه‌های فایل .dyn باید روی هر رایانه هماهنگ نگه داشته شوند، توزیع به‌تنهایی به مشکل اصلی تبدیل می‌شود.
• سرعت. Dynamo روی رشته‌ی اصلی رابط کاربری رویت (UI Thread) اجرا می‌شود و در نتیجه، یک گراف سنگین روی مدل بزرگ، رویت را تا پایان اجرا متوقف نگه می‌دارد.
• یکپارچگی یا رابط کاربری. کار به یک پنجره‌ی اختصاصی، اتصال به یک سیستم بیرونی یا قاعده‌ای نیاز دارد که در هر ذخیره‌سازی اعمال شود، کارهایی که گراف به‌طور قابل‌اعتماد انجام نمی‌دهد.

در این مرحله، گراف هدر نمی‌رود. گرافی که ماه‌ها در پروژه‌های واقعی اجرا شده، بهترین مشخصات فنی برای شروع یک پروژه‌ی توسعه پلاگین رویت است، زیرا هر حالت استثنایی که از آن عبور کرده، از پیش در آن ثبت شده است.

اگر اسکریپتی فقط برای یک پروژه لازم است و پس از آن دیگر اجرا نمی‌شود، سفارش توسعه‌ی اختصاصی آن، چه به ما و چه به هر تیم دیگری، منطقی نیست. یک گراف ساده با یک پکیج آماده، یا حتی انجام یک‌باره‌ی کار به‌صورت دستی، ارزان‌تر و سریع‌تر است. توسعه اسکریپت اختصاصی Dynamo زمانی ارزش هزینه‌ی خود را دارد که یک فرآیند مشخص، بارها، توسط افراد مختلف و در پروژه‌های مختلف تکرار شود.

یکی از پروژه‌های خود ما دقیقاً همین الگو را داشت: فرآیندی که به‌صورت دستی حدود دو هفته و گاهی نزدیک به یک ماه طول می‌کشید، پس از تبدیل‌شدن به یک ابزار خودکار، به حدود ۱۰ دقیقه رسید. آنچه از بیرون یک دکمه به نظر می‌رسید، بر اساس همان دکمه ساخته نشده بود، بلکه حاصل هفته‌ها تصمیم کوچک پشت آن بود، همان تصمیم‌هایی که در یک اسکریپت آزمایشی هنوز گرفته نشده‌اند.

اگر در دفتر کسی Dynamo را می‌شناسد و برای نگهداری کتابخانه وقت دارد، گراف‌ها را داخلی بسازید و از کمک بیرونی برای بازبینی یا برای گراف‌هایی استفاده کنید که از توان Dynamo فراتر رفته‌اند. اگر کتابخانه مسئولی ندارد، گراف‌هایی که پس از ارتقای بعدی از کار بیفتند، دیگر اصلاح نمی‌شوند و این همان نقطه‌ای است که باید نگهداری آن‌ها را به کسی سپرد که این کار جزو وظایف اوست، چه یک نیروی جدید و چه تیمی که ابزارهای دیجیتال اختصاصی می‌سازد. چه نام آن را توسعه، ساخت یا طراحی اسکریپت Dynamo بگذارید، آنچه اهمیت دارد، مسئول مشخص برای نگهداری آن است.