Webontwikkeling: de 10 coderingsantipatterns 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 se op te lossen, omdat oplossingen op architectonisch niveau op dezelfde manier kunnen worden hergebruikt als codefragmenten op microniveau .

Ontwerppatronen zijn over het algemeen herbruikbare oplossingen voor bepaalde scenario's, die handig kunnen zijn om vaak voorkomende problemen op te lossen, en kunnen 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 term 'antipattern' werd in 1998 in een boek genaamd AntiPatterns verzonnen. Het verwijst naar hergebruikte oplossingen die aanvankelijk bruikbaar lijken, maar later meer kwaad dan goed blijken 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 faalpatronen genoemd. Het goede nieuws is dat het mogelijk is om ze te herkennen en te vermijden .

In deze post zullen we 10 algemene coderingantipatterns 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 gemakkelijk de antipatroon van "voortijdige optimalisatie" reproduceren, 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 is "voortijdige optimalisatie de wortel van alle kwaad", wat overdreven kan zijn, maar laat nog zien hoe ernstige problemen voortijdige optimalisatie later kunnen veroorzaken.

Als we optimaliseren voor prestaties voordat we een effectieve architectuur opzetten, kunnen we de leesbaarheid van de code verminderen, het debuggen en het onderhoud moeilijker maken en overtollige onderdelen aan onze code toevoegen.

Om voortijdige optimalisatie te voorkomen, is het een goed idee om het YAGNI-programmeerprincipe te volgen, dat adviseert om "altijd dingen te implementeren wanneer u ze echt nodig hebt, nooit wanneer u alleen maar verwacht dat u ze nodig hebt."

2. Het wiel opnieuw uitvinden

Het antipattern "wiel opnieuw uitvinden" wordt soms ook wel "ontwerpen in een vacuüm" genoemd . Het gebeurt wanneer we alles alleen willen doen en alles vanaf nul willen schrijven, zonder te zoeken naar reeds bestaande methoden, API's of bibliotheken.

Het wiel opnieuw uitvinden is niet alleen tijdrovend, maar op maat gemaakte oplossingen, vooral voor basisfunctionaliteiten, zijn zelden zo goed als standaardoplossingen die al door veel ontwikkelaars en gebruikers zijn getest.

3. Dependency Hell

Het tegenovergestelde van het antipattern "wiel opnieuw uitvinden" is een ander veel voorkomend antipattern genaamd "afhankelijkheids-hel" .

Als we, in plaats van alles vanaf nul te schrijven, te veel externe bibliotheken gebruiken die afhankelijk zijn van specifieke versies van andere bibliotheken, kunnen we gemakkelijk een nauwelijks beheersbare situatie tegenkomen als we willen updaten, omdat deze afhankelijkheidsrelaties in veel gevallen onverenigbaar zijn met elkaar .

De hel van afhankelijkheid kan worden opgelost door pakketbeheerders te gebruiken die in staat zijn om onderling afhankelijke afhankelijkheden op slimme wijze 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 pover softwareontwerp is een groep code die qua structuur vergelijkbaar is met een schaal met spaghetti, dwz 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.

Spaghetti-code komt meestal voort uit de combinatie van verschillende slechte codeermethoden, zoals de code die geen juiste conditionals-blokken bevat, met veel goto-statements, uitzonderingen en threads, die delen bevatten die ergens anders thuishoren, minimale relaties tussen objecten heeft, functies heeft of methoden die niet opnieuw kunnen worden gebruikt of die niet goed of helemaal niet zijn gedocumenteerd.

5. Programmeren met permutatie

"Programmeren met permutatie" of "per ongeluk programmeren" gebeurt wanneer we proberen een oplossing voor een probleem te vinden door achtereenvolgens met kleine aanpassingen te experimenteren, deze één voor één te testen en te beoordelen en uiteindelijk de eerste te implementeren die in eerste instantie werkt.

Programmeren met permutatie kan gemakkelijk nieuwe bugs in onze code introduceren, erger nog, het zijn bugs die we niet per se in één keer 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

"Kopiëren en plakken programmeren" vindt plaats als we het coderen principe "Niet herhalen" (DRY) niet volgen, en in plaats van generieke oplossingen te creëren, voegen we al bestaande codefragmenten in verschillende plaatsen in en later bewerken ze om in de gegeven context.

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 ervaren programmeurs, omdat veel van hen geneigd zijn om hun eigen vooraf geschreven, goed geteste codefragmenten te gebruiken voor specifieke taken, wat gemakkelijk kan leiden tot onbedoelde herhalingen .

7. Cargo-Cult-programmering

De naam van "ladingcultusprogrammering" komt van een specifiek etnografisch fenomeen dat "ladingcultus" wordt genoemd. 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 weer komen.

Wanneer we de antipattern van lading-cult programmeren begaan, 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 genoemde technologieën precies werken.

In veel gevallen doen ontwikkelaars gewoon 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 hebben het over de 'lava flow'-antipatroon wanneer we te maken hebben met code met overbodige of lage kwaliteit onderdelen die integraal lijken te zijn aan 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 legacy code, of wanneer de code is geschreven door iemand anders (meestal zonder de juiste documentatie), of wanneer het project te snel is verhuisd van de ontwikkeling naar de productiefase.

De naam van de antipattern komt van zijn gelijkenis met lava afkomstig van vulkanen, dwz in eerste instantie 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 de lavastromen verwijderen met uitgebreide testen en refactoren, maar in de praktijk is de implementatie 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 configuratie- of invoergegevens opslaan, zoals een bestandspad of een externe hostnaam, in de broncode in plaats van deze te verkrijgen uit een configuratiebestand, een database, een gebruikersinvoer of een andere externe bron .

Het grootste probleem met harde code is dat het alleen goed werkt in een bepaalde omgeving, en op elk moment dat de omstandigheden veranderen, moeten we de broncode wijzigen, meestal op meerdere afzonderlijke plaatsen.

10. Zachte codering

Als we ons uiterste best doen om de valkuil van harde codering te omzeilen, kunnen we gemakkelijk een ander antipatroon tegenkomen dat we "soft coding" noemen, wat precies het tegenovergestelde is.

Bij softcodering plaatsen we 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 soft gecodeerd programma zo abstract en ingewikkeld worden dat het bijna onmogelijk is om het te begrijpen (vooral voor nieuwe teamleden), en extreem moeilijk te onderhouden en te debuggen .