10 redenen waarom u code-optimalisatie nodig hebt
Terwijl we code schrijven, nemen we voortdurend beslissingen en kiezen we oplossingen die in eerste instantie gelijk kunnen lijken. Later blijkt dat meestal sommige keuzes resulteren in een efficiënter programma dan andere, dus een natuurlijke zoektocht naar de beste codeerpraktijken en optimalisatietechnieken ontstaat natuurlijk, en dat beginnen we zie het hele ontwikkelingsproces als een optimalisatieprobleem om op te lossen.
Hoewel optimalisatieproblemen niet de enige zijn waar ontwikkelaars geregeld mee omgaan, zijn er bijvoorbeeld ook beslissingsproblemen en zoekproblemen, optimalisatie is de taak die de verschillende fasen van webontwikkeling omvat, waarschijnlijk de meest.
Code-optimalisatie kan op verschillende niveaus plaatsvinden, afhankelijk van hoe dicht de optimalisatie die we uitvoeren, is om code te bewerken. Bij webontwikkeling kunnen we alleen optimalisaties op hoger niveau uitvoeren, als optimalisaties op assemblage- of runtime-niveau zijn geen optie voor ons, maar we hebben nog steeds veel kansen.
We kunnen onze code op architectonisch niveau optimaliseren met slimme ontwerppatronen, op het broncodeniveau door gebruik te maken van de beste codeermethoden en de juiste tools te gebruiken, en we kunnen ook de prestaties van ons team verbeteren door introductie van codeerstijlgidsen in onze workflow.
Welke techniek we ook kiezen, er is een vuistregel dat elke code-optimalisatie moet volgen: we moeten altijd voer de optimalisatie uit op een manier die de betekenis van de code niet verandert.
De voordelen van code-optimalisatie groeien in lijn met de groei van ons project en zo zelfs in eerste instantie kunnen kleine projecten mettertijd groot worden, het verwerven van solide code-optimalisatievaardigheden heeft bijna altijd meetbare positieve resultaten.
1. Schonere codebasis
Naarmate een project rijpt, en meer en meer ontwikkelaars beginnen eraan te werken, overlappingen en overlappingen verschijnen meestal vroeg of laat en plotseling beseffen we dat we nauwelijks begrijpen wat er aan de hand is.
Het is geen toeval dat het in gedachten houden van het DRY (Do not Repeat Yourself) -principe één van de hoekstenen is van effectieve softwareontwikkeling. Een goed gestructureerde, zorgvuldig geoptimaliseerde codebasis waarin we in staat zijn hergebruik dezelfde elementen meerdere keren is altijd strakker en opgeruimder en daardoor veel gemakkelijker te begrijpen en te gebruiken.
2. Hogere consistentie
Consistentie is als huishoudelijk werk, wanneer het goed wordt verzorgd, merkt niemand het op, maar wanneer het wordt verwaarloosd, ziet de hele plaats er rommelig uit en bevinden we ons in chaos.
Het is moeilijk om volledige consistentie te bereiken het waarborgen van achterwaartse compatibiliteit kan uiteindelijk een verbetering in de weg staan, maar aandacht schenken aan gebruikmakend van coherente coderichtlijnen, compatibele API's en consistente normen kan de pijn zeker verminderen.
Het is vooral belangrijk om de codeconsistentie in het achterhoofd te houden wanneer we moeten omgaan met oude code, of in geval van grotere projecten dat betrekken veel ontwikkelaars.
3. Snellere sites
Optimalisatie van code is vergelijkbaar met het kopen van een snellere auto. Dientengevolge, onze code wordt sneller uitgevoerd, en onze site of applicatie verbruikt minder geheugen dan voorheen. Hoewel het optimalisatieproces kan extra tijd en geld kosten, het resultaat is een betere ervaring, niet alleen voor ontwikkelaars maar ook voor eindgebruikers.
Snellere code houdt in kortere laadtijd van de pagina ook, wat een groot probleem is in beide werelden van zoekmachine-optimalisatie en conversiemarketing. Onderzoek zegt dat “bijna de helft van de webgebruikers verwacht dat een site binnen 2 seconden of minder wordt geladen en dat ze de neiging hebben om een site te verlaten die niet binnen 3 seconden is geladen”, dus snelheid is duidelijk geen gebied dat we veilig kunnen negeren.
4. Betere leesbaarheid van code
Leesbaarheid is een belangrijk aspect van de code-onderhoudbaarheid. Onzorgvuldige code met ad hoc-opmaak is moeilijk te lezen, daarom moeilijk te begrijpen, vooral voor ontwikkelaars die nog niet bekend zijn met een project.
We kunnen onszelf beschermen tegen de pijn van het omgaan met niet-codeerbare code als we bepaalde codeoptimalisatietechnieken toepassen, zoals:
- gebruikmakende coherente naamconventies met betekenisvolle namen, zoals BEM
- consistente opmaak met logisch gebruik van inkeping, witruimte en verticale afstand
- onnodige ruis vermijden, zoals vanzelfsprekende, voor de hand liggende opmerkingen
Dit is de reden waarom grote projecten, zoals WordPress, jQuery en Mootools, duidelijke coderingsstijlgidsen hebben die elke betrokken ontwikkelaar moet volgen.
5. Efficiëntere refactoring
Het komt vaak voor bij webontwikkeling dat we code van iemand anders erven en snel begrijpen dat dat zo is verre van optimaal te zijn, of in termen van structuur, prestaties of onderhoudbaarheid. Hetzelfde kan gebeuren met onze eigen eerdere projecten die we schreven toen we veel minder ervaring hadden met programmeren.
In andere gevallen de doelen van een verder geweldige projectverandering in de loop van de tijd, en we moeten het doen prioriteit geven aan andere dingen in de toepassing dan voorheen.
We praten over refactoring wanneer we verander (ruim) bestaande code op om het te optimaliseren zonder een van zijn functionaliteiten te veranderen. Refactoring moet met grote zorgvuldigheid worden uitgevoerd, alsof het op de verkeerde manier is gedaan, we kunnen gemakkelijk eindigen met een codebasis die nog minder optimaal is dan het origineel was.
Gelukkig hebben we veel goed geteste technieken in handen die het refactoren van een probleemloos proces mogelijk maken.
6. Meer eenvoudige foutopsporing
Foutopsporing neemt een aanzienlijk deel van de webontwikkelingsworkflow op, en het is meestal een vervelende of zelfs ontmoedigende taak. Het is al moeilijk genoeg om onze eigen code te debuggen, maar dat is het wel veel erger als we de fouten in iemand anders moeten vinden, vooral als het zoiets is als een neverending spaghetti-code die alleen maar functies gebruikt.
Slim ontwerp en architecturale patronen, zoals objecten gebruiken en verschillende modules, en duidelijke coderingsrichtlijnen kan het foutopsporingsproces vergemakkelijken, ook al is het hoogstwaarschijnlijk nog steeds niet onze meest geliefde taak.
7. Verbeterde workflow
Veel webontwikkelingsprojecten worden uitgevoerd door verspreide teams, zoals open-sourcecommunity's of externe teams. Een van de moeilijkste dingen bij het beheer van zo'n workflow is het vinden van een manier die communicatie effectief genoeg maakt stelt teamleden in staat elkaar gemakkelijk te begrijpen, en niet voortdurend discussiëren over standaardwaarden.
Overeengekomen best practices en stijlgidsen kunnen de kloof overbruggen tussen mensen met verschillende achtergronden, om nog maar te zwijgen van de gebruikelijke communicatieontberingen tussen ontwerp- en ontwikkelingsteams in de meeste webprojecten..
Code-optimalisatie is ook workflow optimalisatie, alsof teamleden een gemeenschappelijke taal spreken en dezelfde verklaarde doelen delen, ze zullen ook in staat zijn om samen te werken zonder veel minder gedoe.
8. Gemakkelijker Code Onderhoud
Hoewel het bouwen van iets van de grond af meer leuk is dan het onderhouden van reeds bestaande code, moeten we soms nog steeds codeonderhoud uitvoeren. Werken met reeds bestaande systemen kan ons ook nieuwe inzichten geven over code-optimalisatie, omdat het een andere ervaring is dan vroege optimalisaties in een nieuw project.
Bij software-onderhoud bevinden we ons al in een fase waarin we echte prestatie- en efficiëntieproblemen kunnen oplossen en kunnen werken met echte gebruikers in plaats van hypothetische use-cases..
Code-onderhoud krijgt meestal weinig respect in ontwikkelaarscirkels, maar het kan nog steeds een lonende taak zijn als we de beste werkwijzen volgen, zoals het gebruik betrouwbare versiecontrole, afhankelijkheidsbeheer, enscenering en testplatforms, en goed zorg voor documentatie.
9. Snellere functieontwikkeling
Constante innovatie is de kern van relevant blijven in ons vakgebied, zoals als we in een tijdje niets nieuws aan onze gebruikers hebben laten zien, kunnen we snel achterblijven. Het uitbreiden van een project en het toevoegen van nieuwe functies is meestal veel sneller als we werken met een goed geoptimaliseerde, schone codebase.
Afgezien van de al besproken code-optimalisatiemethoden, kan het ontwikkelen van functies ook in een stroomversnelling komen als we het bijhouden moderne projectmanagementmethoden, bijvoorbeeld als we iteratieve levenscyclusmodellen gebruiken in plaats van het traditionele watervalmodel.
10. Kleinere technische schuld
De term 'technische schuld' werd bedacht door Ward Cunningham, de programmeur die ook de eerste wiki ontwikkelde. Het vergelijkt de gevolgen van onze slechte programmeringsbeslissingen die zich in de loop van de tijd ontwikkelen tot financiële schulden waarbij mensen in de toekomst rente betalen om snel geld in het heden te krijgen.
Deze minder dan optimale beslissingen manifesteren zich meestal in de vorm van snelle oplossingen, kopiëren en plakken programmeren, harde codering, ladingcultus programmeren en andere codering antipatterns en slordige werkgewoonten.
Het is eigenlijk onmogelijk om technische schulden volledig te vermijden, omdat zelfs goede beslissingen in de toekomst minder gewenste gevolgen kunnen zijn, maar als we onze code ijverig optimaliseren, zullen we dat zeker zijn belast met een veel kleinere technische schuld.
