Det gjøres mye arbeid bak kulissene for å gjøre LMS-et vårt tilgjengelig på nett for deg. Det krever mye utviklingsarbeid å sette alt sammen. .
Mange ting har endret seg siden selskapet først begynte å bygge Easy LMS. Vil du vite mer? Vår Marketing Owl Priscila har intervjuet en av utviklerne våre for å finne ut hvordan vi bygger Easy LMS ved hjelp av en mikrotjenestearkitektur, hva det betyr, og hvordan det påvirker arbeidet vi gjør som team og sluttbrukerne.
Priscila: Takk for at du ble med meg på dette intervjuet, Thomas! Det første jeg vil vite (og jeg tror de fleste av leserne) er hva mikrotjenestearkitektur er. Kan du forklare det?
Thomas: Ikke noe problem. Mikrotjenestearkitektur er en måte å bygge kode på i flere deler eller repositorier. Vi kan si at vi deler opp måten vi bygger kode på i flere instanser i stedet for å bygge én stor kodeblokk.
Priscila: Interessant. Så det betyr at utviklingsteamet bygger biter av uavhengig kode som passer sammen med resten av programvaren, ikke sant? Men det har ikke alltid vært slik i Easy LMS. Hvorfor så utviklingsteamet behovet for å endre måten dere bygger koden på? Hva førte til det? Var det en ny trend eller noe?
Thomas: Ja, det er en trend, men det var ikke hovedgrunnen. Vi har alltid visst om mikrotjenestearkitektur. Men i begynnelsen bygde vi Easy LMS som store biter med kode, eller det som kalles en monolitt. Da vi begynte å vokse som selskap, fikk vi mye mer trafikk på nettstedet, noe som skapte mange problemer, for eksempel sider som ikke responderte og bugs. Vi innså at vi måtte endre måten vi bygger koden på, slik at nettstedet kunne justeres og skaleres automatisk.
Det er som å ha en "stor fabrikk" som lett blir overveldet av mye arbeid. Vi innså at vi måtte bygge noen "mindre fabrikker" for å håndtere andre deler av arbeidet
Vi fant ut at noen deler av koden ikke var praktiske, og at vi kunne forbedre dem. Da tenkte vi at det var enklere å gjennomføre forbedringene i mindre biter i stedet for å ta dem som et gigantprosjekt. Det er som å ha en "stor fabrikk" som lett blir overveldet av mye arbeid. Vi innså at vi måtte bygge noen "mindre fabrikker" for å håndtere andre deler av arbeidet.
Priscila: Kan du gi et eksempel på noe vi har bygget i en mikrotjenestearkitektur?
Thomas: Et nylig eksempel på en mikrotjeneste vi har implementert, er den nye eksportfunksjonen for eksport av eksamensøkter og deltakerdata. Vi laget den i løpet av de to siste syklusene. Den gamle eksporten kjørte i vår gamle "store fabrikk" sammen med flere andre ting og var ikke optimalisert.
Vi kunne opprette en "liten fabrikk" som spesialiserte seg på å lage disse nye eksportvarene. Med eksporten støtte vi på mange problemer. Når kundene for eksempel hadde for mye data å eksportere, overveldet forespørslene hovedsystemet. Nå som vi har en egen tjeneste for eksporten, kan den kjøre problemfritt. Vi har faktisk laget en kode for eksporten og en annen for å informere administratorene om at eksporten er klar. De er selvstendige enheter, ikke store biter.
Priscila: Kult! Er det andre deler av Easy LMS som vi har bygget med mikrotjenestearkitektur?
Thomas: Ja, det er det. En av de mest interessante er akademiets nye design. Vi bygde det nye akademiet med React, som er et rammeverk for å bygge grensesnitt. Vi tok utgangspunkt i den gamle arkitekturen (monolitten), tok biter fra den og skapte en selvstendig del. Vi bygget også et API (programmeringsgrensesnitt) for å hente data som skal vises i grensesnittet. Nå har vi to selvstendige deler: en for å hente data og en for å vise dataene. De er mindre og enklere å vedlikeholde.
Priscila: Ok, basert på det du fortalte meg, har vi fortsatt en del gammel kode. Er det et problem at vi nå har to typer kode i systemet ?? Er det planer om å oppdatere den?
Thomas: Nei, det er ikke noe problem. Det er en prosess. Vi bygde de første delene av systemet ved hjelp av metoden med "store kodebiter". Det er planer om å erstatte dem. Men kundene merker ikke forskjellen. Vi bygger den nye koden på en måte som gjør at den kan fungere sømløst sammen med den gamle koden.
Priscila: Forstått. Så hva foretrekker du som utvikler? Er det enklere eller mer komplisert å bygge kode med mikrotjenestearkitektur sammenlignet med den tidligere prosessen?
Thomas: Ja, det er mye enklere å tenke i små biter og vedlikeholde den nye koden. Vi vurderer å oppdatere deltakergrensesnittet i fremtiden, slik at det fungerer bedre i kombinasjon med Academy og seg selv. Hvis vi bygger det med mikrotjenestearkitektur, blir det mye enklere å legge til funksjoner fordi vi kan jobbe med hver enkelt del for seg.
Priscila: Så, hvordan har arbeidet med mikrotjenester endret måten du jobber på?
Thomas: Vi kan utvikle raskere og bedre. Mikrotjenester hjelper oss med å vedlikeholde nettstedet og gjør det mulig for oss å lansere ting raskere. .
Vi kan også bestemme den beste måten å fullføre en jobb på, fordi hvert stykke kode er en selvstendig enhet. Det betyr at vi kan bestemme hvilket programmeringsspråk vi vil bruke, og hva slags tjeneste vi vil kjøre.
Da vi brukte det gamle systemet, måtte vi fortsette å bygge koden på det språket hvis vi ønsket å oppdatere en versjon som brukte et bestemt språk. Nå kan vi velge mellom ulike språk basert på hva vi mener er best for den aktuelle funksjonen. Vi jobber i team. Hvis vi starter en ny mikrotjeneste, utforsker vi alternativene, og så bestemmer vi oss for hva som fungerer best for oss. Det gir oss flere valgmuligheter.
Priscila: Påvirker det å berøre uønskede deler av systemet, for eksempel når du prøver å løse et problem og ender opp med å skape et annet (for eksempel en feil)?
Thomas: Ja, selv for et år siden, når vi prøvde å løse ting som involverte mye kode, endte vi opp med å jobbe med for mange unødvendige ting. Hvis vi for eksempel skulle løse X, løste vi Y, og så skapte vi feil Z. Arbeidet med mikrotjenester har redusert dette problemet.
Priscila: Ok. Jeg ser at mikrotjenestearkitektur gjør arbeidet enklere å håndtere for utviklingsteamet. Men hvordan påvirker det kundene våre og deres deltakere?
Thomas: Vel, som jeg sa, kundene legger ikke merke til (og bør ikke legge merke til) ulike deler av koden. Alt skal fungere sammen for å skape en smidig opplevelse. Kundene kan dra nytte av dette fordi vi nå kan lansere nye funksjoner raskere og forbedre oss basert på deres tilbakemeldinger.
Det er en drastisk endring fra måten vi gjorde ting på før. Da vi for eksempel lanserte det nye Exam-administratorpanelet, tok det oss rundt seks måneder med utvikling før vi lanserte hele greia på én gang. Om kundene elsket det eller ikke, var det ingen vei tilbake (heldigvis elsket de det?). Nå har vi endret måten vi skaper og lanserer nye funksjoner på.
Den nye kursbyggeren, for eksempel, ble først lansert som en betafunksjon. Vi bygget den med React og lanserte den litt etter litt, og la til mindre nye funksjoner helt til den hadde alle funksjonene som skulle til for å erstatte den gamle kursbyggeren i sin helhet. I mellomtiden kunne vi se hva som fungerte, hvordan kundene brukte den, forbedre den, iterere den og deretter gjøre endringer. Det ville ikke ha vært mulig med store deler av koden utgitt på én gang.
Priscila: Det gir veldig god mening. Så vidt jeg husker, stemmer det overens med prinsippene i Toyotas Improvement Kata, som vi bruker i selskapet. Det er bedre å lage en prototype, få tilbakemeldinger og forbedre funksjonen i stedet for å bruke mye tid uten å vite hvordan kundene vil motta den. Takk for at du ble med meg på dette intervjuet!
Thomas: Ja, jeg tror det fungerer bedre. Jeg håper jeg kunne kaste litt lys over hvordan utviklingsteamet vårt jobber hos Easy LMS! Bare hyggelig.
