Kriterier för dålig mjukvaruarkitektur

Kriterier för dålig design

Livet fungerar helt enkelt: ofta, för att vara smart, behöver du bara inte göra dumma saker. Detta gäller även för mjukvaruutveckling: i de flesta fall, för att göra något bra, behöver du bara inte göra det dåligt.

De flesta programmerare har haft erfarenhet av delar av systemet som var dåligt utformade. Men ännu mer sorgligt kommer de flesta av er att ha den sorgliga upplevelsen att inse att ni var upphovsmännen till ett sådant system. Vi ville ha det bästa, men det blev som alltid.

De flesta utvecklare strävar inte efter dålig arkitektur, och för många system kommer det en punkt där de börjar säga att dess arkitektur är hemsk. Varför händer det här? Var arkitekturdesign dålig från början, eller har den blivit dålig med tiden?

Roten till detta problem är avsaknaden av en definition av "dålig" design.

Det verkar för mig att det är förståelsen för designens kvalitet och orsakerna till dess "förfall" som är de viktigaste egenskaperna för alla programmerare. Som i de flesta andra fall är huvudsaken att identifiera problemet, och det blir en fråga om teknik för att lösa det.

Definition av "dålig design"

Om du bestämmer dig för att skryta med din kod inför en annan programmerare, kommer du med största sannolikhet få förlöjligande som svar: "Vem gör det här?", "Varför är det så?" och "Jag skulle göra saker annorlunda." Detta händer väldigt ofta.

Alla människor är olika, men du skriver fortfarande koden för dina medprogrammerare, så i processen med att utveckla varje funktion behöver du alltid en recensionsfas när andra tittar på din kod.

Men även om många saker kan göras på olika sätt finns det en uppsättning kriterier som alla utvecklare skulle komma överens om. Varje bit kod som uppfyller dess krav men som fortfarande uppvisar en (eller flera) egenskaper är dålig design.

Dålig design:

• Svårt att ändra eftersom varje förändring påverkar för många andra delar av systemet. ( Stelhet , Stelhet).
• När ändringar görs går andra delar av systemet oväntat sönder. ( Bräcklighet , Bräcklighet).
• Koden är svår att återanvända i en annan applikation eftersom det är för svårt att få ut den från den aktuella applikationen. ( Orörlighet , Orörlighet).

Och det roliga är att det är nästan omöjligt att hitta en del av systemet som inte innehåller någon av dessa egenskaper (det vill säga är flexibel, pålitlig och återanvändbar), uppfyller kravet, och samtidigt är dess design dålig .

Således kan vi använda dessa tre egenskaper för att entydigt avgöra om en design är "dålig" eller "bra".

Orsaker till "dålig design"

Vad gör en design stel, spröd och orörlig? Styvt ömsesidigt beroende av moduler.

En design är stel om den inte lätt kan ändras. Denna stelhet beror på det faktum att en enda ändring av en kodbit i ett vävt system resulterar i kaskadändringar i beroende moduler. Detta händer alltid när en person arbetar med koden.

Detta komplicerar omedelbart hela den kommersiella utvecklingsprocessen: när antalet kaskadförändringar inte kan förutsägas av designern eller utvecklaren är det omöjligt att uppskatta effekten av en sådan förändring. Därför försöker de skjuta upp sådana förändringar på obestämd tid.

Och detta gör i sin tur kostnaden för förändring oförutsägbar. Inför sådan osäkerhet är chefer ovilliga att göra ändringar, så designen blir officiellt stel.

Vid någon tidpunkt passerar ditt projekt "händelsehorisonten" och är dömt att falla in i det "svarta hålet" av stel arkitektur.

Bräcklighet är tendensen hos ett system att gå sönder på flera ställen efter en enda förändring. Vanligtvis uppstår nya problem på platser som inte är begreppsmässigt relaterade till förändringens plats. Sådan bräcklighet undergräver allvarligt förtroendet för utformningen och underhållet av systemet.

Så var det oftast när det inte fanns några privata metoder. Det räcker att göra alla metoder offentliga, och du kommer att bli dömd till utseendet av en bräcklig arkitektur. Inkapsling hjälper till att hantera detta på mikronivå. Men på makronivå behöver du en modulär arkitektur.

När ett projekt har en bräcklig arkitektur kan utvecklarna inte garantera produktens kvalitet.

Enkla ändringar i en del av applikationen leder till buggar i andra orelaterade delar. Att korrigera dessa fel leder till ännu fler problem, och eskortprocessen förvandlas till en berömd hund som jagar sin egen svans.

Designen är orörlig när de nödvändiga delarna av systemet är starkt knutna till andra oönskade detaljer. För mycket av sin egen kod, sina egna unika tillvägagångssätt och lösningar.

Kommer du ihåg JUL-loggern, vars utvecklare kom på sina egna loggningsnivåer utan någon bra anledning? Detta är bara fallet.

För att ge en designer en uppfattning om hur lätt det är att återanvända en befintlig design, räcker det att tänka på hur lätt det kommer att vara att använda i en ny applikation.

Om designen är tätt kopplad, kommer denna designer att bli förskräckt över mängden arbete som krävs för att separera de nödvändiga delarna av systemet från de onödiga detaljerna. I de flesta fall är en sådan design inte återanvändbar, eftersom kostnaden för att separera den uppväger att utveckla den från grunden.

Relevans

Allt förändras, men allt förblir detsamma. (kinesiskt ordspråk)

Mycket bra frågor har ställts ovan. Vilka är farorna med ömtåliga och stela system? Ja, eftersom processen att hantera ett sådant projekt blir oförutsägbar och okontrollerbar. Och priset är orimligt.

Hur kan en chef ge eller inte ge klartecken att lägga till någon funktion om han inte vet hur mycket tid det faktiskt kommer att ta? Hur prioriterar man uppgifter om man inte kan uppskatta tiden och komplexiteten i genomförandet av dem?

Och hur kan utvecklare betala av samma tekniska skuld när vi kommer att håva in att betala den, och vi kan inte förstå hur mycket vi kommer att håva tills vi rakar?

Problem med kodåteranvändning eller testning är också mycket relevanta. Enhetstester tjänar inte bara till att testa vissa antaganden om enheten som testas, utan också för att bestämma graden av dess sammanhållning och kan fungera som en indikator på återanvändning.

Här är ett citat från Bob Martin för det här fallet: "För att återanvända din kod måste du anstränga dig för att återanvända den mindre än kostnaden för att utveckla från grunden. " Annars kommer ingen ens att bry sig om denna fråga.

Användningen av designprinciper och mönster tjänar ett syfte - att göra design bra. Om användningen av dem inte ger dig någon fördel (eller tvärtom, bryter mot principerna för "bra design"), är något i ditt uterum inte rätt och kanske har verktyget börjat användas för andra ändamål.