Webontwikkeling De 10 coderende antipatterns die u moet vermijden
Het ontwerpen van de architectuur van een website of een applicatie, of het opzetten van een effectieve codeerworkflow zorgt ervoor dat we vaak met terugkerende problemen omgaan. We hoeven deze problemen met het ontwerpen van software niet per definitie op te lossen, zoals oplossingen op architectonisch niveau kunnen opnieuw worden gebruikt op dezelfde manier als codefragmenten op het microniveau.
Ontwerppatronen zijn over het algemeen herbruikbare oplossingen voor bepaalde scenario's kan dat van pas komen om vaak voorkomende problemen op te lossen, en kan ons enorm helpen onze code te optimaliseren.
Hoewel ontwerppatronen geweldige middelen zijn om ons ontwikkelingsproces te verbeteren door gebruik te maken van beproefde formules, kunnen we soms ook fout gaan met deze formules. Dit worden antipatterns genoemd.
Wat zijn Antipatterns?
De voorwaarde “antipattern” werd bedacht in een boek genaamd AntiPatterns in 1998. Het verwijst naar hergebruikte oplossingen die in eerste instantie bruikbaar lijken, maar later blijkt om meer kwaad dan goed te doen.
Dit kan om verschillende redenen gebeuren, bijvoorbeeld als we de patronen niet in de juiste context, context of tijd gebruiken (oplossingen die in het verleden effectief waren, werken mogelijk niet altijd in het heden), of in andere gevallen het hele paradigma. was vanaf het begin gewoon slecht.
Antipatterns worden ook vaak genoemd patronen van mislukking. Het goede nieuws is dat het dat is mogelijk om ze te herkennen en te vermijden.
In deze post zullen we 10 veelgebruikte codeerantipatterns in webontwikkeling bekijken die ons kunnen misleiden door te denken dat we goed geoptimaliseerde code hebben. (Merk op dat de antipatronen die in dit bericht worden vermeld niet noodzakelijkerwijs hetzelfde zijn als wat u kunt vinden in het bovengenoemde boek.)
1. Voortijdige optimalisatie
Een goede timing is een cruciale factor in code-optimalisatie. We kunnen eenvoudig de antipatroon van “voortijdige optimalisatie”, als we aandacht besteden aan kleine efficiëntiewinsten en ze te vroeg in het ontwikkelingsproces optimaliseren, voordat we precies weten wat we willen doen.
Volgens het beroemde citaat van Donald Knuth “voortijdige optimalisatie is de wortel van al het kwaad“, wat een overdrijving kan zijn, maar laat nog steeds zien hoe ernstige problemen voortijdige optimalisatie later kunnen veroorzaken.
Als we optimaliseren voor prestaties voordat we een effectieve architectuur opzetten, kunnen we dat doen lagere codele leesbaarheid, maken debuggen en onderhoud moeilijker, en voeg overbodige delen toe naar onze code.
Om voortijdige optimalisatie te voorkomen, is het een goed idee om het YAGNI-programmeerprincipe te volgen, dat adviseert om “implementeer altijd dingen wanneer je ze echt nodig hebt, nooit wanneer je gewoon verwacht dat je ze nodig hebt.”
2. Het wiel opnieuw uitvinden
De “het wiel opnieuw uitvinden” antipattern wordt soms ook wel aangeduid als “ontwerpen in een vacuüm”. Het gebeurt wanneer we willen doe alles alleen en schrijf alles vanaf nul, zonder te zoeken naar reeds bestaande methoden, API's of bibliotheken.
Het wiel opnieuw uitvinden is niet alleen een tijdverspillend ding om te doen, maar maatwerkoplossingen, vooral voor basisfunctionaliteiten, zijn zelden zo goed als standaardoplossingen die al door veel ontwikkelaars en gebruikers zijn getest.
3. Dependency Hell
Het tegenovergestelde van de “het wiel opnieuw uitvinden” antipattern is een andere veel voorkomende antipattern genoemd “afhankelijkheid hel”.
Als we, in plaats van alles van nul te schrijven, we gebruiken te veel externe bibliotheken die afhankelijk zijn van specifieke versies van andere bibliotheken, we kunnen gemakkelijk een nauwelijks beheersbare situatie tegenkomen als we willen updaten, omdat deze afhankelijke dochterondernemingen in veel gevallen zijn onverenigbaar met elkaar.
De hel van afhankelijkheid kan worden opgelost door pakketbeheerders te gebruiken die dat kunnen op slimme wijze onderlinge afhankelijkheden bij te werken. Als we teveel overweldigd zijn door het probleem, kan refactoring ook een goed idee zijn.
4. Spaghetti-code
“Spaghetti-code” is waarschijnlijk het meest bekende coderingsantipatroon. Het beschrijft een applicatie die moeilijk te debuggen of te wijzigen is vanwege het ontbreken van een goede architectuur.
Het resultaat van een slecht softwareontwerp is een stelletje code die qua structuur vergelijkbaar is met een schaal met spaghetti, d.w.z.. verward en ingewikkeld. De leesbaarheid van de spaghetti-code is erg laag en het is meestal een bijna onmogelijke missie om te begrijpen hoe het precies werkt.
De spaghetticode komt meestal van de combinatie van verschillende slechte codeermethoden, zoals de code die geen juiste conditionele blokken bevat, met veel goto-statements, uitzonderingen en threads, die delen bevatten die ergens anders thuishoren, minimale relaties tussen objecten heeft, functies of methoden heeft die niet opnieuw gebruikt kunnen worden, of die niet goed gedocumenteerd is of helemaal niet.
5. Programmeren met permutatie
“Programmeren door middel van permutatie” of “programmeren per ongeluk” gebeurt wanneer we proberen een oplossing voor een probleem te vinden door achtereenvolgens te experimenteren met kleine aanpassingen, deze één voor één te testen en te beoordelen en uiteindelijk degene te implementeren die in eerste instantie werkt.
Programmeren door middel van permutatie kan eenvoudig nieuwe bugs introduceren in onze code, Erger nog, het zijn beestjes die we niet per se meteen herkennen. In veel gevallen is het ook onmogelijk om te anticiperen of de oplossing voor alle mogelijke scenario's zal werken, of niet.
6. Kopieer en plak de programmering
“Kopieer en plak programmering” treedt op als we het coderen van de code niet herhalen (DRY) niet volgen, en in plaats van generieke oplossingen te creëren, voegen we al bestaande codefragmenten in verschillende plaatsen in en bewerken ze later om in de gegeven context te passen.
Deze oefening resulteert in een code die zeer repetitief is, omdat de ingevoegde codedelen meestal alleen verschillen in kleine verschillen.
Kopiëren en plakken programmeren wordt niet alleen gepleegd door beginnende ontwikkelaars, maar ook door ervaren programmeurs, zoals velen van hen gevoelig zijn gebruik hun eigen vooraf geschreven, goed geteste codefragmenten voor specifieke taken, wat gemakkelijk kan leiden onbedoelde herhalingen.
7. Cargo-Cult-programmering
De naam van “cargo-cult programmeren” komt van een specifiek etnografisch fenomeen genaamd “vrachtcultus”. Ladingsculten verschenen in de Stille Zuidzee na de Tweede Wereldoorlog, toen het gedwongen contact met geavanceerde beschavingen autochtonen ertoe bracht te denken dat gefabriceerde producten, zoals Coca-Cola, tv's en koelkasten die door vrachtschepen naar de eilanden werden gebracht, waren gemaakt door bovennatuurlijke methoden; en als ze magische riten uitvoeren die vergelijkbaar zijn met de gewoonten van westerlingen, zal de lading gevuld met goederen terugkomen.
Wanneer we de antipattern van lading-cult programmeren, doen we in principe hetzelfde. We gebruiken kaders, bibliotheken, oplossingen, ontwerppatronen, enz. Die goed werkten voor anderen, zonder te begrijpen waarom we dit doen, of hoe de technologieën precies werken.
In veel gevallen ontwikkelaars gewoon doe ritueel wat hip is in die tijd zonder een echt doel. Deze praktijk is niet alleen slecht omdat het onze applicatie overbodig maakt, maar het kan ook gemakkelijk nieuwe bugs introduceren in onze code.
8. Lava Flow
We praten over de “lava stroom” antipattern wanneer dat nodig is omgaan met code die overtollige of onderdelen van lage kwaliteit heeft dat lijken integraal te zijn voor het programma, maar we begrijpen niet volledig wat het doet of hoe het de hele applicatie beïnvloedt. Dit maakt het riskant om het te verwijderen.
Het gebeurt meestal met oude code, of wanneer het code is geschreven door iemand anders (meestal zonder de juiste documentatie), of wanneer het project te snel van de ontwikkeling naar de productiefase ging.
De naam van de antipattern komt van zijn gelijkenis met lava afkomstig van vulkanen, dat wil zeggen eerst beweegt het snel en vloeiend zonder al te veel voorzorgsmaatregelen te nemen, maar later stolt het en wordt het moeilijk te verwijderen.
In theorie kunnen we lavastromen verwijderen met uitgebreide testen en refactoring, maar in de praktijk, de implementatie is vaak moeilijk of zelfs onmogelijk. Omdat lava-stromen meestal hoge prestatiekosten hebben, is het beter om ze te voorkomen door vanaf het begin een goed ontworpen architectuur en een goede workflow op te zetten.
9. Harde codering
“Harde codering” is een bekende antipattern waartegen de meeste webontwikkelingsboeken ons in het voorwoord waarschuwen. Harde codering is de ongelukkige praktijk waarin we slaan configuratie- of invoergegevens op, zoals een bestandspad of een externe hostnaam, in de broncode in plaats van het te verkrijgen uit een configuratiebestand, een database, een gebruikersinvoer of een andere externe bron.
Het grootste probleem met de harde code is dat het werkt alleen goed in een bepaalde omgeving, en bij wanneer de omstandigheden veranderen, we moeten wijzigen de broncode, meestal op meerdere afzonderlijke plaatsen.
10. Zachte codering
Als we heel hard proberen de valkuil van harde codering te vermijden, kunnen we gemakkelijk een andere antipattern tegenkomen “zachte codering”, wat precies het tegenovergestelde is.
In zachte codering, we plaatsen dingen die in de broncode zouden moeten staan in externe bronnen, we slaan bijvoorbeeld bedrijfslogica op in de database. De meest voorkomende reden waarom we dit doen, is de angst dat bedrijfsregels in de toekomst zullen veranderen, daarom zullen we de code moeten herschrijven.
In extreme gevallen kan een programma met een zachte codering zo abstract en ingewikkeld worden dat het bijna onmogelijk is om het te begrijpen (vooral voor nieuwe teamleden), en extreem moeilijk te onderhouden en debuggen.
