Kā pāriet no labā uz lielo

Šis ir ievads daudzdaļīgā sērijā, kurā mēs izpētīsim, kā padarīt priekšējo programmatūras izstrādes procesus efektīvākus un mērogojamākus - lai labāks produkts būtu ātrāks.

“Cilvēku grupa, kas prāta vētras pār klēpjdatoru un papīra loksnēm”, autors Štefans Štefančíks vietnē Unsplash

Lieliska produkta izveidošana bieži vien nav vienīgais mēģinājums. Sarežģītākajos uzstādījumos būtu iesaistītas vairākas radošās, mārketinga, produktu un tehnoloģiju komandas. Pat ja esat viena uzņēmuma uzņēmums, jums būs jāsadarbojas ar lietotājiem, lai apkopotu viņu atsauksmes par to, kas viņiem noder. Šo cikliskās projektēšanas iteratīvo ietvaru, kas palīdz uzlabot kvalitāti un funkcijas, parasti sauc par veiklās atkārtošanas darbplūsmu.

Jo ātrāk jūs varēsit atkārtot, jo labāks būs jūsu produkts.
Smartsheet “Agile Iteration Workflow”

Kad StashAway, kad priekšējās grupas komanda pirmo reizi sāka veidot tīmeklī balstītu produktu, mēs bijām paātrinātā termiņā, lai sāktu, un mūsu produktu izstrādes un pārvaldības procesi nebija tik stingri. Tagad, kad produkts nogatavojas un kad tiek izpētītas un pievienotas citas funkcijas, mēs vēlamies uzlabot un pastiprināt mūsu procesu, veidojot labāku un mērogojamāku produkta priekšējā gala arhitektūru. Pašreizējā iestatīšana neļaus mums efektīvi veikt mērogu funkciju piedāvājuma un valsts paplašināšanas ziņā.

Lai izveidotu lielisku produktu, mums ir jāuzlabo iterācijas darbplūsma. Par to ir daudz literatūras par produktu pārvaldību, un šī nav šo rakstu sērija. Tas, ko mēs vēlamies izpētīt, ir tas, kā ātrāk tikt pie atkārtojumiem prototipēšanas un veidošanas posmā, un lai to izdarītu, mums būs jāformalizē mūsu komandas iekšējie izstrādes un apstiprināšanas procesi, lai mēs varētu efektīvāk sadarboties ar mūsu radošajām un produktu komandām . Mēs domājam, ka mēs to varam sasniegt, izmantojot pastāvīgu integrāciju un piegādes plūsmu saistībā ar plašāku produktu atkārtojuma darbplūsmu, kā aprakstīts iepriekš.

Galu galā mūsu mērķis ir tuvoties deklaratīvajai programmēšanas paradigmai, kas pauž to, ko mēs vēlamies darīt savās lietojumprogrammās, nevis obligāti kodēt kā. Lai to izdarītu, mums būs jāveido pamats mūsu celtniecības bloku izveidošanai.

Sākumā izvēršam rūpes par lietotāja saskarni un lietojumprogrammu loģiku, lai UI komponentu izstrāde kļūtu par atsevišķu darbību. Tam būs savs centrālais repozitorijs kopā ar kopējiem utilītiem, savs vienības komplekts, pieņemšanas un regresijas testi. Mūsu lietotāja saskarnes komponenti tagad būs atkārtoti izmantojami, komponējami un atbilstoši tēmai vietņu un tīmekļa lietotņu variantiem. Lietojot to Storybook, mēs varam izveidot interaktīvu rakstu bibliotēku.

Mums būs pārliecība, ka mūsu lietotāja saskarnes komponenti izskatīsies un izturēsies tieši tā, kā vajadzētu, lai mēs varētu koncentrēties uz jautrajiem un svarīgajiem jautājumiem - lietojumprogrammām un to, kā viņiem vajadzētu izturēties. To pašu procesu ar mūsu lietotāja interfeisa komponentiem mēs varam piemērot arī mūsu projektiem paredzētajos projektos ar specifiskākiem testa komplektiem, lai palielinātu pārklājumu. Tikai ar šiem testa komplektiem mēs varam palielināt izstrādātāju pārliecību par koda stumšanu un izvietošanu un pretī palielināt iterācijas ātrumu.

Izmantojot šo centrālo komponenti, kas spēj sastādīt komponentus, mēs varam izveidot idejas prototipiem un gaiteņa lietotāju pārbaudēm un pat ātrāk piedāvāt jaunas funkcijas.

Programmatūras testēšanas līmeņi

Jūs esat pamanījis, ka mēs esam metuši mājās ziņu, ka testēšana ir svarīga. Programmatūras testēšana ir plašs programmatūras izstrādes temats, taču koncentrēsimies uz četriem testēšanas līmeņiem, kas ir neatņemama nepārtrauktā piegādes procesa vienmērīgā darbībā - vienība, integrācija, sistēma un pieņemšana.

Mēs izmantojam vienības testus, lai pārbaudītu atsevišķus komponentus, vismazākās pārbaudāmās vienības, programmatūrā. Mūsu gadījumā tie parasti ir UI komponenti vai utilītas palīgu metodes. Integrācijas pārbaude notiek, ja atsevišķi komponenti tiek pārbaudīti kā grupa. Piemēram, tas varētu nozīmēt tādu funkciju kā kalkulators, kurā būs pogas un displeja ekrāns, un pārliecinoties, vai, reaģējot uz pogas nospiešanu, tiek parādīts pareizs numurs. API galapunkts varētu izveidot datu bāzes savienojumu, lai izgūtu datu kopu.

Vienības un integrācijas testi parasti novērš visspilgtākās kļūdas, pirms mēs sākam izvēršanas izvietošanu. Tas ietaupa laiku iekšējiem un ārējiem testētājiem, kuri novērtēs pabeigto un integrēto sistēmu, lai tā atbilstu funkciju un biznesa prasībām - sistēmas domēniem un pieņemšanas testiem. Kad programmatūra iztur četrus pārbaudes līmeņus, mēs to varam izmantot ražošanā.

Tas ir īss ieskats jautājumā par to, kā mēs plānojam padarīt mūsu klientu grupas procesus efektīvākus. Sīkāku informāciju par ieviešanu mēs aplūkosim turpmākajās ziņās par StashAway vietnes priekšgala attīstību. Sekojiet līdzi!

Mēs nepārtraukti meklējam lielu tehnoloģiju talantu pievienošanos mūsu komandai - apmeklējiet mūsu vietni, lai uzzinātu vairāk, un jūtieties brīvi sazināties ar mums!