Suunnittelun ja koodin välisen kuilun kaventaminen

'Design & Code' on sarja suunnittelusta ja suunnittelukokeista, prosesseista ja oppeista, jotka AirSwap-tiimi on tuonut sinulle.

AirSwapilla meillä on asynkroninen ja iteratiivinen lähestymistapa tuotekehitykseen. Yksi varhaisimmista haasteistamme, joita tapasimme, oli kuitenkin yhdenmukaisen tuoteidentiteetin ylläpitäminen ominaisuustöiden toistojen kautta useiden tuotteiden omistajien keskuudessa. Työskentellessämme AirSwap Token Trader- ja AirSwap -widget-ohjelmien varhaisten versioiden kanssa löysimme nopeasti kourallisen Sketch-tiedostoja - kukin tiedosto sisälsi tarttuvan pussin symboleja ja tyylejä, jotka edustivat tuoteidentiteettimme tilaa kyseisenä ajankohtana. Vaikka tämä toimi alussa, konsolidoidun totuuslähteemme puutteesta kasvoi nopeasti vanhentuneiden tyylien seka useissa lähteissä.

Kun useita tiedostoja ja symboleja oli hajallaan niiden kaikkien välillä, siitä tuli vaivaa hallita johdonmukaista identiteettiä.

Jokainen AirSwap-käyttöliittymäkokemus on kirjoitettu Reakt-kielellä. Alussa meillä oli jaettujen komponenttien hakemisto, tarvittaessa alustava komponenttikirjasto, jolla oli oikeat tyylit, jotka vastasivat tuotteen identiteettiä. Toistetessamme kuitenkin tuotteemme identiteetti muuttui. Uudempien ominaisuuksien suunnittelukomplien tekeminen vaikeutti sen tunnistamista, onko tietty komponentti jo olemassa vai onko se tarpeen toteuttaa. Teimme varhaisen päätöksen käyttää tyylisiä komponentteja, joiden avulla voimme nopeasti iteroida ja rakentaa ominaisuuksia. Tyyliteltyjen komponenttien mukana tullut helppokäyttöisyys oli valtava voitto, mutta se myös antoi meille tahattomasti tehdä joitain huonoja päätöksiä tyylien jatkamisessa. Ilman tiukkoja sääntöjä komponenttien luomisesta tai laajentamisesta, kooditietokantamme tuli nopeasti koti monelle kopioidulle koodille vain pienillä eroilla. Tämä ei vain vähentänyt kehittäjien nopeutta ja lisääntynyttä teknistä velkaa, vaan myös johtanut epäjohdonmukaisuuteen tuoteidentiteetissämme.

Koska suunnittelukompoissa ei ole tarkkaan määriteltyä järjestelmää, monet kooditietokantamme tiedostot toisivat uusia komponentteja, jotka olivat samanlaisia ​​kuin olemassa olevat, tai tekisivät pieniä muutoksia olemassa oleviin komponentteihin.

Etsiessämme ratkaisua näihin ongelmiin olemme äskettäin aloittaneet kokeilun siitä, kuinka kurottaa kuilu suunnittelun ja koodin välillä.

Suunnitteluteknologia

Suunnittelutekniikan idea ei ole mitään uutta. Työkalut, kuten Craft ja Invision, auttavat suunnittelijoita lujittamaan tyylitään ja yhdistämään nämä tiedot kehittäjille. Tämän avulla useat sidosryhmät voivat työskennellä eri ominaisuuksien kanssa ylläpitäen samalla konsolidoitua peruskomponenttien sarjaa tai jaettua komponenttikirjastoa. Tarvitsemme kuitenkin tapaa, jolla ei vain ylläpidetä tasa-arvoisuutta kuvioiden välillä, vaan ylläpidetään pariteettiakin sen välillä, mitkä komponentit muodostavat mallin ja mitä koodissa esiintyy.

Noin vuosi sitten Airbnb: n suunnittelutekniikkatiimi julkaisi avoimen lähdekoodin projektin nimeltä react-sketchapp, jonka avulla Reakt-komponentit voitiin muokata Sketchiksi. React-yhteisö vastasi myönteisesti, ja riittävän pian tyylitellyt komponentit julkaisivat kirjastonsa laajennuksen, tyylitellyt komponentit / primitiivit, tukemalla monikohteiden renderointia (mukaan lukien mallinnus Sketchille). Näistä hankkeista tuli perustavanlaatuisia teknisiä ratkaisuja kohtaamamme epäjohdonmukaisuusongelmiin.

AirSwap-komponenttikirjasto

AirSwap-widgetin tyhjentävän tarkastuksen jälkeen tunnistimme ja luomme luonnoksessa komponenttijoukot, joita oli tarkoitus käyttää kaikissa nykyisissä ja tulevissa ominaisuuksissa. Sitten meillä oli aikaa luoda tämä koko komponenttikirjasto uudelleen Reaktissa käyttämällä tyyliteltyjä komponentteja / alkukkeita perustana. Komponentimme tuotettiin symboleina react-sketchapp -sovelluksen avulla, luomalla malleillemme yhden totuuden lähteen.

Reagoi Sketchille renderoidut komponentit

