Kriterier for dårlig softwarearkitektur

Kriterier for dårligt design

Livet fungerer ganske enkelt: ofte behøver du bare ikke at gøre dumme ting for at være klog. Dette gælder også for softwareudvikling: i de fleste tilfælde, for at gøre noget godt, skal du bare ikke gøre det dårligt.

De fleste programmører har haft erfaring med dele af systemet, der var dårligt designet. Men endnu mere trist vil de fleste af jer have den triste oplevelse at indse, at I var ophavsmændene til et sådant system. Vi ville have det bedste, men det blev som altid.

De fleste udviklere stræber ikke efter dårlig arkitektur, og for mange systemer kommer der et punkt, hvor de begynder at sige, at dens arkitektur er forfærdelig. Hvorfor sker dette? Var arkitekturdesign dårligt fra starten, eller er det blevet dårligt med tiden?

Roden til dette problem er manglen på en definition af "dårligt" design.

Det forekommer mig, at det er forståelsen af ​​kvaliteten af ​​design og årsagerne til dets "forfald", der er de vigtigste kvaliteter for enhver programmør. Som i de fleste andre tilfælde er hovedsagen at identificere problemet, og det vil være et spørgsmål om teknologi at løse det.

Definition af "dårligt design"

Hvis du beslutter dig for at prale af din kode foran en medprogrammør, vil du højst sandsynligt blive latterliggjort som svar: "Hvem gør det her?", "Hvorfor er det sådan?" og "Jeg ville gøre tingene anderledes." Dette sker meget ofte.

Alle mennesker er forskellige, men du skriver stadig koden til dine medprogrammører, så i processen med at udvikle hver funktion har du altid brug for en gennemgangsfase, når andre mennesker ser på din kode.

Men selvom mange ting kan gøres på forskellige måder, er der et sæt kriterier, som alle udviklere vil være enige om. Ethvert stykke kode, der opfylder kravene, men stadig udviser en (eller flere) egenskaber, er dårligt design.

Dårligt design:

• Svært at ændre, fordi enhver ændring påvirker for mange andre dele af systemet. ( Stivhed , Rigiditet).
• Når der foretages ændringer, går andre dele af systemet uventet i stykker. ( Skrøbelighed , Skrøbelighed).
• Koden er svær at genbruge i et andet program, fordi det er for svært at få det ud af det aktuelle program. ( Ubevægelighed , ubevægelighed).

Og det sjove er, at det næsten er umuligt at finde et stykke af systemet , der ikke indeholder nogen af ​​disse egenskaber (det vil sige, er fleksibelt, pålideligt og genanvendeligt), opfylder kravet, og samtidig er dets design dårligt .

Således kan vi bruge disse tre egenskaber til entydigt at afgøre, om et design er "dårligt" eller "godt".

Årsager til "dårligt design"

Hvad gør et design stift, skørt og ubevægeligt? Stiv indbyrdes afhængighed af moduler.

Et design er stift , hvis det ikke let kan ændres. Denne stivhed skyldes det faktum, at en enkelt ændring af et stykke kode i et vævet system resulterer i kaskadeændringer i afhængige moduler. Dette sker altid, når én person arbejder på koden.

Dette komplicerer straks hele den kommercielle udviklingsproces: Når antallet af kaskadeændringer ikke kan forudsiges af designeren eller udvikleren, er det umuligt at estimere virkningen af ​​en sådan ændring. Derfor forsøger de at udskyde sådanne ændringer på ubestemt tid.

Og det gør igen omkostningerne ved forandringer uforudsigelige. Stillet over for en sådan usikkerhed er ledere tilbageholdende med at foretage ændringer, så designet bliver officielt stift.

På et tidspunkt passerer dit projekt "begivenhedshorisonten" og er dømt til at falde ind i stiv arkitekturs "sorte hul".

Skrøbelighed er et systems tendens til at bryde ned flere steder efter en enkelt ændring. Normalt opstår nye problemer på steder, der er begrebsmæssigt uafhængige af stedet for forandring. En sådan skrøbelighed underminerer alvorligt tilliden til designet og vedligeholdelsen af ​​systemet.

Dette var normalt tilfældet, når der ikke var private metoder. Det er nok at offentliggøre alle metoder, og du vil blive dømt til udseendet af en skrøbelig arkitektur. Indkapsling hjælper med at håndtere dette på mikroniveau. Men på makroniveau har du brug for en modulær arkitektur.

Når et projekt har en skrøbelig arkitektur, kan udviklerne ikke garantere produktets kvalitet.

Simple ændringer i en del af applikationen fører til fejl i andre ikke-relaterede dele. At rette disse fejl fører til endnu flere problemer, og eskorteprocessen bliver til en berømt hund, der jagter sin egen hale.

Designet er ubevægeligt , når de nødvendige dele af systemet er stærkt knyttet til andre uønskede detaljer. For meget af deres egen kode, deres egne unikke tilgange og løsninger.

Kan du huske JUL-loggeren, hvis udviklere kom op med deres egne logningsniveauer uden god grund? Dette er bare tilfældet.

For at give en designer en idé om, hvor nemt det er at genbruge et eksisterende design, er det nok at tænke på, hvor nemt det vil være at bruge i en ny applikation.

Hvis designet er tæt koblet, vil denne designer blive forfærdet over den mængde arbejde, der kræves for at adskille de nødvendige dele af systemet fra de unødvendige detaljer. I de fleste tilfælde er et sådant design ikke genanvendeligt, da omkostningerne ved at adskille det opvejer at udvikle det fra bunden.

Relevans

Alt ændrer sig, men alt forbliver det samme. (kinesisk ordsprog)

Rigtig gode spørgsmål er blevet rejst ovenfor. Hvad er farerne ved skrøbelige og stive systemer? Ja, fordi processen med at styre et sådant projekt bliver uforudsigelig og ukontrollerbar. Og prisen er ublu.

Hvordan kan en leder give eller ej give grønt lys til at tilføje en funktion, hvis han ikke ved, hvor lang tid det rent faktisk vil tage? Hvordan prioriterer man opgaver, hvis man ikke tilstrækkeligt kan estimere tiden og kompleksiteten af ​​deres implementering?

Og hvordan kan udviklere betale den samme tekniske gæld af, når vi vil rake ind med at betale den, og vi ikke kan forstå, hvor meget vi vil rake, før vi raker?

Problemer med genbrug af kode eller test er også meget relevante. Enhedstest tjener ikke kun til at teste nogle antagelser om den enhed, der testes, men også til at bestemme graden af ​​dens sammenhæng og kan tjene som en indikator for genbrug.

Her er et citat fra Bob Martin for denne sag: "For at genbruge din kode, skal du gøre en indsats for at genbruge den mindre end omkostningerne ved at udvikle fra bunden . " Ellers er der ingen, der overhovedet gider denne sag.

Brugen af ​​designprincipper og mønstre tjener ét formål - at gøre design godt. Hvis deres brug ikke giver dig nogen fordel (eller omvendt, overtræder principperne om "godt design"), så er noget i din udestue ikke rigtigt, og måske er værktøjet begyndt at blive brugt til andre formål.