Projekt atomowy

Projektowanie atomowe to metodologia konstruowania systemów interfejsów poprzez łączenie małych, wielokrotnego użytku elementów w coraz większe struktury. Wprowadzona przez Brada Frosta w 2013 roku, zapożycza metaforę chemiczną i definiuje pięć poziomów: atomy – najmniejsze niepodzielne elementy, takie jak etykiety, pola wejściowe i przyciski; cząsteczki – proste grupy, takie jak pole wyszukiwania z etykietą i przyciskiem; organizmy – bardziej złożone elementy, takie jak nagłówek witryny lub karta produktu; szablony – struktury stron z symbolami zastępczymi treści; oraz strony – szablony wypełnione rzeczywistą treścią.

Wkładem tej metodologii jest wspólny słownik decyzji, którą każdy zespół ds. interfejsu podejmuje niejawnie: co jest komponentem, co kompozycją i gdzie zaczyna się ponowne wykorzystanie. Bez ram, zespoły tworzą ekrany indywidualnie, powielają podobne elementy z drobnymi modyfikacjami, a w efekcie powstają dziesiątki subtelnie różniących się przycisków i kart, które należy utrzymywać. Projektowanie atomowe zapewnia strukturę do identyfikacji jednostek wielokrotnego użytku i decydowania, do którego poziomu przynależy dany element interfejsu.

Praktyczne korzyści z tego rozwiązania ujawniają się w fazie konserwacji, a nie w początkowej wersji. Zmiana elementu bazowego aktualizuje wszystko, co się z niego składa, więc zmiana stylu lub odstępów między elementami jest spójna i nie wymaga przeszukiwania bazy kodu. Nowe ekrany można tworzyć z istniejących fragmentów, co skraca czas realizacji i zmniejsza liczbę decyzji wymaganych przy każdej nowej stronie. Prace nad zapewnieniem jakości i dostępnością koncentrują się na poziomie komponentów, gdzie pojedyncza, poprawna implementacja spełnia wszystkie wymagania, a nie jest powtarzana na każdej stronie.

Metodologia spotyka się z uzasadnioną krytyką, głównie dotyczącą dosłowności. Zespoły poświęcają nieproporcjonalnie dużo wysiłku na debatę nad tym, czy dany pierwiastek jest cząsteczką, czy organizmem, co jest argumentem taksonomicznym bez praktycznych konsekwencji. Metafora chemiczna zawodzi również na granicach i jest słabo zrozumiała dla osób niebędących projektantami. Większość doświadczonych zespołów traktuje poziomy jako luźny przewodnik, często sprowadzając je do prostszych rozróżnień, takich jak prymitywy, komponenty i wzorce, i koncentruje się na podstawowej zasadzie kompozycji, a nie na poprawnej klasyfikacji.

Nadmierna abstrakcja stanowi poważniejsze ryzyko. Budowa biblioteki komponentów przed ustaleniem faktycznych potrzeb produktu prowadzi do powstania komponentów zaprojektowanych do wyimaginowanych przypadków, z nadmiarem opcji konfiguracji i niejasnym przeznaczeniem. Bardziej niezawodną metodą jest budowanie ekranów, obserwowanie rzeczywistych powtórzeń i wyodrębnianie komponentów po kilkukrotnym wystąpieniu wzorca w rzeczywistym użyciu. Przedwczesna abstrakcja jest trudniejsza do wyeliminowania niż duplikacja, ponieważ każdy użytkownik komponentu ogranicza jego możliwości zmian.

Wartość metodologii w dużej mierze zależy od zarządzania, którego sama nie zapewnia. Biblioteka komponentów bez jasno określonych praw własności, reguł dotyczących wkładu i procesu wycofywania akumuluje warianty: trzy nieznacznie różniące się karty, dwa komponenty przycisków o nakładających się celach oraz rosnący zestaw jednorazowych nadpisań zastosowanych, ponieważ istniejący komponent prawie pasował. Decyzja o tym, kto zatwierdza nowe komponenty, w jaki sposób zespół wnioskuje o zmianę współdzielonego komponentu i jak usunąć przestarzały wzorzec z istniejącego użycia, ma większe znaczenie dla długoterminowej spójności niż taksonomia. Organizacje, które wdrożyły takie zarządzanie, uważają, że biblioteka z czasem redukuje nakład pracy; te, które tego nie robią, uważają, że staje się ona kolejną niespójną powierzchnią wymagającą konserwacji obok kodu, który miała uprościć.

W kontekście realizacji podejście to sprawdza się najlepiej, gdy biblioteka projektowa i biblioteka kodu są ze sobą spójne, tak aby komponent w narzędziu projektowym miał jedną implementację o tej samej nazwie i tych samych wariantach. Ustalenie, że zgodność jest wspólną odpowiedzialnością wszystkich projekt produktu oraz rozwój produktówi to właśnie decyduje, czy system projektowania zmniejsza nakład pracy, czy też po prostu dodaje drugi artefakt do utrzymania obok kodu.