Kriterier for god softwarearkitektur

Effektivitet

Erfarne programmører kan nemt skelne en god arkitektur fra en dårlig, men hvis de bliver bedt om at beskrive den med få ord, er det usandsynligt, at de kan gøre det. Der er ikke et enkelt kriterium for god arkitektur og ingen enkelt definition.

Men hvis du tænker dig om, kan du skrive en række kriterier, som en god arkitektur bør opfylde. En god arkitektur er for det første en logisk arkitektur, der gør processen med at udvikle og vedligeholde et program enklere og mere effektiv.

Når et program har en god arkitektur, er det altid nemt nok at forstå, hvordan det fungerer, og hvor man skal skrive kode. Et veldesignet program er lettere at ændre, teste, fejlfinde og udvikle. Smarte mennesker har formuleret følgende kriterier for god arkitektur:

• Effektivitet;
• Fleksibilitet;
• Udvidbarhed;
• Skalerbarhed;
• testbarhed;
• Kodevedligeholdelse.

Systemeffektivitet. Programmet skal selvfølgelig løse de pålagte opgaver og udføre sine funktioner godt og under forskellige forhold. Det ser ud til, at ethvert program gør, hvad det skal gøre (hvis det er skrevet), men ofte er det slet ikke tilfældet.

Du vil konstant støde på programmer, der ikke gør, hvad de hævder at gøre.

• Libre Office er en fuld erstatning for Microsoft Office (ikke rigtigt);
• Edge-browseren understøtter alle webstandarder (ikke rigtigt);
• Banken bekymrer sig om sikkerheden af ​​dens brugeres personlige data (faktisk ikke).

Og vi har endnu ikke berørt ydeevne, pålidelighed, rettidige fejlrettelser eller offentliggørelse af information om kendte sårbarheder.

Det er klart, at ingen er perfekte, men programmet skal løse sine primære opgaver. Derfor, uden effektivitet, ingen steder.

Fleksibilitet

Det eneste vigtigere end effektivitet efter min mening er fleksibilitet. Enhver applikation skal ændres over tid, da kravene ændres, tilføjes nye. Jo hurtigere og mere bekvemt det er at foretage ændringer i den eksisterende funktionalitet, jo færre problemer og fejl det forårsager, jo mere fleksibel er systemarkitekturen.

Meget ofte tror nybegyndere / arkitekter, at de har brug for en ideel arkitektur til aktuelle opgaver. Ingen. Du har brug for en ideel arkitektur til de opgaver, der bliver annonceret for dig om et år. Du, der allerede nu ikke kender de fremtidige opgaver, burde vide, hvad de bliver.

Det giver ingen mening at forsøge at forudsige dem, for der vil altid være noget uventet. Men du skal tage højde for, at sådanne opgaver vil dukke op. Forsøg derfor i udviklingsprocessen at evaluere, hvad der opnås i forhold til, hvordan det skal ændres.

Spørg dig selv: "Hvad sker der, hvis den nuværende arkitektoniske beslutning viser sig at være forkert?", "Hvor meget kode vil blive ændret?". Ændring af et fragment af systemet bør ikke påvirke dets andre fragmenter.

Når det er muligt, bør arkitektoniske beslutninger ikke være hugget i sten, og konsekvenserne af arkitektoniske fejl bør være rimeligt begrænsede. "God arkitektur giver dig mulighed for at FORSINKE vigtige beslutninger" (Bob Martin) og minimerer "omkostningerne" ved fejl.

En af disse tilgange er at opdele applikationen i mikrotjenester: det er nemt at bryde den allerede eksisterende logik op i separate dele. Men det største problem er at foretage fremtidige ændringer af et dusin tjenester på én gang for at implementere en lille funktion.

Skalerbarhed

Skalerbarhed er evnen til at reducere udviklingstiden ved at tilføje nye mennesker til projektet. Arkitekturen skal gøre det muligt at parallelisere udviklingsprocessen, så mange mennesker kan arbejde på programmet på samme tid.

Det ser ud til, at denne regel udføres af sig selv, men i praksis er alt præcis det modsatte. Der er endda en superpopulær bog, The Mythical Man-Month , som forklarer, hvorfor udviklingstiden øges, når der kommer nye mennesker til et projekt.

Udvidelsesmuligheder

Udvidelsesmuligheder er evnen til at tilføje nye funktioner og enheder til et system uden at bryde dets kernestruktur. I den indledende fase giver det mening kun at sætte den grundlæggende og mest nødvendige funktionalitet ind i systemet.

Dette er det såkaldte YAGNI-princip - du har ikke brug for det , "du har ikke brug for det". Samtidig skal arkitekturen give dig mulighed for nemt at øge yderligere funktionalitet efter behov. Og således at indførelsen af ​​de mest sandsynlige ændringer krævede den mindste indsats.

