Jak unikać chaosu w Dynamo: graf, który da się utrzymać po pół roku

Dynamo potrafi oszczędzić godziny pracy, ale potrafi też zamienić się w labirynt przewodów, wyjątków i założeń, których nikt już nie pamięta. Największym problemem nie jest samo zbudowanie automatyzacji. Problem zaczyna się wtedy, gdy graf ma działać na kolejnych projektach, z innymi modelami i po kilku miesiącach przerwy.

Chaos zaczyna się od niewidocznych założeń

Wiele grafów wygląda dobrze w dniu powstania, bo autor pamięta cały kontekst: które widoki mają być wybrane, jaki parametr jest zawsze wypełniony, dlaczego lista jest sortowana akurat w tym miejscu i czemu jeden wyjątek został obsłużony ręcznie. Po czasie te założenia znikają z głowy, ale zostają w grafie. Jeżeli nie są nazwane, opisane i sprawdzone, automatyzacja staje się krucha.

Dlatego porządek w Dynamo nie jest kwestią estetyki. To element bezpieczeństwa pracy z modelem. Czytelny graf pozwala szybciej znaleźć błąd, spokojniej przekazać narzędzie komuś innemu i łatwiej zdecydować, czy automatyzacja nadaje się jeszcze do użycia na nowym projekcie.

1. Nazwa grupy powinna mówić, co wchodzi i co wychodzi

Grupy typu Inputs, Filter albo Calc są zrozumiałe tylko przez chwilę. Lepiej opisywać etap działania: Rooms | Filter by phase | Valid room set, Views | Build sheet names | Candidate names, Elements | Check required parameters | Missing values report. Taka nazwa od razu mówi, czy grupa wybiera dane, przekształca je, czy przygotowuje wynik.

Dobrze działa też zasada jednego języka. Jeżeli cały projekt używa polskich nazw parametrów i opisów, graf może być po polsku. Jeżeli narzędzia mają być przekazywane szerzej albo łączone z dokumentacją techniczną, angielski bywa praktyczniejszy. Najgorsza jest mieszanka przypadkowa, bo później trudno wyszukiwać, filtrować i utrzymywać opisy.

2. Jeden blok, jedna odpowiedzialność

Najbardziej zdradliwe są grupy, które robią zbyt wiele naraz: pobierają elementy, filtrują, sortują, zmieniają parametry i eksportują raport. Taki blok jest szybki do zbudowania, ale trudny do naprawy. Kiedy wynik jest zły, nie wiadomo, czy problem jest w wyborze elementów, logice listy, pustych wartościach, mapowaniu parametrów czy końcowym zapisie.

Lepszy graf może być dłuższy wizualnie, ale spokojniejszy mentalnie. Osobno pobieranie danych, osobno walidacja, osobno transformacja, osobno zapis. Wtedy użytkownik widzi ścieżkę myślenia, a nie tylko gęstą pajęczynę przewodów.

3. Punkty kontrolne są ważniejsze niż efektowny output

Każdy ważny etap powinien zostawiać po sobie prosty ślad: liczbę elementów, podgląd kilku wartości, listę błędów albo komunikat, że dane wejściowe są puste. To są małe punkty kontrolne, które ratują czas przy debugowaniu. Jeżeli graf nagle zwraca zły raport, można sprawdzić, w którym miejscu liczba elementów spadła do zera albo gdzie pojawiły się wartości null.

W praktyce dobrze sprawdzają się trzy poziomy kontroli: szybki licznik, podgląd przykładowych danych oraz raport problemów. Licznik mówi, czy coś w ogóle przyszło. Podgląd pokazuje, czy dane mają sens. Raport problemów pozwala użytkownikowi zareagować bez otwierania całego grafu.

4. Wejścia użytkownika powinny być ograniczone

Zbyt wiele suwaków, przełączników i ręcznie wybieranych elementów sprawia, że graf zaczyna być formularzem bez instrukcji. Użytkownik nie wie, które pole jest obowiązkowe, które jest ustawieniem technicznym, a które może spokojnie zostawić bez zmian. W małej automatyzacji lepiej mieć mniej opcji, ale dobrze opisanych.