Komponenttikirjaston luomisesta tuli perusta alustavalle suunnitteluprosessillemme AirSwapissa. Komponenttien suunnittelut tulivat ensin, jota seurasi toteutus. Koska käytimme tyylisiä komponentteja ja reagoi luonnoskuvaan, voimme palauttaa toteutetun koodin takaisin Sketchiin tarkistettavaksi. Hyväksynnän jälkeen renderoiduista komponenteista tulee uusia malleja, jotka ovat valmiita tulevaa tarkistamista varten tarvittaessa.

Komponenttikirjaston useita versioita, jotka on hahmoteltu Sketchiin ja ladattu Figmaan

Kirjoita Figma

Tämä jakso eliminoi erot koodin ja suunnittelun välillä. Löysimme kuitenkin nopeasti tämän ratkaisun lisäedut, kun aloimme tehdä suurimman osan suunnittelutyöstämme Figmassa. Koska suunnittelutyökalumme antavat meille mahdollisuuden luoda Sketch-asiakirjoja komponenttikirjastosta, lähetämme jokaisen uuden version Figmaan. Kommentit ja muutospyynnöt voidaan tehdä vuorovaikutteisesti viimeisimmässä versiossa, joka tarjoaa seuraavaa versiota koskevat tiedot, ja se ladataan vain, kun kaikki aiemmat kommentit on osoitettu. Tämä ei ole täysin saumaton (vielä), mutta se luo käyttöliittymän tarkistusprosessin, joka on informatiivisesti samanlainen kuin GitHubin vetopyynnöt.

Uuden komponenttikirjastomme avulla pilkkataksesi uutta AirSwap Conversational OTC -kauppaa

Lisäksi käyttämällä Figman jaettuja kirjasto-ominaisuuksia, voimme sitten tarjota pääsyn näihin komponentteihin kaikissa suunnittelukomplekseissamme. Suunnittelijoina voimme reaaliajassa tarkastella ja muokata näitä kompodeja yhteistyössä, mikä antaa selkeän kuvan siitä, mitä komponenttia käytetään. Tämä eliminoi täysin arvaukset siitä, onko komponentti jo olemassa, koska komponentin nimi näkyy kuvassa.

Komponentin nimi näkyy kuvassa, joka antaa heti tietoa kehittäjille, jotka katsovat pilkkaa

Mitä seuraavaksi

Jatkamme eteenpäin, aiomme parantaa ja mukauttaa tätä prosessia sopimaan paremmin tuotekehitystyöhömme. Tarvitaan vielä useita manuaalisia ja tehottomia vaiheita.

Yhden suhteen Figma ei tällä hetkellä tarjoa kirjoituskelpoista sovellusliittymää asiakirjoille, mikä vaatii meitä lähettämään luodut Sketch-tiedostot manuaalisesti. Asianmukaisella API-tuella voimme helposti integroida tämän päästä päähän -prosessin jatkuvan integraatioputken kautta. Kuvittelemme tulevaisuutta, jossa CI-putkilinja tuottaa luonnoksen tiedostosta reopan tunnisteesta tai haarasta (tai vielä parempaa, tuottaa alkuperäisiä Figma-objekteja sketchin läpikäynnin sijasta), lataa se tiedosto Figmaan ja linkittää tuloksena olevan asiakirjan vetämiseen pyyntö. Figman kommentit voidaan lähettää ristikkäin GitHubiin tarjoamalla saumatonta viestintää ja palautetta suunnittelun ja koodin välillä.

Lisäksi, vaikka olemme luoneet teknisen perustan komponenttikirjastolle, meidän on vielä määriteltävä käytännölliset säännöt siitä, miten ja milloin meidän on laajennettava komponentteja ja / tai luotava uusia. Mitkä komponenttien ominaisuudet voidaan tarkistaa tapauskohtaisesti, ja milloin suuri määrä muutoksia osoittaa tarpeen luoda uusi komponentti? Meidän on löydettävä luonnolliset vastaukset näihin ongelmiin, mieluiten keksimällä automatisoidut tavat näiden päätösten täytäntöönpanemiseksi.

Tämän uuden komponenttikirjaston avulla olemme huomanneet tuottavuuden ja tehokkuuden lisääntyneen suunnittelusta koodiksi -vaihtoehdoilla. Vaikka tämän uuden prosessin kattava ja täydellinen ominaisuus on kaukana täydellisestä, se on antanut meille mahdollisuuden lisätä työssä etenemisen nopeutta ylläpitäen samalla tuotteen identiteetin korkeaa eheyttä. Suunnittelu ja suunnittelutekniikka ympäröivät keskustelut kehittyvät nopeasti monissa tuoteryhmissä ympäri maailmaa. Suunnittelu on asia, josta välitämme syvästi AirSwapilla, ja suunnittelutekniikasta on tullut jännittävä tuotekehityskohta, jota voimme hyödyntää meille mahtavien tuotteiden toimittamisessa.

  • Tilaa AirSwap-blogi
  • Liity viralliseen kanavaamme Telegramissa
  • Seuraa meitä Twitterissä
  • Löydä meidät Facebookista
  • Tilaa alaluokka