Solutional
Keeruline tarkvara sünnib sageli ka siis, kui äri pole seda kunagi küsinud. Üks levinud põhjus on see, et arendusmeeskond keskendub tehnoloogiavalikutele rohkem kui probleemile, mida tarkvara lahendama peaks.
Arhitektuur ja tööriistad mõjutavad palju enamat kui esimest arendusfaasi. Need määravad uute funktsioonide lisamise kiiruse, toodanguvigade hulga, juurutuse keerukuse ning selle, kui kiiresti saab intsidente analüüsida ja lahendada.
Lihtsa, tõhusa, töökindla ja hõlpsasti laiendatava süsteemi loomine on raske. See nõuab kogemust, distsipliini ja valmisolekut oma eelistusi kriitiliselt hinnata.
Kuidas tarkvara muutub tarbetult keeruliseks
Projekti alguses valitakse tehnoloogiaid vahel populaarsuse järgi. Loogika kõlab: „Kui teised seda kasutavad, peab see olema hea valik ka meile.“
Nii võivad SPA raamistikud nagu React või Vue, mikroteenused, Kubernetes ja AWS jõuda projekti enne, kui äriprobleem on põhjalikult mõistetud.
Oluline küsimus ei ole, kas tehnoloogia on moodne või levinud. Küsimus on, kas projektis eksisteerib probleem, mida see lahendab. Iga lisakomponent võib suurendada arenduse, testimise, juurutuse, monitooringu, intsidentide lahendamise ja tulevaste uuenduste kulu.
Klient võib konkreetset tehnoloogiat soovida seetõttu, et on kuulnud edukate ettevõtete kogemustest. Sama valik ei pruugi sobida teise organisatsiooni, toote, mahu või meeskonna jaoks. Avalikud edulood kirjeldavad tavaliselt eeliseid põhjalikumalt kui kasutuskulusid ja ebaõnnestunud katseid.
Keerukust lisab ka õppimine õppimise pärast. Arendajatel on loomulik soov uusi tööriistu proovida, kuid kliendiprojekt ei tohiks muutuda tehnoloogiaeksperimendiks, kui katsetamine ei toeta ärilist eesmärki ja riskid pole teadlikult vastu võetud.
Kuidas luua lihtsamat tarkvara
Ära vali tehnoloogiat harjumuse või populaarsuse järgi. Hinda iga otsust konkreetse probleemi, meeskonna ja süsteemi eeldatava eluea põhjal.
Kasulikud küsimused on:
- Millist probleemi see tehnoloogia lahendab?
- Kas see probleem eksisteerib selles projektis praegu?
- Kas sama tulemuseni jõuab lihtsamalt?
- Kas funktsionaalsete nõuete väike muutus eemaldaks vajaduse täielikult?
- Kui palju lisab valik keerukust arendusse, testimisse, juurutusse, monitooringusse ja intsidentide lahendamisse?
- Kui küps ja hooldatav tehnoloogia on?
- Milliseid uuendusi või migratsioone tuleb tulevikus teha?
- Kui raske oleks tehnoloogia hiljem asendada või eemaldada?
Praktiline rusikareegel on, et igal tehnoloogiavalikul on nii eelised kui ka kulud. Keeruline osa on kulude hindamine enne, kui meeskond on neid ise kogenud. Turundus, konverentsiettekanded ja entusiastlikud kasutajad rõhutavad loomulikult tugevusi; arendusmeeskond peab uurima ka piiranguid ning operatiivseid kompromisse.
Lihtsus on teadlik insenerivalik
Äriprotsessi parandamiseks pole automaatselt vaja keerulist arhitektuuri. KISS-põhimõte eksisteerib põhjusega: tarbetu keerukus teeb süsteemi raskemini mõistetavaks ja hooldatavaks.
Lihtne tarkvara ei tähenda lihtsakoelist tarkvara. Selle loomine nõuab aastatepikkust kogemust, analüütilist ja enesekriitilist mõtlemist, distsiplineeritud inseneritööd ning head projektijuhtimist.
Solutionalis keskendume äriprobleemi lahendamisele väikseima süsteemiga, mis katab praegused vajadused ja saab turvaliselt edasi areneda. Meie lähenemisest saad rohkem lugeda artiklist Miks valida tarkvaraarenduspartneriks Solutional?.
Mõnes projektis on keerukas arhitektuur põhjendatud. Sellisel juhul peab meeskond suutma selgitada, millist konkreetset probleemi iga komponent lahendab, milliseid puudusi see kaasa toob ja miks eelised kulu üles kaaluvad.