Jeżeli dana wartość nie jest decyzją użytkownika, tylko częścią logiki, nie powinna leżeć na pierwszym planie. Można ją zamknąć w grupie technicznej i opisać komentarzem. Dzięki temu osoba odpalająca graf widzi tylko te rzeczy, za które faktycznie odpowiada.

5. Wersjonowanie grafu jest normalną częścią pracy

Graf Dynamo jest narzędziem, a narzędzie zmienia się w czasie. Warto więc traktować je trochę jak kod: numer wersji, krótki changelog, informacja o autorze i data ostatniej zmiany. Nie chodzi o biurokrację. Chodzi o to, żeby po kwartale wiedzieć, czy dany graf obsługuje nowy przypadek, czy tylko przypadkiem działał na jednym modelu.

• v1.0.0 - pierwsza stabilna wersja użyta na projekcie.
• v1.1.0 - dodana obsługa nowego parametru albo nowego typu elementu.
• v1.1.1 - poprawka błędu bez zmiany działania dla użytkownika.
• v2.0.0 - zmiana, która może wymagać innego sposobu użycia grafu.

6. Komentarz ma tłumaczyć decyzję, nie noda

Komentarz „sortuję listę” niewiele wnosi, bo to widać z samego grafu. Dużo lepszy komentarz brzmi: „sortowanie po numerze pomieszczenia przed grupowaniem, bo kolejność z modelu zmienia się między sesjami”. Taki opis tłumaczy decyzję i ryzyko, a nie oczywisty ruch techniczny.

Najbardziej wartościowe komentarze pojawiają się przy miejscach kruchych: filtrowaniu po nazwie, konwersji jednostek, zaokrągleniach, obsłudze pustych wartości, odwołaniach do parametrów współdzielonych i fragmentach, które zależą od standardu konkretnego biura. To tam przyszły użytkownik będzie potrzebował kontekstu.

7. Graf powinien mieć scenariusz awaryjny

Automatyzacja nie powinna udawać, że wszystko jest dobrze, gdy dane wejściowe są słabe. Jeżeli brakuje parametru, warto pokazać raport braków. Jeżeli lista elementów jest pusta, lepiej zatrzymać działanie niż zapisać pusty wynik. Jeżeli graf ma modyfikować model, powinien jasno pokazywać, co zostanie zmienione.

To szczególnie ważne przy narzędziach, które zapisują wartości do Revita. Odczyt może być eksperymentalny. Zapis powinien być spokojny, przewidywalny i odwracalny. Dobrą praktyką jest najpierw tryb raportu, a dopiero później tryb zapisu.

Połączenie z większym standardem BIM

Dynamo nie żyje w próżni. Jeżeli w biurze nie ma jasnych zasad nazewnictwa, parametrów i odpowiedzialności, grafy zaczynają łatać chaos zamiast go ograniczać. Automatyzacja jest wtedy coraz bardziej skomplikowana, bo musi obsługiwać wszystkie wyjątki, które wynikają z braku standardu.

Najlepsze grafy są proste, ponieważ stoją na jasnym procesie. Wiadomo, skąd biorą dane, jak sprawdzają błędy, co zapisują i kto odpowiada za wynik. Wtedy Dynamo przestaje być magicznym guzikiem, a staje się normalnym narzędziem projektowym.

Podsumowanie

Chaos w Dynamo najczęściej nie bierze się z braku wiedzy technicznej. Bierze się z pośpiechu, niewidocznych założeń i braku utrzymania. Kilka prostych zasad zmienia bardzo dużo: czytelne grupy, jedna odpowiedzialność na blok, punkty kontrolne, ograniczone wejścia, wersjonowanie, komentarze wyjaśniające decyzje i scenariusz awaryjny. Dzięki temu graf może nadal pomagać po pół roku, zamiast stać się kolejnym plikiem, którego nikt nie chce otwierać.