Atomtervezés

Az atomtervezés egy olyan módszertan, amely interfészrendszereket hoz létre apró, újrafelhasználható darabok fokozatosan nagyobb struktúrákká történő összeállításával. Brad Frost vezette be 2013-ban, egy kémiai metaforát kölcsönözve, és öt szintet határoz meg: atomok, a legkisebb oszthatatlan elemek, mint például a címkék, bemenetek és gombok; molekulák, egyszerű csoportok, mint például egy keresőmező a hozzá tartozó címkével és gombbal; organizmusok, összetettebb összeállítások, mint például egy webhely fejléce vagy egy termékkártya; sablonok, oldalszerkezetek tartalomhelykitöltőkkel; és oldalak, valódi tartalommal feltöltött sablonok.

A módszertan hozzájárulása egy közös szókincs egy olyan döntéshez, amelyet minden interfészcsapat implicit módon meghoz: mi a komponens, mi a kompozíció, és hol kezdődik az újrafelhasználás. Keretrendszer nélkül a csapatok egyénileg építik a képernyőket, hasonló elemeket másolnak apró változtatásokkal, és tucatnyi finoman eltérő gombbal és kártyával végződnek, amelyeket mindegyiket karban kell tartani. Az atomi tervezés egy struktúrát biztosít az újrafelhasználható egységek azonosítására és annak eldöntésére, hogy az interfész egy adott része melyik szinthez tartozik.

Gyakorlati előnyei inkább a karbantartásban, mint a kezdeti buildben mutatkoznak meg. Egy alapelem megváltoztatása frissíti az abból összeállított összes elemet, így a fókuszstílus vagy a térköz megváltoztatása következetesen terjed, ahelyett, hogy a kódbázisban kellene keresgélni. Az új képernyők meglévő darabokból állíthatók össze, ami lerövidíti a szállítási időt és csökkenti az egyes új oldalakhoz szükséges döntések számát. A minőségbiztosítási és akadálymentesítési munka a komponensek szintjén koncentrálódik, ahol egyetlen helyes implementáció minden felhasználást szolgál, ahelyett, hogy oldalonként ismétlődne.

A módszertan jogos kritikákat vált ki, főként a szó szerinti értelmezés miatt. A csapatok aránytalanul sok energiát fordítanak annak megvitatására, hogy egy adott elem molekula vagy organizmus-e, ami egy taxonómiai érv, amelynek nincs gyakorlati következménye. A kémiai metafora a határokon is felbomlik, és rosszul kommunikál a nem tervezők számára. A legtöbb tapasztalt csapat laza útmutatóként kezeli a szinteket, gyakran egyszerűbb megkülönböztetésekre, például primitívekre, komponensekre és mintázatokra bontja azokat, és az összetétel alapelvére összpontosít a helyes osztályozás helyett.

A túlzott absztrakció komolyabb kockázatot jelent. Ha egy komponenskönyvtárat anélkül építünk fel, hogy tudnánk, mire van valójában szüksége a terméknek, az elképzelt esetekre tervezett komponenseket eredményez, túlzott konfigurációs lehetőségekkel és nem egyértelmű célokkal. A megbízhatóbb sorrend a képernyők felépítése, a valódi ismétlődések észrevétele és a komponensek kinyerése, miután a minta többször is megjelent a valós használatban. A korai absztrakciót nehezebb feloldani, mint a duplikációt, mert egy komponens minden felhasználója korlátozza, hogyan változhat.

A módszertan értéke nagymértékben függ az irányítástól, amelyet maga nem biztosít. Egy egyértelmű tulajdonjog, közreműködési szabályok és elavulási folyamat nélküli komponenskönyvtár variánsokat halmoz fel: három kissé eltérő kártyát, két átfedésben lévő célú gombkomponenst, és egyre növekvő számú egyszeri felülbírálást, amelyeket azért alkalmaznak, mert a meglévő komponens majdnem illeszkedett. A hosszú távú konzisztencia szempontjából fontosabb eldönteni, hogy ki hagyja jóvá az új komponenseket, hogyan kér egy csapat módosítást egy megosztott komponensen, és hogyan távolít el egy elavult mintát a meglévő használatból, mint a taxonómia. Azok a szervezetek, amelyek ezt az irányítást bevezetik, azt tapasztalják, hogy a könyvtár idővel csökkenti a munkát; azok, akik nem találják, egy újabb inkonzisztens felületté válik, amely karbantartást igényel a kód mellett, amelyet egyszerűsíteni szántak.

Szállítási szempontból a megközelítés akkor működik a legjobban, ha a tervezőkönyvtár és a kódkönyvtár egymáshoz illeszkedik, így a tervezőeszközben lévő komponens egyetlen implementációval rendelkezik, ugyanazzal a névvel és ugyanazokkal a változatokkal. Ennek az megfelelésnek a megállapítása közös felelősség. termék dizájn és a termékfejlesztés, és ez határozza meg, hogy egy tervezőrendszer csökkenti-e a munkát, vagy egyszerűen csak egy második műterméket ad hozzá a kódhoz, amelyet a kód mellett kell karbantartani.