Kuidas ohjeldada kaost tarkvaraarenduses disainisüsteemi ja komponendivaramu abil?

Tavaliselt kipub arendusprojektides ulatuslike muudatuste tegemine poole projekti pealt kujunema üsna ajamahukaks ja annab ka rahaliselt ja muus osas valusasti tunda.

Sellepärast on meie soovitus projekti algusfaasis alati võimalikult palju arvestada olemasoleva infoga. Teisalt on mõistetav, et näiteks agiilses tiimis on kõik (sh eesmärgid ja info) pidevas muutumises. Vastavalt sellele, kuidas kõike seda projekti jooksul hallatakse, jagunevad front-end arendajad tinglikult kolme koolkonda:

Olemasolevate süsteemide kasutamisel saab võrdlemisi kiiresti asjaga algust teha. Tegelema peab põhiliselt ainult funktsionaalsuse väljaehitamise ja n-ö suure pildi arendusega. Seepärast on väliste komponendivaramute kasutamine ideaalne prototüüpimiseks, ideede proovimiseks ja MVPdeks.

Kuna kogu tiimi peale on kokku teatud hulk ressursse - vaimset võimekust ja aega, siis aitab väliste komponendivaramute kasutamine suuresti kaasa päris probleemide lahendamisele ja suure pildi kokku panekule. Tiim saab keskenduda äriloogilistele ülesannetele ega pea enam niivõrd panustama interaktsioonidesse ja visuaalsesse poolde.

Väliste komponendivaramute ja disainisüsteemide puhul , mille käekäiku mõjutada ei saa, peab arvesse võtma nende eripärasid ja mustreid juba disainis ja analüüsis. Visuaalse poole ülekirjutamine ei pruugi olla väga lihtne ja tulevikus võivad üle kirjutatud mustrid katki minna, eriti kui vajadustele vastavaks kohendamisel kasutatakse rätseplahendusi.

Lisaks ei pruugi aja möödudes komponent enam vastata funktsionaalsetele nõuetele ja valik tuleb teha kolme suuna vahel:

Disainisüsteemi ja sellega kaasneva komponendivaramu ehitamine otsast peale on kindlasti kulukam ja mahukam töö, kui osaliselt valmis süsteemi kohendamine. Ise ehitamise suureks plussiks on aga täielik kontroll visuaalide ja funktsionaalsuse üle, sest ehitatav süsteem ise ja ka nõudmised on sageli ajas muutuvad.

Komponendivaramut kasutavad arendajad (ja eriti just nooremarendajad) ei pea muretsema erinevate UI funktsionaalsuste implementeerimise pärast, vaid saavad keskenduda äriloogilistele probleemidele ja komponentide integreerimisele. Sellest tulenevalt on lihtsam kaasata ka erineva tasemega arendajaid.

Komponendivaramu ehitamine erineb üsna palju igapäevastest arendustegevustest, sest seal püütakse lisaks kasutajate omadele lahendada ka arendajate probleeme. Praktika näitab, et kõigile arendajatele teekide ehitamine ei sobigi. Näiteks kui sinu disainisüsteemil ja komponentidel puudub loogika või neid on keeruline kasutada ja panna oma funktsiooni täitma, siis loobuvad arendustiimid nende kasutamisest üsna kiiresti.

Paraku ehitavad need arendustiimid sageli ise identse süsteemi ning paari aastaga tekib ühest ja samast asjast mitu erinevat omavahel võistlevat versiooni. Kindel on aga see, et mida kogenum spetsialist teeki ehitab, seda kasulikum tööriist arendustiimide jaoks valmib. Nagu iga arendusprojekti puhul, on siingi oluline järgida häid arendusprintsiipe, hoida skoopi ja mõelda ka tuleviku peale.

Kui otsustad ise ehitada, siis esimene ülesanne on luua inventar kõige sagedamini kasutatavatest komponentidest. Rakenduste ja veebide puhul, mis pole algusest peale komponentide peale üles ehitatud, peab keegi kõik manuaalselt läbi käima ning otsima korduvaid mustreid ja komponente. Mustrite ja komponentide inventuuri tegemisest on kirjutanud näiteks Nathan Curtis ja Brad Frost.