Kriterier for god programvarearkitektur

Effektivitet

Erfarne programmerere kan lett skille en god arkitektur fra en dårlig, men hvis de blir bedt om å beskrive den med noen få ord, er det usannsynlig at de kan gjøre det. Det finnes ikke et enkelt kriterium for god arkitektur og ingen enkelt definisjon.

Men hvis du tenker deg om, kan du skrive en rekke kriterier som en god arkitektur bør tilfredsstille. En god arkitektur er for det første en logisk arkitektur som gjør prosessen med å utvikle og vedlikeholde et program enklere og mer effektiv.

Når et program har en god arkitektur, er det alltid lett nok å forstå hvordan det fungerer og hvor man skal skrive kode. Et godt utformet program er lettere å endre, teste, feilsøke og utvikle. Smarte mennesker har formulert følgende kriterier for god arkitektur:

• Effektivitet;
• Fleksibilitet;
• Utvidbarhet;
• Skalerbarhet;
• testbarhet;
• Vedlikehold av kode.

Systemeffektivitet. Programmet skal selvfølgelig løse de tildelte oppgavene og utføre sine funksjoner godt, og under ulike forhold. Det ser ut til at et hvilket som helst program gjør det det skal gjøre (hvis det er skrevet), men ofte er dette slett ikke tilfelle.

Du vil stadig støte på programmer som ikke gjør det de hevder å gjøre.

• Libre Office er en full erstatning for Microsoft Office (egentlig ikke);
• Edge-nettleseren støtter alle nettstandarder (egentlig ikke);
• Banken bryr seg om sikkerheten til personopplysningene til brukerne (faktisk ikke).

Og vi har ennå ikke berørt ytelse, pålitelighet, rettidige feilrettinger eller publisering av informasjon om kjente sårbarheter.

Det er tydelig at ingen er perfekte, men programmet må løse sine primære oppgaver. Derfor, uten effektivitet, ingen steder.

Fleksibilitet

Det eneste som er viktigere enn effektivitet etter min mening er fleksibilitet. Enhver applikasjon må endres over tid, ettersom kravene endres, blir nye lagt til. Jo raskere og mer praktisk det er å gjøre endringer i den eksisterende funksjonaliteten, jo færre problemer og feil det forårsaker, jo mer fleksibel er systemarkitekturen.

Svært ofte tror nybegynnere programmerere / arkitekter at de trenger en ideell arkitektur for aktuelle oppgaver. Nei. Du trenger en ideell arkitektur for oppgavene som vil bli annonsert for deg om et år. Du, som allerede nå ikke kjenner de fremtidige oppgavene, bør vite hva de vil være.

Det gir ingen mening å prøve å forutsi dem, for det vil alltid være noe uventet. Men du må ta hensyn til at slike oppgaver vil dukke opp. Prøv derfor i utviklingsprosessen å evaluere hva som oppnås med tanke på hvordan det må endres.

Spør deg selv: "Hva skjer hvis den nåværende arkitektoniske beslutningen viser seg å være feil?", "Hvor mye kode vil bli endret?". Endring av ett fragment av systemet bør ikke påvirke de andre fragmentene.

Når det er mulig, bør ikke arkitektoniske beslutninger være hugget i stein, og konsekvensene av arkitektoniske feil bør begrenses rimelig. "God arkitektur lar deg UTSIKE viktige avgjørelser" (Bob Martin) og minimerer "kostnadene" ved feil.

En av disse tilnærmingene er å dele opp applikasjonen i mikrotjenester: det er lett å bryte den allerede eksisterende logikken i separate deler. Men det største problemet er å gjøre fremtidige endringer i et dusin tjenester samtidig for å implementere en liten funksjon.

Skalerbarhet

Skalerbarhet er muligheten til å redusere utviklingstiden ved å legge til nye mennesker i prosjektet. Arkitekturen skal gjøre det mulig å parallellisere utviklingsprosessen slik at mange kan jobbe med programmet samtidig.

Det ser ut til at denne regelen utføres av seg selv, men i praksis er alt akkurat det motsatte. Det er til og med en superpopulær bok, The Mythical Man-Month , som forklarer hvorfor når nye mennesker legges til i et prosjekt, øker utviklingstiden.

Utvidbarhet

Utvidbarhet er muligheten til å legge til nye funksjoner og enheter til et system uten å bryte kjernestrukturen. I den innledende fasen er det fornuftig å sette inn bare den grunnleggende og mest nødvendige funksjonaliteten i systemet.

Dette er det såkalte YAGNI-prinsippet - du trenger det ikke , "du trenger det ikke". Samtidig skal arkitekturen tillate deg å enkelt øke tilleggsfunksjonaliteten etter behov. Og slik at innføringen av de mest sannsynlige endringene krevde minst innsats.

