Webudvikling De 10 kodende antipatterner, du skal undgå

Design af arkitekturen på et websted eller et program eller opsætning af en effektiv kodende arbejdsgang gør det ofte, at vi behandler tilbagevendende problemer. Vi behøver ikke nødvendigvis at løse disse software design problemer fra bunden, som Løsninger på arkitektonisk niveau kan genanvendes på samme måde som kodestykker på mikro-niveau.

Design mønstre er generelt genanvendelige løsninger for visse scenarier, det kan Kom godt i gang med at løse almindeligt forekommende problemer, og kan enormt hjælpe os med at optimere vores kode.

Mens designmønstre er gode midler til at forbedre vores udviklingsproces ved at anvende velprøvede formler, kan vi undertiden også gå galt med dem. Disse kaldes antipatterner.

Hvad er antipatterner?

Begrebet “antipattern” blev opfattet i en bog kaldet AntiPatterns i 1998. Det refererer til genanvendte løsninger, der i første omgang virker nyttige, men viser sig senere at gøre mere skade end godt.

Dette kan ske af forskellige grunde, for eksempel hvis vi ikke bruger mønstrene i den rigtige kontekst, indstilling eller tid (løsninger, der var effektive i fortiden, kan ikke altid fungere i nutiden) eller i andre tilfælde hele paradigmet var bare dårlig fra starten.

Antipatterner kaldes også ofte fejlmønstre. Den gode nyhed er, at det er muligt at genkende og undgå dem.

I dette indlæg vil vi kigge på 10 fælles kodende antipatterner i webudvikling, der kan bedrage os til at tro, at vi har en veloptimeret kode. (Bemærk, at de antipatterner, der er angivet i dette indlæg, ikke nødvendigvis er de samme som hvad du kan finde i den ovenfor nævnte bog.)

1. For tidlig optimering

God timing er en afgørende faktor i kodeoptimering. Vi kan let gengive antipattern af “for tidlig optimering”, hvis vi er opmærksomme på små effektiviteter og optimerer for dem for tidligt i udviklingsprocessen, før vi præcist ved, hvad vi vil gøre.

Ifølge Donald Knuths berømte citat “for tidlig optimering er roden til alt ondt“, hvilket kan være en overdrivelse, men viser stadig, hvordan alvorlige problemer for tidlig optimering senere kan forårsage.

Hvis vi optimerer til ydeevne, før vi opretter en effektiv arkitektur, kan vi lavere kode læsbarhed, lave fejlsøgning og vedligeholdelse hårdere, og Tilsæt overflødige dele til vores kode.

For at forhindre for tidlig optimering er det en god ide at følge programmeringsprincippet YAGNI (Du skal ikke bruge det), som anbefaler at “Gennemfør altid ting, når du rent faktisk har brug for dem, aldrig når du bare forudser, at du har brug for dem.”

2. Genopfinde hjulet

Det “genopfinde hjulet” antipattern er også undertiden også omtalt som “designe i et vakuum”. Det sker, når vi vil gør alt ved os selv og skriv alt fra bunden, uden at søge allerede eksisterende metoder, API'er eller biblioteker.

Genopfinde hjulet er ikke bare en tidskrævende ting at gøre, men Brugerdefinerede løsninger, specielt til grundlæggende funktionaliteter, er sjældent så gode som de standardiserede der allerede er testet af mange udviklere og brugere.

3. afhængighed helvede

Det modsatte af “genopfinde hjulet” Antipattern er en anden almindelig antipattern kaldet “afhængighed helvede”.

Hvis vi bruger i stedet for at skrive alt fra bunden for mange tredjepartsbiblioteker, der er afhængige af specifikke versioner af andre biblioteker, vi kan let løbe ind i en næppe håndterbar situation, når vi ønsker at opdatere, da disse subsidiære afhængigheder er i mange tilfælde uforenelig med hinanden.

Afhængighed helvede kan løses ved hjælp af pakkeforvaltere, der er i stand til Opdater smart indbyrdes afhængige afhængigheder smart. Hvis vi bliver overvældet for meget af problemet, kan refactoring også være en god ide.

4. Spaghetti kode

“Spaghetti kode” er nok den mest kendte kodende antipattern. Det beskriver en applikation, der er svær at debugere eller ændre på grund af manglen på en ordentlig arkitektur.

Resultatet af dårlig software design er en flok kode, der ligner struktur i en skål spaghetti, dvs.. sammenflettet og indviklet. Læsbarhed af spaghetti kode er meget lav, og det er normalt en næsten umulig opgave at forstå, hvordan det virker præcist.

Spaghetti kode stammer normalt fra kombination af forskellige dårlige kodningspraksis, for eksempel koden, der ikke indeholder korrekte conditionals-blokke, har mange goto-udsagn, undtagelser og tråde, der indeholder dele, der hører til et andet sted, har minimale forhold mellem objekter, funktioner eller metoder, der ikke kan genbruges eller ikke dokumenteres korrekt eller overhovedet.