Kravet om, at systemets arkitektur skal være fleksibel og udvidelig (det vil sige at kunne ændres og udvikles) er så vigtigt, at det endda er formuleret som et særskilt princip - "Åbent/lukket princip " . Open-Closed-princippet er det andet af de fem SOLID-principper: softwareenheder (klasser, moduler, funktioner) skal være åbne for udvidelse, men lukkede for modifikation .

Med andre ord: det skal være muligt at ændre og udvide systemets adfærd uden at omskrive eksisterende dele af systemet .

Det betyder, at applikationen skal designes på en sådan måde, at ændring af dens adfærd og tilføjelse af ny funktionalitet ville blive opnået ved at skrive ny kode (udvidelser), uden at skulle ændre eksisterende kode.

I dette tilfælde vil fremkomsten af ​​nye krav ikke medføre en ændring af den eksisterende logik, men kan primært implementeres ved at udvide den. Dette princip er grundlaget for "plug-in arkitektur" (Plugin Architecture). De teknikker, hvormed dette kan opnås, vil blive diskuteret senere.

Husker du servlets og filtre? Hvorfor var der behov for filtre, og endda med separate grænseflader, hvis al den samme logik faktisk kunne implementeres ved hjælp af servlets?

Det var opfindelsen af ​​konceptet med filtre (serviceservlets), der gjorde det muligt at flytte forskellige servicefunktioner til et separat lag. Og i fremtiden, når du ændrede filtrenes adfærd, var det ikke nødvendigt at ændre servlets.

Før opfindelsen af ​​filtre var al servicelogikken, der var ansvarlig for omdirigering af anmodninger, placeret i selve servlets. Og ofte ville en lille ændring i logikken føre til behovet for at gennemgå alle servlets og foretage forskellige ændringer til alle.

Testbarhed

Hvis du er en Java Backend-udvikler, så viser dine serverapplikationer ofte et sæt metoder som en REST API. Og for at kontrollere, at alle dine metoder fungerer efter hensigten, skal de dækkes af tests.

Generelt er API-testdækning en god stil. Det giver dig mulighed for at sikre dig, at din API virkelig gør, hvad den var beregnet til. Og også, endnu vigtigere, kan du foretage ændringer i serverlogikken og nemt kontrollere, at du ikke ved et uheld har ødelagt noget .

Så snart du begynder at skrive test, vil du indse, at det meste kode slet ikke kan testes: private metoder, stærk kobling, statiske klasser og variabler.

"Hvorfor har vi brug for tests, hvis koden virker?", vil begynderen spørge.

"Hvorfor har vi brug for en arbejdskode, hvis den ikke kan testes?", vil fagmanden spørge.

Kode, der er let at teste, vil indeholde færre fejl og være mere pålidelig. Men test forbedrer ikke kun kodekvaliteten. Næsten alle udviklere kommer til sidst til den konklusion, at kravet om "god testbarhed" også er en styrende kraft, der automatisk fører til godt design.

Her er et citat fra bogen Ideal Architecture: "Brug princippet om "testbarhed" af en klasse som en "lakmustest" af godt klassedesign. Selv hvis du ikke skriver en enkelt linje med testkode, skal du besvare dette spørgsmål i 90 % af tilfældene vil hjælpe med at forstå, hvordan alt godt" eller "dårligt" med hans design."

Der er en hel metode til at udvikle programmer baseret på test, som kaldes Test-Driven Development (TDD). Dette er selvfølgelig den anden yderlighed: skriv kode, før du skriver kode.

Kodevedligeholdelse

Som regel arbejder rigtig mange på programmet – nogle går, nye kommer. Den gennemsnitlige arbejdstid for en programmør i en it-virksomhed er halvandet år. Så hvis du kom til et projekt, der er 5 år gammelt, så har kun 20 % af dine kollegaer arbejdet på det helt fra begyndelsen.

Det er meget svært at vedligeholde og udvikle et program, som andre har skrevet. Selvom programmet allerede er skrevet, er det ofte nødvendigt at fortsætte med at vedligeholde det: Ret fejl og lav mindre rettelser. Og ofte skal dette gøres af folk, der ikke har været med til at skrive det.

Derfor skal en god arkitektur gøre det relativt nemt og hurtigt for nye mennesker at forstå systemet . Projektet skal være:

• Godt struktureret.
• Indeholder ikke duplikering.
• Har velformateret kode.
• Det er ønskeligt at medtage dokumentation.
• Det er nødvendigt at anvende standard og velkendte løsninger til programmører.

Du kan nemt bedømme det projekt, du arbejder på, på et 5-punktssystem . Tæl blot to point for hvert af disse krav . Og hvis du får 5 eller flere, så er du heldig.

Programmører har endda et princip om mindste overraskelse : Jo mere eksotisk systemet er, jo sværere er det for andre at forstå. Normalt bruges det i forhold til brugergrænsefladen, men det kan også bruges til at skrive kode.