Kriterier for dårlig programvarearkitektur

Kriterier for dårlig design

Livet fungerer ganske enkelt: ofte, for å være smart, trenger du bare ikke å gjøre dumme ting. Dette gjelder også programvareutvikling: i de fleste tilfeller, for å gjøre noe bra, trenger du bare ikke gjøre det dårlig.

De fleste programmerere har hatt erfaring med deler av systemet som var dårlig utformet. Men enda mer trist, de fleste av dere vil ha den triste opplevelsen av å innse at dere var forfatterne av et slikt system. Vi ville ha det beste, men det ble som alltid.

De fleste utviklere streber ikke etter dårlig arkitektur, og for mange systemer kommer det et punkt hvor de begynner å si at arkitekturen er forferdelig. Hvorfor skjer dette? Var arkitekturdesign dårlig fra starten, eller har det blitt dårlig over tid?

Roten til dette problemet er mangelen på en definisjon av "dårlig" design.

Det virker for meg at det er forståelsen av kvaliteten på design og årsakene til dens "forfall" som er de viktigste egenskapene for enhver programmerer. Som i de fleste andre tilfeller er hovedsaken å identifisere problemet, og det vil være et spørsmål om teknologi for å løse det.

Definisjon av "dårlig design"

Hvis du bestemmer deg for å skryte av koden din foran en medprogrammerer, vil du mest sannsynlig bli latterliggjort som svar: "Hvem gjør dette?", "Hvorfor er det sånn?" og "Jeg ville gjort ting annerledes." Dette skjer veldig ofte.

Alle mennesker er forskjellige, men du skriver fortsatt koden for dine medprogrammerere, så i prosessen med å utvikle hver funksjon trenger du alltid en gjennomgangsfase når andre ser på koden din.

Men selv om mange ting kan gjøres på forskjellige måter, er det et sett med kriterier som alle utviklere vil være enige om. Ethvert kodestykke som tilfredsstiller kravene, men som fortsatt viser en (eller flere) egenskaper, er dårlig design.

Dårlig design:

• Vanskelig å endre fordi enhver endring påvirker for mange andre deler av systemet. ( Rigiditet , Rigiditet).
• Når det gjøres endringer, bryter andre deler av systemet uventet. ( Skjørhet , Skjørhet).
• Koden er vanskelig å gjenbruke i en annen applikasjon fordi det er for vanskelig å få den ut av gjeldende applikasjon. ( Bevegelighet , Immobilitet).

Og det morsomme er at det er nesten umulig å finne en del av systemet som ikke inneholder noen av disse egenskapene (det vil si er fleksibel, pålitelig og gjenbrukbar), oppfyller kravet, og samtidig er designet dårlig. .

Dermed kan vi bruke disse tre egenskapene til entydig å bestemme om et design er "dårlig" eller "bra".

Årsaker til "dårlig design"

Hva gjør et design stivt, sprøtt og ubevegelig? Stiv gjensidig avhengighet av moduler.

Et design er stivt hvis det ikke enkelt kan endres. Denne stivheten skyldes det faktum at en enkelt endring av et kodestykke i et vevd system resulterer i kaskadende endringer i avhengige moduler. Dette skjer alltid når én person jobber med koden.

Dette kompliserer umiddelbart hele den kommersielle utviklingsprosessen: når antall overlappende endringer ikke kan forutsies av designeren eller utvikleren, er det umulig å estimere virkningen av en slik endring. Derfor prøver de å utsette slike endringer på ubestemt tid.

Og dette gjør igjen kostnadene ved endring uforutsigbare. Overfor en slik usikkerhet er ledere motvillige til å gjøre endringer, så designet blir offisielt stivt.

På et tidspunkt passerer prosjektet ditt "hendelseshorisonten" og er dømt til å falle inn i det "svarte hullet" av rigid arkitektur.

Skjørhet er tendensen til et system til å bryte ned på flere steder etter en enkelt endring. Vanligvis oppstår nye problemer på steder som er konseptuelt ikke relatert til stedet for endring. Slik skjørhet undergraver alvorlig tilliten til utformingen og vedlikeholdet av systemet.

Dette var vanligvis tilfelle når det ikke fantes private metoder. Det er nok å offentliggjøre alle metoder, og du vil bli dømt til å se ut som en skjør arkitektur. Innkapsling hjelper til med å håndtere dette på mikronivå. Men på makronivå trenger du en modulær arkitektur.

Når et prosjekt har en skjør arkitektur, kan ikke utviklerne garantere kvaliteten på produktet.

Enkle endringer i en del av applikasjonen fører til feil i andre ikke-relaterte deler. Å rette opp disse feilene fører til enda flere problemer, og eskorteprosessen blir til en kjent hund som jager sin egen hale.

Designet er ubevegelig når de nødvendige delene av systemet er sterkt knyttet til andre uønskede detaljer. For mye av deres egen kode, deres egne unike tilnærminger og løsninger.

Husker du JUL-loggeren, hvis utviklere kom opp med sine egne loggingsnivåer uten god grunn? Dette er bare tilfelle.

For å gi en designer en idé om hvor enkelt det er å gjenbruke et eksisterende design, er det nok å tenke på hvor enkelt det vil være å bruke i en ny applikasjon.

Hvis designet er tett koblet, vil denne designeren bli forferdet over mengden arbeid som kreves for å skille de nødvendige delene av systemet fra de unødvendige detaljene. I de fleste tilfeller er et slikt design ikke gjenbrukbart, siden kostnadene ved å skille det oppveier å utvikle det fra bunnen av.

Relevans

Alt endres, men alt forblir det samme. (kinesisk ordtak)

Veldig gode spørsmål har blitt reist ovenfor. Hva er farene ved skjøre og stive systemer? Ja, fordi prosessen med å styre et slikt prosjekt blir uforutsigbar og ukontrollerbar. Og prisen er ublu.

Hvordan kan en leder gi eller ikke gi klarsignal til å legge til en funksjon hvis han ikke vet hvor mye tid det faktisk vil ta? Hvordan prioritere oppgaver hvis du ikke kan estimere tiden og kompleksiteten til implementeringen av dem tilstrekkelig?

Og hvordan kan utviklere betale ned den samme tekniske gjelden når vi vil rake inn å betale den, og vi kan ikke forstå hvor mye vi vil rake før vi raker?

Problemer med gjenbruk eller testing av kode er også svært relevante. Enhetstester tjener ikke bare til å teste noen antakelser om enheten som testes, men også for å bestemme graden av dens sammenheng og kan tjene som en indikator på gjenbruk.

Her er et sitat fra Bob Martin for denne saken: "For å gjenbruke koden din, må du anstrenge deg for å gjenbruke den mindre enn kostnadene ved å utvikle fra bunnen av . " Ellers vil ingen engang bry seg med denne saken.

Bruken av designprinsipper og mønstre tjener ett formål - å gjøre design bra. Hvis bruken av dem ikke gir deg noen fordel (eller omvendt, bryter med prinsippene for "god design"), er det noe i vinterhagen din som ikke er riktig, og kanskje har verktøyet begynt å bli brukt til andre formål.