Kriterier för god mjukvaruarkitektur

Effektivitet

Erfarna programmerare kan lätt skilja en bra arkitektur från en dålig, men om de ombeds att beskriva den med några få ord är det osannolikt att de kommer att kunna göra det. Det finns inget enskilt kriterium för bra arkitektur och ingen enskild definition.

Men om du tänker efter kan du skriva ett antal kriterier som en bra arkitektur ska uppfylla. En bra arkitektur är för det första en logisk arkitektur som gör processen att utveckla och underhålla ett program enklare och effektivare.

När ett program har en bra arkitektur är det alltid lätt att förstå hur det fungerar och var man ska skriva kod. Ett väl utformat program är lättare att ändra, testa, felsöka och utveckla. Smarta människor har formulerat följande kriterier för bra arkitektur:

• Effektivitet;
• Flexibilitet;
• Expanderbarhet;
• Skalbarhet;
• testbarhet;
• Kod underhållbarhet.

Systemeffektivitet. Programmet ska givetvis lösa de tilldelade uppgifterna och utföra sina funktioner väl och under olika förutsättningar. Det verkar som att vilket program som helst gör vad det ska göra (om det är skrivet), men ofta är det inte alls så.

Du kommer ständigt att stöta på program som inte gör vad de påstår sig göra.

• Libre Office är en fullständig ersättning för Microsoft Office (inte riktigt);
• Edge-webbläsaren stöder alla webbstandarder (inte riktigt);
• Banken bryr sig om säkerheten för sina användares personuppgifter (faktiskt inte).

Och vi har ännu inte berört prestanda, tillförlitlighet, snabba buggfixar eller publicering av information om kända sårbarheter.

Det är klart att ingen är perfekt, men programmet måste lösa sina primära uppgifter. Därför, utan effektivitet, ingenstans.

Flexibilitet

Det enda viktigare än effektivitet enligt mig är flexibilitet. Alla applikationer måste ändras över tiden, eftersom kraven ändras läggs nya till. Ju snabbare och bekvämare det är att göra ändringar i den befintliga funktionaliteten, ju färre problem och fel det orsakar, desto mer flexibel är systemarkitekturen.

Mycket ofta tror nybörjare programmerare / arkitekter att de behöver en idealisk arkitektur för aktuella uppgifter. Nej. Du behöver en idealisk arkitektur för de uppgifter som kommer att tillkännages för dig om ett år. Du, som redan nu inte känner till framtida uppgifter, borde veta vad de kommer att bli.

Det är ingen mening att försöka förutsäga dem, för det kommer alltid att finnas något oväntat. Men du måste ta hänsyn till att sådana uppgifter kommer att dyka upp. Försök därför i utvecklingsprocessen att utvärdera vad som erhålls i termer av hur det kommer att behöva förändras.

Fråga dig själv: "Vad händer om det nuvarande arkitektoniska beslutet visar sig vara fel?", "Hur mycket kod kommer att ändras?". Att ändra ett fragment av systemet bör inte påverka dess andra fragment.

När det är möjligt bör arkitektoniska beslut inte vara huggna i sten, och konsekvenserna av arkitektoniska fel bör rimligen begränsas. "Bra arkitektur gör att du kan DRÖJA viktiga beslut" (Bob Martin) och minimerar "kostnaden" för misstag.

Ett av dessa tillvägagångssätt är att dela upp applikationen i mikrotjänster: det är lätt att dela upp den redan existerande logiken i separata delar. Men det största problemet är att göra framtida ändringar av ett dussin tjänster på en gång för att implementera en liten funktion.

Skalbarhet

Skalbarhet är förmågan att minska utvecklingstiden genom att lägga till nya personer till projektet. Arkitekturen ska möjliggöra att utvecklingsprocessen parallelliseras så att många personer kan arbeta med programmet samtidigt.

Det verkar som att denna regel utförs av sig själv, men i praktiken är allt precis tvärtom. Det finns till och med en superpopulär bok, The Mythical Man-Month , som förklarar varför utvecklingstiden ökar när nya personer läggs till i ett projekt.

Expanderbarhet

Utökningsbarhet är möjligheten att lägga till nya funktioner och enheter till ett system utan att bryta dess kärnstruktur. I det inledande skedet är det vettigt att bara sätta in den grundläggande och mest nödvändiga funktionaliteten i systemet.

Detta är den så kallade YAGNI-principen - du behöver det inte , "du kommer inte att behöva det". Samtidigt bör arkitekturen göra det möjligt för dig att enkelt öka ytterligare funktionalitet efter behov. Och så att införandet av de mest sannolika förändringarna krävde minsta ansträngning.

