Webbutveckling De 10 kodande antipatternerna du måste undvika
Att utforma en webbplatss eller en applikations arkitektur eller skapa ett effektivt kodningsflöde gör det ofta att vi hanterar återkommande problem. Vi behöver inte nödvändigtvis lösa dessa programvaruproblem från början, som lösningar på arkitektonisk nivå kan återanvändas på samma sätt som kod snippets på mikro-nivå.
Designmönster är generellt återanvändbara lösningar för vissa scenarier, det kan komma till nytta för att lösa vanliga problem, och kan enormt hjälpa oss att optimera vår kod.
Medan designmönster är stora sätt att förbättra vår utvecklingsprocess genom att använda välprövade formler, kan vi ibland också gå fel med dem. Dessa kallas antipatterner.
Vad är Antipatterns?
Termen “antimönster” var myntade i en bok som heter AntiPatterns 1998. Den hänvisar till återanvända lösningar som initialt verkar användbara, men visar sig senare att göra mer skada än bra.
Detta kan hända av olika anledningar, till exempel om vi inte använder mönstren i rätt sammanhang, inställning eller tid (lösningar som var effektiva i det förflutna kanske inte alltid fungerar i nutiden) eller i andra fall hela paradigmet var bara dåligt från början.
Antipatterns kallas också ofta misslyckningsmönster. Den goda nyheten är att det är möjligt att känna igen och undvika dem.
I det här inlägget kommer vi att titta på 10 vanliga kodande antipatterner i webbutveckling som kan leda oss till att vi har en väl optimerad kod. (Observera att antipatternerna som anges i det här inlägget inte nödvändigtvis är desamma som vad du hittar i boken som nämns ovan.)
1. För tidig optimering
God timing är en viktig faktor vid kodoptimering. Vi kan enkelt reproducera antipattern av “för tidig optimering”, om vi uppmärksammar små effektiviteter och optimerar för dem för tidigt i utvecklingsprocessen innan vi exakt vet vad vi vill göra.
Enligt Donald Knuths berömda citat “För tidig optimering är roten till allt ont“, vilket kan vara en överdrift, men visar fortfarande hur allvarliga problem prematur optimering senare kan orsaka.
Om vi optimerar för prestanda innan vi installerar en effektiv arkitektur, kan vi lägre kodläsbarhet, göra felsökning och underhålls hårdare, och lägg till överflödiga delar till vår kod.
För att förhindra för tidig optimering är det en bra idé att följa programmeringsprincipen YAGNI (You Do not Need It), som rekommenderar att “alltid genomföra saker när du faktiskt behöver dem, aldrig när du bara förutser att du behöver dem.”
2. Återupprätta hjulet
De “uppfinna hjulet på nytt” Antipattern kallas ibland också “designa i vakuum”. Det händer när vi vill gör allt av oss själva och skriv allt från början, utan att leta efter redan befintliga metoder, API eller bibliotek.
Återuppfinna hjulet är inte bara en tidslös sak att göra, men anpassade lösningar, speciellt för grundläggande funktionaliteter, är sällan lika bra som standardiserade som redan har testats av många utvecklare och användare.
3. Beroende Helvetet
Det motsatta av “uppfinna hjulet på nytt” Antipattern är en annan vanlig antipattern kallad “beroende helvete”.
Om vi, istället för att skriva allt från början, använder för många tredje partsbibliotek som är beroende av specifika versioner av andra bibliotek, vi kan lätt gå in i en knappt hanterbar situation när vi vill uppdatera, eftersom dessa dotterbolag är i många fall oförenliga med varandra.
Beroende helvete kan lösas genom att använda paketchefer som kan uppdatera smidigt beroende beroende. Om vi är överväldigade för mycket av problemet, kan refactoring också vara en bra idé.
4. Spaghetti Kod
“Spaghetti kod” är förmodligen den mest kända kodande antipattern. Det beskriver en applikation som är svår att felsöka eller ändra på grund av bristen på en riktig arkitektur.
Resultatet av dålig programvara är en massa kod som liknar struktur i en skål spaghetti, dvs. trasslig och konvulerad. Läsbarhet av spaghettikod är mycket låg, och det är vanligtvis ett nästan omöjligt uppdrag att förstå hur det fungerar exakt.
Spagetti koden stämmer vanligtvis från kombination av olika dåliga kodningspraxis, såsom koden som inte innehåller korrekta conditionals-block, med många goto-förklaringar, undantag och trådar som innehåller delar som hör hemma någonstans, har minimala relationer mellan objekt, funktioner eller metoder som inte kan återanvändas eller inte dokumenteras korrekt eller alls.
5. Programmering genom permutation
“Programmering genom permutation” eller “programmering av en olycka” händer när vi försöker hitta en lösning på ett problem genom att successivt experimentera med små modifikationer, testa och utvärdera dem en efter en, och slutligen implementera den som arbetar först.
Programmering genom permutation kan enkelt presentera nya fel i vår kod, värre fortfarande, de är buggar som vi inte nödvändigtvis känner igen igen. I många fall är det också omöjligt att förutse om lösningen kommer att fungera för alla möjliga scenarier, eller inte.
6. Kopiera och klistra in programmering
“Kopiera och klistra in programmering” inträffar när vi inte följer principen om inte repetera dig själv (DRY), och i stället för att skapa generella lösningar sätter vi redan existerande kodsedlar till olika platser och ändrar dem senare för att passa in i det angivna sammanhanget.
Denna övning resulterar i en kod som är mycket repetitiv, eftersom de infogade koddelarna vanligen skiljer sig åt endast i mindre avvikelser.
Kopiera och klistra programmering engageras inte bara av nybörjareutvecklare, utan även erfarna programmerare, som många av dem är benägna att Använd egna förskriven, välprövade kodutdrag för specifika uppgifter, vilket lätt kan leda till oavsiktliga upprepningar.
7. Cargo-Cult Programmering
Namnet på “lastkultprogrammering” kommer från ett specifikt etnografiskt fenomen som kallas “lastkult”. Lastkulturer uppträdde i södra Stilla havet efter andra världskriget, när den tvungna kontakten med avancerade civilisationer ledde infödingar att tänka att tillverkade produkter, som Coca-Cola, TV och kylskåp som togs med fraktfartyg till öarna, skapades av övernaturliga metoder; och om de utför magiska ritningar som liknar de västerländska tullarna kommer lasten fylld med varor att komma igen.
När vi begår antipattern av lastkultprogrammering gör vi i princip samma. Vi använder ramar, bibliotek, lösningar, mönster mönster, som fungerade bra för andra, utan att förstå varför vi gör det, eller hur teknikerna fungerar exakt.
I många fall utvecklare bara ritualt gör vad som är hip på den tiden utan något verkligt syfte. Denna övning är inte bara dålig eftersom det gör vår ansökan överflödigt uppblåst, men det kan också enkelt introducera nya fel i vår kod.
8. Lava Flow
Vi talar om “lava flöde” antipattern när vi behöver hantera kod som har redundanta eller lågkvalitativa delar den där verkar vara integrerad till programmet, men vi förstår inte helt vad det gör eller hur det påverkar hela applikationen. Detta gör det riskabelt att ta bort det.
Det händer vanligtvis med arvskod, eller när Koden skrevs av någon annan (vanligtvis utan korrekt dokumentation), eller när projektet rörde sig för snabbt från utveckling till produktionsfas.
Antipatterns namn kommer från dess resemblance med lava som kommer från vulkaner, det vill säga i början rör det sig snabbt och flytande utan att ta för många försiktighetsåtgärder, men det stärks senare och blir svårt att ta bort.
I teorin kan vi bli av med lavaströmmar med omfattande testning och refacto, men i praktiken, genomförandet är ofta svårt eller till och med omöjligt. Eftersom lavaflöden brukar ha högprestandekostnader, är det bättre att förhindra dem genom att skapa en väldesignad arkitektur och ett bra arbetsflöde från början.
9. Hård kodning
“Hårdkodning” är en välkänd antipattern mot vilken de flesta webbutvecklingsböcker varnar oss rätt i forordet. Hårdkodning är den olyckliga övningen i vilken Vi lagrar konfigurations- eller ingångsdata, till exempel en filväg eller ett fjärrd värdnamn, i källkoden snarare än att hämta det från en konfigurationsfil, en databas, en användarinmatning eller en annan extern källa.
Det största problemet med hård kod är det Det fungerar bara ordentligt i en viss miljö, och vid när villkoren ändras, vi behöver ändra källkoden, vanligtvis på flera separata platser.
10. Mjuk kodning
Om vi försöker mycket svårt att undvika fallet med hårdkodning kan vi enkelt springa in i en annan antipattern som heter “mjuk kodning”, vilket är dess motsatta.
Vid mjuk kodning, Vi lägger saker som borde vara i källkoden i externa källor, till exempel lagrar vi affärslogik i databasen. Den vanligaste anledningen till att vi gör det är rädslan att affärsreglerna kommer att förändras i framtiden, därför måste vi skriva om koden.
I extrema fall kan ett mjukkodat program bli så abstrakt och konvulerad att det är nästan omöjligt att förstå det (speciellt för nya lagmedlemmar), och extremt svårt att underhålla och felsöka.