5. Programmering ved permutation

“Programmering ved permutation” eller “programmering ved et uheld” sker, når vi forsøger at finde en løsning på et problem ved successivt at eksperimentere med små ændringer, test og vurdere dem en efter en og endelig implementere den, der virker først.

Programmering ved permutation kan nemt introducere nye fejl i vores kode, værre stadig, de er bugs, vi genkender ikke nødvendigvis med det samme. I mange tilfælde er det også umuligt at forudse, om løsningen vil fungere for alle mulige scenarier, eller ej.

6. Kopier og indsæt programmering

“Kopier og indsæt programmering” opstår, når vi ikke følger det ikke-gentage sig selv (DRY) kodningsprincip, og i stedet for at skabe generiske løsninger indsætter vi allerede eksisterende kodestykker til forskellige steder og senere redigerer dem for at passe ind i den givne sammenhæng.

Denne praksis resulterer i en kode, der er meget repeterende, da de indsatte kode dele normalt kun adskiller sig i mindre uoverensstemmelser.

Kopier og indsæt programmering er ikke kun begået af nybegynderudviklere, men også erfarne programmører, som mange af dem er tilbøjelige til Brug deres egne forhåndskrevne, velprøvede kodestykker til specifikke opgaver, som let kan føre til utilsigtede gentagelser.

7. Cargo-Cult Programmering

Navnet på “cargo-programmering” kommer fra et specifikt etnografisk fænomen kaldet “lastkult”. Cargo cults dukkede op i det sydlige Stillehav efter anden verdenskrig, da den tvungne kontakt med avancerede civilisationer førte indfødte til at tro, at fremstillede produkter, såsom Coca-Cola, tv'er og køleskaber bragt af lastskibe til øerne, blev skabt af overnaturlige metoder; og hvis de udfører magiske ritualer, der ligner de vesteuropas skikke, kommer lasten fyldt med varer igen.

Når vi forpligter antipatternen til fragtkult programmering, gør vi stort set det samme. Vi bruger rammer, biblioteker, løsninger, designmønstre osv., Der fungerede godt for andre, uden at forstå, hvorfor vi gør det, eller hvordan teknologierne virker præcist.

I mange tilfælde udviklere bare Ritual gør hvad der er hip på det tidspunkt uden noget egentligt formål. Denne praksis er ikke kun dårlig, fordi det gør vores applikation overflødigt opustet, men det kan også nemt introducere nye fejl i vores kode.

8. Lava Flow

Vi taler om “lavaflod” antipattern, når vi skal håndtere kode, der har overflødige eller lavkvalitetsdele at synes at være integreret til programmet, men vi forstår ikke helt hvad det gør, eller hvordan det påvirker hele applikationen. Dette gør det risikabelt at fjerne det.

Det sker normalt med arv kode, eller når kode er skrevet af en anden person (normalt uden ordentlig dokumentation), eller når projektet flyttede for hurtigt fra udviklingen til produktionsfasen.

Navnet på antipattern kommer fra dets resemblance med lava, der kommer fra vulkaner, dvs. i første omgang bevæges det hurtigt og fluidt uden at tage for mange forholdsregler, men det størkner senere og bliver svært at fjerne.

I teorien kan vi slippe af med lavastrømme med omfattende test og refactoring, men i praksis, implementeringen er ofte hård eller endog umulig. Da lavastrømme normalt har højtydende omkostninger, er det bedre at forhindre dem ved at oprette en veldesignet arkitektur og en god arbejdsgang fra starten.

9. Hård kodning

“Hård kodning” er en velkendt antipattern, mod hvilken de fleste webudviklingsbøger advarer os lige i forordet. Hård kodning er den uheldige praksis i hvilken vi gemmer konfigurations- eller inputdata, f.eks. en filsti eller et fjernt værtsnavn, i kildekoden snarere end at få det fra en konfigurationsfil, en database, en brugerindgang eller en anden ekstern kilde.

Det største problem med hard kode er det det virker kun korrekt i et bestemt miljø, og på når vilkårene ændres, vi skal ændre kildekode, normalt på flere separate steder.

10. Blød kodning

Hvis vi prøver meget svært at undgå faldet i hård kodning, kan vi let løbe ind i en anden antipattern, der hedder “blød kodning”, hvilket er det nøjagtige modsatte.

Ved blød kodning, vi sætter ting, der skal være i kildekoden til eksterne kilder, For eksempel gemmer vi forretningslogik i databasen. Den mest almindelige grund til, at vi gør det, er frygten for, at forretningsregler vil ændre sig i fremtiden, derfor skal vi omskrive koden.

I ekstreme tilfælde kan et soft-kodet program Bliv så abstrakt og indviklet, at det er næsten umuligt at forstå det (især for nye holdmedlemmer), og ekstremt svært at vedligeholde og fejle.