Kravet på att systemets arkitektur ska vara flexibel och utbyggbar (det vill säga kunna förändras och utvecklas) är så viktigt att det till och med formuleras som en separat princip - den "öppna/stängda principen " . Open-Closed-principen är den andra av de fem SOLID-principerna: programvaruenheter (klasser, moduler, funktioner) ska vara öppna för förlängning, men stängda för modifiering .

Med andra ord: det ska vara möjligt att ändra och utöka systemets beteende utan att skriva om befintliga delar av systemet .

Detta innebär att applikationen bör utformas på ett sådant sätt att ändra dess beteende och lägga till ny funktionalitet skulle uppnås genom att skriva ny kod (tillägg), utan att behöva ändra befintlig kod.

I detta fall kommer uppkomsten av nya krav inte att innebära en modifiering av den befintliga logiken, utan kan implementeras i första hand genom att utöka den. Denna princip är grunden för "plug-in arkitektur" (Plugin Architecture). Teknikerna med vilka detta kan uppnås kommer att diskuteras senare.

Kommer du ihåg servlets och filter? Varför behövdes filter, och även med separata gränssnitt, om i själva verket samma logik kunde implementeras med hjälp av servlets?

Det var uppfinningen av konceptet filter (serviceservlets) som gjorde det möjligt att flytta olika servicefunktioner till ett separat lager. Och i framtiden, när du ändrade filterbeteende, var det inte nödvändigt att ändra servlets.

Före uppfinningen av filter fanns all servicelogik som var ansvarig för omdirigering av förfrågningar i själva servletarna. Och ofta skulle en liten förändring i logiken leda till behovet av att gå igenom alla servlets och göra olika ändringar för alla.

Testbarhet

Om du är en Java Backend-utvecklare, exponerar dina serverapplikationer ofta en uppsättning metoder som ett REST API. Och för att kontrollera att alla dina metoder fungerar som de ska, måste de täckas med tester.

I allmänhet är API-testtäckning en bra stil. Det låter dig se till att ditt API verkligen gör vad det var tänkt att göra. Och även, ännu viktigare, kan du göra ändringar i serverlogiken och enkelt kontrollera att du inte av misstag har brutit något .

Så fort du börjar skriva tester kommer du att inse att det mesta koden inte kan testas alls: privata metoder, stark koppling, statiska klasser och variabler.

"Varför behöver vi tester om koden fungerar?", kommer nybörjaren att fråga.

"Varför behöver vi fungerande kod om den inte kan testas?", kommer proffsen att fråga.

Kod som är lätt att testa kommer att innehålla färre buggar och vara mer tillförlitlig. Men tester förbättrar inte bara kodkvaliteten. Nästan alla utvecklare kommer så småningom fram till att kravet på ”god testbarhet” också är en vägledande kraft som automatiskt leder till bra design.

Här är ett citat från boken Ideal Architecture: "Använd principen om "testbarhet" för en klass som ett "lackmustest" av bra klassdesign. Även om du inte skriver en enda rad med testkod, svara på den här frågan i 90 % av fallen kommer att hjälpa till att förstå hur allt bra" eller "dåligt" med sin design."

Det finns en hel metodik för att utveckla program baserade på test, som kallas för Testdriven utveckling (TDD). Detta är naturligtvis den andra ytterligheten: skriv kod innan du skriver kod.

Kod underhållbarhet

Som regel jobbar många med programmet – en del slutar, nya kommer. Den genomsnittliga arbetstiden för en programmerare i ett IT-företag är ett och ett halvt år. Så om du kom till ett projekt som är 5 år gammalt, så har bara 20 % av dina kollegor arbetat med det från första början.

Att underhålla och utveckla ett program som andra har skrivit är mycket svårt. Även om programmet redan är skrivet är det ofta nödvändigt att fortsätta underhålla det: åtgärda fel och gör mindre korrigeringar. Och ofta måste detta göras av personer som inte deltagit i att skriva det.

Därför bör en bra arkitektur göra det relativt enkelt och snabbt för nya människor att förstå systemet . Projektet måste vara:

• Välstrukturerad.
• Innehåll inte dubbelarbete.
• Har välformaterad kod.
• Det är önskvärt att inkludera dokumentation.
• Det är nödvändigt att tillämpa standardlösningar och bekanta lösningar för programmerare.

Du kan enkelt betygsätta projektet du arbetar med på ett 5-punktssystem . Räkna bara två poäng för vart och ett av dessa krav . Och om du får 5 eller fler, då har du tur.

Programmerare har till och med en princip om minsta överraskning : ju mer exotiskt systemet är, desto svårare är det för andra att förstå. Vanligtvis används det i förhållande till användargränssnittet, men det är tillämpligt för att skriva kod också.