Kravet om at systemets arkitektur skal være fleksibel og utvidbar (det vil si være i stand til endring og utvikling) er så viktig at det til og med er formulert som et eget prinsipp - "Åpent/lukket prinsipp " . Open-Closed-prinsippet er det andre av de fem SOLID-prinsippene: programvareenheter (klasser, moduler, funksjoner) skal være åpne for utvidelse, men stengt for modifikasjon .

Med andre ord: det skal være mulig å endre og utvide oppførselen til systemet uten å omskrive eksisterende deler av systemet .

Dette betyr at applikasjonen bør utformes på en slik måte at endring av atferd og tilføyelse av ny funksjonalitet oppnås ved å skrive ny kode (utvidelser), uten å måtte endre eksisterende kode.

I dette tilfellet vil fremveksten av nye krav ikke innebære en modifikasjon av den eksisterende logikken, men kan implementeres primært ved å utvide den. Dette prinsippet er grunnlaget for "plug-in-arkitektur" (Plugin Architecture). Teknikkene for hvordan dette kan oppnås vil bli diskutert senere.

Husker du servlets og filtre? Hvorfor var det nødvendig med filtre, og selv med separate grensesnitt, hvis faktisk all den samme logikken kunne implementeres ved hjelp av servlets?

Det var oppfinnelsen av konseptet med filtre (serviceservlets) som gjorde det mulig å flytte ulike servicefunksjoner til et eget lag. Og i fremtiden, når du endret oppførselen til filtre, var det ikke nødvendig å endre servletene.

Før oppfinnelsen av filtre, var all tjenestelogikken som var ansvarlig for å omdirigere forespørsler plassert i selve servletene. Og ofte vil en liten endring i logikken føre til behovet for å gå gjennom alle servletene og gjøre forskjellige endringer på alle.

Testbarhet

Hvis du er en Java Backend-utvikler, viser serverapplikasjonene dine ofte et sett med metoder som en REST API. Og for å sjekke at alle metodene dine fungerer etter hensikten, må de dekkes med tester.

Generelt er API-testdekning en god stil. Den lar deg sørge for at API-en din virkelig gjør det den var ment å gjøre. Og enda viktigere, du kan gjøre endringer i serverlogikken og enkelt sjekke at du ikke har ødelagt noe ved et uhell .

Så snart du begynner å skrive tester, vil du innse at det meste av kode ikke kan testes i det hele tatt: private metoder, sterk kobling, statiske klasser og variabler.

"Hvorfor trenger vi tester hvis koden fungerer?", vil nybegynneren spørre.

«Hvorfor trenger vi arbeidskode hvis den ikke kan testes?», vil fagmannen spørre.

Kode som er enkel å teste vil inneholde færre feil og være mer pålitelig. Men tester forbedrer ikke bare kodekvaliteten. Nesten alle utviklere kommer etter hvert til den konklusjon at kravet om «god testbarhet» også er en ledetråd som automatisk fører til god design.

Her er et sitat fra boken Ideal Architecture: "Bruk prinsippet om "testbarhet" av en klasse som en "lakmustest" for god klassedesign. Selv om du ikke skriver en eneste linje med testkode, svarer du på dette spørsmålet i 90 % av tilfellene vil bidra til å forstå hvordan alt er bra" eller "dårlig" med hans design."

Det finnes en hel metodikk for å utvikle programmer basert på tester, som kalles Test-Driven Development (TDD). Dette er selvfølgelig den andre ytterligheten: skriv kode før du skriver kode.

Vedlikehold av kode

Som regel jobber det mange med programmet – noen slutter, nye kommer. Gjennomsnittlig arbeidstid for en programmerer i et IT-selskap er halvannet år. Så hvis du kom til et prosjekt som er 5 år gammelt, så har bare 20 % av kollegene dine jobbet med det helt fra begynnelsen.

Å vedlikeholde og utvikle et program som andre har skrevet er svært vanskelig. Selv om programmet allerede er skrevet, er det ofte nødvendig å fortsette å vedlikeholde det: fikse feil og foreta mindre rettelser. Og ofte må dette gjøres av folk som ikke har vært med på å skrive det.

Derfor bør en god arkitektur gjøre det relativt enkelt og raskt for nye mennesker å forstå systemet . Prosjektet skal være:

• Godt strukturert.
• Ikke inneholde duplisering.
• Ha godt formatert kode.
• Det er ønskelig med dokumentasjon.
• Det er nødvendig å bruke standard og kjente løsninger for programmerere.

Du kan enkelt vurdere prosjektet du jobber med på et 5-punktssystem . Bare tell to poeng for hvert av disse kravene . Og hvis du får 5 eller flere, så er du heldig.

Programmerere har til og med et prinsipp om minste overraskelse : jo mer eksotisk systemet er, desto vanskeligere er det for andre å forstå. Vanligvis brukes det i forhold til brukergrensesnittet, men det kan også brukes til å skrive kode.