توسعه اسکریپت اختصاصی داینامو یعنی ساختن یک گرافی که یک فرایند مشخص و تکراری رویت را با همان دقتی که یک آدم انجام میدهد، انجام بدهد؛ نه فقط اتصال چند نود آماده به هم برای یک نتیجه یکباره. تفاوت بین این دو خیلی بیشتر از ظاهرشان است. گرافی که یکبار روی یک پروژه کار میکند یک آزمایش است. گرافی که ماه بعد، روی پروژه بعدی، با تیم بعدی هم همان‌طور کار میکند، یک ابزار است. اکثر دفاتر جایی بین این دو گیر می‌کنند: یک نفر یک گراف نیمه‌کاره ساخته، فقط خودش می‌داند چطور اجرایش کند، و وقتی آن نفر مرخصی می‌رود، همه به روش قدیمی و دستی برمی‌گردند. توسعه اسکریپت اختصاصی داینامو دقیقاً همین شکاف را می‌بندد: نه با پیچیده‌ترکردن ابزار، بلکه با ساختن گرافی که کسی غیر از سازنده‌اش هم بتواند به آن اعتماد کند.
اسکریپت داینامو دقیقاً چه چیزی جایگزین میکند
داینامو یک محیط برنامهنویسی بصری است که با اتصال نودها به هم، به Revit API دسترسی میدهد بدون آنکه لازم باشد یک خط کد نوشته شود. این یعنی کاری که در حالت عادی باید در رویت با کلیک‌های تکراری انجام شود، حالا می‌تواند به‌عنوان یک گراف قابل‌اجرا و قابل‌اشتراک تعریف شود.
چیزی که این ابزار واقعاً جایگزین میکند، زمان تکرار دستی است، نه مهارت انسانی. یک نفر که می‌داند چطور شیت‌ها را مرتب کند، همچنان باید بداند شیت‌ها چطور باید مرتب شوند؛ فقط دیگر مجبور نیست هر بار آن را با دست انجام دهد. گرافی که این منطق را درست ثبت کرده باشد، همان تصمیم را بدون خطای انسانی و بدون افت تمرکز در ساعت آخر روز تکرار میکند.
جایی که اتوماسیون اول جواب میدهد: شیت و مستندسازی
مرتب‌سازی شیت، نام‌گذاری ویو و چیدمان لیجند معمولاً اولین جایی هستند که یک دفتر ارزش خودکارسازی را حس میکند، چون این کارها هم زیاد تکرار می‌شوند و هم قانون واضحی دارند: یک شماره‌گذاری مشخص، یک ترتیب مشخص، یک قالب مشخص. همین وضوح باعث میشود ساخت یک گراف داینامو برایشان کم‌ریسک‌تر از کارهای طراحی‌محور باشد.
همین‌جاست که خدمات اسکریپتنویسی داینامو معمولاً از ارزش خودشان دفاع می‌کنند: یک فرایند مستندسازی که هر بار سی تا چهل دقیقه طول می‌کشد، وقتی به یک گراف تبدیل شود، به چند دقیقه اجرای خودکار می‌رسد، و آن چند دقیقه هربار دقیقاً همان قانون را دنبال میکند، نه نسخه‌ای که هرکس به سلیقه خودش تفسیر کرده.
کنترل کیفیت و بررسی مدل با داینامو
داینامو می‌تواند مثل یک بازرس خودکار عمل کند: مدل را اسکن کند، پارامترهای خالی یا عناصر بدون تگ را پیدا کند، و حتی برخی خطاها را خودش اصلاح کند. این دقیقاً همان منطقی است که چک‌کننده مدل رویت به آن می‌پردازد؛ تفاوت اینجاست که یک گراف اختصاصی، برخلاف یک ابزار عمومی، دقیقاً همان قواعدی را چک میکند که استاندارد داخلی همان دفتر تعریف کرده.
ریسک این بخش این است که یک گراف کنترل کیفیت که خودش تست نشده، خطاهای غلط تولید میکند و اعتماد به کل ابزار را از بین می‌برد. یک گراف بازرسی باید روی چند مدل واقعی و متفاوت امتحان شود، نه فقط روی همان مدلی که برایش نوشته شده.
جانمایی تکراری: فمیلی، والپست و نازک‌کاری
جانمایی خودکار فمیلی در طول محیط اتاق، ساخت والپست بر اساس نوع دیوار، یا اجرای نازک‌کاری خودکار بر اساس جدول اتاق، همه یک الگوی مشترک دارند: قانون از قبل در دیتای پروژه وجود دارد (نوع اتاق، نوع دیوار، فینیش موردنیاز)، فقط کسی باید آن را یکبار به‌صورت منطق بنویسد.
این‌جا جایی است که تفاوت بین یک گراف آزمایشی و یک ابزار واقعی بیشترین اهمیت را دارد. جانمایی خودکار روی یک اتاق مربعی ساده کار میکند؛ روی یک اتاق با شکل نامنظم، یا اتاقی با چند بازشو، ممکن است شکست بخورد. گرافی که فقط حالت ساده را پوشش میدهد، در عمل هر بار به یک بررسی دستی نیاز دارد که خودش همان زمانی را می‌گیرد که قرار بود صرفه‌جویی شود.
کد پایتون: وقتی برنامهنویسی بصری کافی نیست
نودهای بصری برای اکثر منطق‌های خطی کافی‌اند، اما هر جا منطق شرطی پیچیده، حلقه‌های تودرتو یا دسترسی مستقیم به بخش‌هایی از Revit API که نود آماده‌ای ندارند لازم شود، یک نود پایتون داخل همان گراف، سریعتر و قابل‌نگهداری‌تر از زنجیره‌ای طولانی از نودهای بصری است.
این به‌معنای رهاکردن داینامو نیست؛ به‌معنای استفاده از آن به‌عنوان یک لایه‌ی گلو بین رابط بصری و منطق واقعی است. یک تیم که هم برنامهنویسی بصری و هم Revit API را می‌شناسد، می‌تواند تصمیم بگیرد کجا نود کافی است و کجا چند خط کد پایتون همان کار را با نگهداری کمتر انجام میدهد.
پکیجهای سفارشی و مرتب‌نگه‌داشتن کتابخانه اسکریپت
همان‌طور که یک کتابخانه فمیلی بدون استاندارد نام‌گذاری شلوغ میشود، یک کتابخانه گراف داینامو هم بدون سازمان‌دهی همین سرنوشت را پیدا میکند: نسخه‌های مختلف یک گراف با نام‌های نزدیک به هم، پکیجهای شخصثالثی که دیگر بهروزرسانی نمی‌شوند، و گرافی که فقط سازنده‌اش می‌داند دقیقاً چه ورودی‌ای انتظار دارد.
سه چیز این وضعیت را کنترل میکند:
- یک نام‌گذاری ثابت برای هر گراف که هدف و نسخه را نشان میدهد.
- فهرستی از پکیجهای شخص‌ثالث مورد استفاده (مثل Clockwork یا archi-lab) با نسخه دقیق، برای وقتی که یک بهروزرسانی چیزی را می‌شکند.
- یک یادداشت کوتاه کنار هر گراف که می‌گوید چه ورودی‌ای انتظار می‌رود و چه خروجی‌ای تولید میکند.
کِی یک اسکریپت باید به افزونه کامپایل‌شده تبدیل شود
یک گراف داینامو وقتی جواب میدهد که اجرایش دستی، از سمت یک نفر آشنا با ابزار، قابل‌قبول باشد. وقتی همان فرایند باید توسط چند نفر مختلف، بدون شناخت داینامو، هر روز اجرا شود؛ یا وقتی زمان اجرا برای یک گراف بصری غیرقابل‌قبول کند میشود؛ آن‌وقت زمان تبدیل آن به یک افزونه کامپایل‌شده رسیده است. همین مسیر را توسعه پلاگین اختصاصی رویت با جزئیات بیشتری پوشش میدهد.
این تصمیم فقط درباره سرعت نیست؛ درباره پایداری در برابر بهروزرسانی رویت هم هست. یک گراف داینامو معمولاً به نسخه‌ای از یک پکیج شخص‌ثالث وابسته است که ممکن است با هر ارتقای رویت نشکند، اما ممکن هم هست بشکند. یک افزونه کامپایل‌شده در برابر Revit API نسخه‌بندی‌شده کامپایل میشود و این وابستگی را قابل‌پیش‌بینی‌تر میکند، هرچند به‌قیمت زمان توسعه بیشتر تمام میشود.
داخلی بسازید یا کمک بیرونی بگیرید
اگر یک اسکریپت فقط برای یک پروژه خاص لازم است و بعد از تحویل آن پروژه دیگر استفاده نمی‌شود، سفارش‌دادن توسعه اختصاصی آن معنا ندارد؛ یک گراف ساده از یک پکیج آماده یا حتی یک بار انجام دستی همان کار، ارزانتر و سریعتر تمام میشود. توسعه اسکریپت اختصاصی داینامو ارزشش را وقتی نشان میدهد که همان فرایند بارها، توسط افراد مختلف، در پروژههای مختلف تکرار میشود.
یک پروژه سابق تیم ما درست همین الگو را داشت: فرایندی که به‌صورت دستی حدود دو هفته و گاهی نزدیک به یک ماه طول می‌کشید، بعد از تبدیل‌شدن به یک ابزار خودکار، به حدود ده دقیقه رسید. چیزی که از بیرون یک دکمه ساده به‌نظر می‌رسد، هیچ‌وقت بر اساس همان دکمه قیمت نمی‌خورد؛ بر اساس هفته‌هایی از تصمیم‌های ریز پشت آن دکمه قیمت می‌خورد، همان تصمیم‌هایی که یک اسکریپت آزمایشی هنوز آن‌ها را نگرفته.
توسعه اسکریپت اختصاصی داینامو زمانی ارزش واقعی خودش را نشان میدهد که یک فرایند مشخص، تکرارشونده و قانونمند پیدا شود، نه وقتی هدف صرفاً «داشتن یک اتوماسیون» باشد. گرافی که روی چند مدل واقعی تست شده، مستند شده و مرز مشخصی بین آنچه داینامو انجام میدهد و آنچه باید به یک افزونه کامپایل‌شده برسد دارد، همان چیزی است که یک بار ساخته میشود و سال‌ها کار میکند؛ نه چیزی که هر چند ماه دوباره باید ساخته شود.
مطالب مرتبط
پرسش‌های متداول
اسکریپت داینامو در رویت دقیقاً چیست؟
یک گراف از نودهای متصل به هم است که با استفاده از Revit API یک فرایند مشخص را در رویت اجرا میکند، بدون آنکه لازم باشد آن فرایند هر بار با دست انجام شود. خروجی می‌تواند از مرتب‌سازی شیت تا بررسی کیفیت مدل باشد.
آیا اسکریپتنویسی داینامو همان برنامهنویسی با Revit API است؟
نه دقیقاً. داینامو یک لایه بصری روی بخشی از Revit API است. برای منطق‌های ساده و خطی همین لایه کافی است؛ برای منطق پیچیده‌تر یا دسترسی به بخش‌هایی که نود آماده ندارند، یک نود پایتون داخل همان گراف یا توسعه یک افزونه کامل لازم میشود.
آیا اسکریپت داینامو بعد از هر بهروزرسانی رویت هم کار میکند؟
همیشه تضمینشده نیست. اگر گراف به پکیجهای شخصثالثی وابسته باشد که با نسخه جدید رویت هماهنگ نشده باشند، ممکن است بشکند. مستندسازی نسخه دقیق هر پکیج و تستکردن گراف بعد از هر ارتقا، ریسک را کم میکند نه صفر.
چه زمانی یک اسکریپت داینامو باید به یک افزونه کامپایل‌شده تبدیل شود؟
وقتی فرایند باید توسط افراد بدون شناخت داینامو اجرا شود، وقتی سرعت اجرای گراف بصری کند میشود، یا وقتی پایداری در برابر به‌روزرسانی‌های رویت اهمیت بیشتری از سرعت توسعه پیدا میکند.
آیا برای اسکریپتنویسی داینامو حتماً باید برنامهنویس استخدام کنیم؟
برای یک گراف ساده و یکباره، نه. برای گرافی که بارها در پروژههای مختلف استفاده میشود و باید در برابر دادههای واقعی و نامنظم پایدار بماند، تجربهای که هم Revit API و هم منطق برنامهنویسی را بشناسد، نتیجه را قابلاعتمادتر میکند.
هزینه توسعه اسکریپت اختصاصی داینامو به چه چیزی بستگی دارد؟
به پیچیدگی منطق، تعداد حالتهای استثنا که باید پوشش داده شوند، و میزان تست لازم روی مدلهای واقعی بستگی دارد؛ نه به تعداد نودهای روی صفحه. گرافی که فقط حالت ساده را پوشش میدهد ارزانتر است اما در عمل کمتر قابلاعتماد است.
چه زمانی اصلاً نباید سراغ توسعه اسکریپت اختصاصی برویم؟
وقتی فرایند فقط یکبار، برای یک پروژه خاص لازم است. در آن حالت یک گراف ساده از یک پکیج آماده یا حتی انجام دستی همان کار، ارزانتر و سریعتر از سفارش توسعه اختصاصی است.