Share
We hebben allemaal onze slechte gewoonten. In dit artikel bespreken we een lijst met slechte praktijken die de moeite waard zijn om te onderzoeken, opnieuw te evalueren en onmiddellijk te corrigeren.
Opnieuw gepubliceerde zelfstudieOm de paar weken bekijken we enkele van onze favoriete lezers uit de geschiedenis van de site. Deze tutorial werd voor het eerst gepubliceerd in februari 2011.
Telkens wanneer ik een project open dat niet van mij is, gaat het gepaard met een vleugje angst dat ik een soort van Temple of Doom-scenario tegenkom, gevuld met valdeuren, geheime codes en die regel code die op wijziging, brengt de hele app naar beneden (en stuurt mogelijk een gigantische rotsblok naar me toe in een smalle gang).
Als we het mis hebben en alles goed gaat, afgezien van enkele kleine verschillen in "hoe ik het zou hebben gedaan", halen we opgelucht adem, steken we onze mouwen op en duiken we het project in.
Maar als we gelijk hebben ... Nou, dat is een heel ander verhaal.
Onze eerste gedachte bij het zien van deze onheilige puinhoop is meestal in de trant van: "Wie denkt deze man dat hij is?" En terecht; wat voor soort programmeur zou graag zo'n onheilige puinhoop van een project maken?
Vreselijke code is de verzameling van meerdere kleine snelkoppelingen of concessies.
Je eerste instinct is misschien om te veronderstellen dat de persoon die het project heeft gebouwd een beginneling is, of misschien is hij gewoon een idioot. Maar dat is niet altijd het geval.
Mijn theorie is dat vreselijke code de accumulatie van meerdere kleine snelkoppelingen of concessies is - net zo vaak als het het product is van onervarenheid of domheid. Dit maakt de Temple of Doom-app veel enger, omdat degene die het heeft gebouwd misschien net zo slim, slim en goed leesbaar is als jij. Ze zijn gewoon lui geworden of hebben dingen in een haast samengevoegd, en elk van die kleine snelkoppelingen is opgeteld in de kronkelende nachtmerrie die net op je schoot viel.
Nog enger, dit zou kunnen betekenen dat iemand ooit uw code heeft geërfd en onmiddellijk in tranen uitbarstte.
Het doet nooit pijn om je huidige praktijken opnieuw te bekijken en ervoor te zorgen dat je geen snelkoppelingen maakt die kunnen bijdragen aan de verloren slaap van iemand anders.
Laten we een paar minuten nemen en enkele veelgebruikte snelkoppelingen, concessies en andere slechte praktijken bespreken om ervoor te zorgen dat onze projecten geen angst opbrengen in de harten van de dorpelingen.
Voordat u een enkele regel code schrijft, moet u een degelijk aanvalsplan hebben.
Voordat u een enkele regel code schrijft, moet u een degelijk aanvalsplan hebben. Dit helpt u op het goede spoor te blijven en vermijdt dwalende code die u later zal verwarren, om nog maar te zwijgen over een andere arme ziel.
Eén benadering die mij tijd heeft bespaard - zowel in ontwikkeling als in commentaar - is om eerst een samenvatting in reacties te schrijven:
Zoals je ziet, weet ik bijna zonder precies te weten hoe het bestand eruit zal zien, zonder een enkele regel code te schrijven. Het beste van alles is dat je op deze manier een hele applicatie kunt plannen, en als je op een punt komt dat een functie een functionaliteit vereist die bij een andere past, alles wat je hoeft te doen is de opmerking veranderen.
Het vereist een verschuiving in de manier waarop je de ontwikkeling benadert, maar het zal je vaardigheden in projectorganisatie door het dak laten gaan.
NOTITIE: Sommige van deze opmerkingen zijn niet nodig; sommigen van hen zullen veranderen; anderen moeten worden toegevoegd - dat wordt verwacht. Dit is net zoiets als het schrijven van een schets voor een paper of het schrijven van een boodschappenlijstje: het houdt je gewoon op de goede weg als je de klus klopt.
Je hoeft niets te zeggen
Maar het enige ergste probleem met de meeste code die ik tegenkom is dat het slecht wordt becommentarieerd of helemaal niet wordt becommentarieerd.
Het maakt me verdrietig dat ik dit moet opschrijven. Wanneer iets zo gemakkelijk is als commentaar geven, zou het niet iets moeten zijn dat we elkaar eraan moeten herinneren om te doen.
Maar het enige ergste probleem met de meeste code die ik tegenkom is dat het slecht wordt becommentarieerd of helemaal niet wordt becommentarieerd. Dit voegt niet alleen een flinke hoeveelheid tijd toe aan mijn eerste kennismaking met het project, maar het garandeert ook vrijwel dat een fix gemaakt met behulp van een onconventionele methode uit noodzaak, me zal verwarren. Als ik vervolgens een refactoring doe, verbreek ik de app per ongeluk omdat ik de verzachtende omstandigheden die de fix hebben gemaakt nog niet heb aangetroffen.
Dit proces kan tussen de 10 minuten en 6 uur duren. (En je hebt me dit aangedaan, ik weet waar je woont. Ik kom voor jou.)
Dus zeg dit hardop:
ik, [zeg je naam], hierbij zweren om opmerkingen te maken in elke situatie waarin het doel van de code die ik heb geschreven niet meteen duidelijk is.
"Onmiddellijk duidelijk" verwijst naar code die niet zelfdocumenterend kan zijn (omdat het niet redelijk zou zijn om dit te doen) en / of niet een doodeenvoudige taak voltooit. Denk er op deze manier over na: als u gedurende een paar seconden moet stoppen met nadenken over uw oplossing, verdient dit waarschijnlijk een snelle uitleg..
Om mijn punt te illustreren, ga ik een voorbeeld gebruiken van een artikel dat ik onlangs voor beginners heb geschreven. Stel je de volgende situatie voor:
$ pieces = explode ('.', $ image_name); $ extension = array_pop ($ pieces);Wat doet dat? Moest je stoppen en erover nadenken? Weet je nog steeds niet zeker wat erin is opgeslagen? $ verlenging?
Kijk nog eens naar dat fragment, maar met een korte opmerking:
// Haal de extensie uit de afbeeldingsbestandsnaam $ pieces = explode ('.', $ Image_name); $ extension = array_pop ($ pieces);Vijf seconden tegelijk zullen op een grote manier oplopen.
Als je nu naar deze code kijkt, heb je geen extra hersenkracht nodig: je ziet de opmerking, ziet de code en hoeft nooit zijn intentie in twijfel te trekken.
Het kan je misschien maar vijf seconden bespiegelen, maar als je een complexe app hebt, zal vijf seconden tegelijk groot zijn.
Dus stop met het maken van excuses. Schrijf de verdomde opmerking.
Je offert duidelijkheid voor je beknoptheid
Goede voorbeelden van het opofferen van duidelijkheid voor beknoptheid omvatten onduidelijke namen van variabelen en het laten vallen van de accolades.
Het is een universele verleiding om iets gedaan te krijgen in zo weinig mogelijk karakters, maar die verleiding is zoiets als de verleiding om maar één ondergoed te hebben: Het wasgoed wordt snel gedaan, maar de problemen die ontstaan door uw keuze enorm opwegen tegen de voordelen.
Goede voorbeelden van het opofferen van duidelijkheid voor beknoptheid omvatten korte, onduidelijke namen van variabelen (zoals
$ a- wat doet$ aopslaan?) en de accolades laten vallen.Het laten vallen van gekrulde accolades van controlestructuren is een ergernis voor mijn huisdier. Als je niet van accolades houdt, schakel dan over naar Python. In PHP is het gewoon te gemakkelijk om de betekenis zonder hen te verliezen.
Bekijk bijvoorbeeld deze set van geneste if-else-instructies zonder accolades:
5) echo "Groter dan 5!"; anders echo "Minder dan 5!"; anders echo "Groter dan 10!"; echo "
Nog een opmerking. ";In een oogopslag lijkt het alsof de laatste regel alleen moet vuren als de waarde van
$ foois groter dan 10. Maar wat er feitelijk gebeurt, is een geval van onjuiste inspringen; de laatste echo-instructie schiet ongeacht wat$ foowinkel.Kun je het uitzoeken als je er een paar seconden naar kijkt en weet dat if-else-statements zonder accolades alleen de directe volgende regel beïnvloeden? Natuurlijk.
Moet je de energie verspillen met het uitzoeken van dat? Absoluut niet.
Het toevoegen van accolades voegt enkele regels toe, maar het verduidelijkt de uitspraak enorm, zelfs met de oneven inspringing:
5) echo "Groter dan 5!"; else echo "Minder dan 5!"; else echo "Groter dan 10!"; echo "
Nog een opmerking. ";Ja, het is goed om je code kort te houden, maar niet ten koste van de duidelijkheid. Het is de extra regels waard om ervoor te zorgen dat niemand zijn hoofd tegen een toetsenbord hoeft te slaan om je code te doorzoeken.
U volgt geen coderingsnorm
Kies een standaard en houd je eraan.
Schattig worden met je opmaak kan voldoen aan je artistieke behoeften, maar het doet niemand iets. Kies een standaard (ik raad de PEAR-coderingsnorm aan) en houd u eraan. Iedereen zal je bedanken. (Inclusief jezelf, ooit.)
Geloof me. Ik was die gast ooit - ik wilde een 'kenmerkende stijl' hebben - en ik verspilde veel uren aan het repareren van mijn gruwelijke opmaak later. Er is een tijd om anders te zijn en een tijd om het te doen zoals iedereen.
Als het op programmeren aankomt, beschouw het dan als een gesproken taal. Grammatica en interpunctie bestaan niet voor niets: we kunnen elkaar dus duidelijk verstaan wanneer we dingen opschrijven. Denk aan coderingsnormen zoals een nerdige versie van Strunk & White's Elements of Style - volgens de richtlijnen betekent dat mensen begrijpen wat je probeert te zeggen, niet dat je een saai persoon bent.
U dupliceert code
Je doet het verkeerd.
Probeer elk onderdeel van uw app te beschouwen als iets dat op een bepaald moment moet worden gewijzigd. Als dit het geval is, moet u dan meer dan één bestand bijwerken? Als je Ja hebt geantwoord, is het tijd om opnieuw te evalueren hoe je code schrijft.
Als je code op meer dan één plek in je app hetzelfde doet, doe je het verkeerd.
Je volgt geen ontwikkelingspatroon
Je zou altijd een structuur moeten hebben als je codeert.
Je zou altijd een structuur moeten hebben als je codeert. Ik wil niet zeggen dat je het MVC-patroon of iets dat even rigide is moet volgen, maar ik bedoel dat je moet weten hoe je componenten moet classificeren en waar ze naartoe moeten gaan.
Door een logisch ontwikkelingspatroon te volgen, worden veel beslissingen automatisch en hoeft iemand die uw code binnenkomt niet veel te gissen bij het zoeken naar een bepaalde functionaliteit in uw codebasis.
Het duurt niet lang en het zal je apps echt op een grote manier verduidelijken.
Je bent te slim voor je eigen bestwil
De eenvoudigste oplossing is meestal het meest geschikt
Er is een dunne lijn tussen een slimme oplossing en een gecompliceerde oplossing.
Het is altijd verleidelijk om een nieuwe, zoete truc uit te proberen die je hebt geleerd, maar we moeten de drang weerstaan om een complexe oplossing in een ruimte te forceren waar een simpele oplossing voldoende is..
Op een basisniveau is de eenvoudigste oplossing meestal het meest geschikt. Je probeert er uit te komen punt A naar punt B - een omweg maken punt Awesome is leuk, maar levert echt geen voordelen op.
Uw superzoete oplossing levert echter een probleem op waarbij iemand anders die specifieke oplossing misschien niet heeft gezien en gewoon verdwaalt. Het is niet omdat ze niet zo slim zijn als jij, ofwel; het is waarschijnlijk omdat ze dat specifieke artikel niet hebben gezien of niet probeerden een vierkant concept in een rond probleem te forceren.
Houd jezelf niet voor de gek, maar onthoud dat je overcomplicerende dingen moet voorkomen "alleen maar omdat."
Je bent een Wang
Vermijd het actief maken van uw code koste wat het kost.
Toen ik voor het eerst aan het ontwikkelen was, werkte ik met een man die een zelfbenoemde "expert" -programmeur was. Als ik een vraag had over een concept, gaf hij me nooit een duidelijk antwoord; om het antwoord op mijn oorspronkelijke vraag te krijgen, moest ik een paar voorlopige vragen beantwoorden om te bewijzen dat u het antwoord aankunt.
Deze man was ook erg goed in het schrijven van code die cryptisch, versluierd en gewoon in de war was.
Bestanden zoals die van hem zijn het resultaat van programmeurs die denken dat ze hun code moeilijk leesbaar moeten maken om 'de idioten buiten te houden'.
De algemene filosofie hierachter is meestal: "Als je niet slim genoeg bent om deze code te begrijpen, zou je er in de eerste plaats niet in moeten zijn."
Dit is een diep misleide en anti-sociale benadering van programmeren. Het is een zeer elitaire manier om naar dingen te kijken, en het laat zien dat de programmeur het contact met zijn beginnerstammen heeft verloren, toen hij zelf hulp nodig had.
Vermijd het actief maken van uw code koste wat het kost. Het maakt je niet cooler of slimmer, en het versterkt het respect niet. Het maakt je gewoon een wang.
Kerel, waar heb je het over??
Als je stopt met leren, blijven de projecten waar je aan werkt in welke tijdsperiode dan ook die je hebt besloten te regelen.
Naast de snelkoppelingen en algemene luiheid hierboven, is een ander ding dat je misschien tegenhoudt een gebrek aan voortdurend leren en vooruitgang boeken.
Technologie verandert niet omdat de gemeenschap in het algemeen zich verveelt en we besloten om op te knappen; de meeste nieuwe technologieën komen naar voren om efficiënter en gemakkelijk bestaande problemen op te lossen. Als je ervoor kiest om de voortgang te negeren, kies je ervoor om het langzame proces van het marginaliseren van je vaardigheden te starten.
Hier zijn een paar dingen die we allemaal kunnen stoppen om ervoor te zorgen dat onze skillsets up-to-date zijn, allemaal zonder dat we onze weekends moeten opgeven.
Je probeert het helemaal zelf te doen
Ontdek welke van deze programmeurs een vergelijkbare aanpak hebben en laat ze u informeren over het grote nieuws.
Je kunt de hele gemeenschap niet bijhouden. Zoals iedereen die ooit heeft geprobeerd om een abonnement bij meer dan 200 technische blogs bij te houden, zegt, kan dit eenvoudig niet binnen een redelijk tijdsbestek worden gedaan..
Gelukkig zijn er binnen de community mensen die hun tijd besteden aan het kijken naar de voortgang van de technologie en het rapporteren van hun bevindingen. Als je de tijd neemt om erachter te komen welke van deze programmeurs een vergelijkbare benadering en stijl hebben, kun je ze laten invullen op het grote nieuws.
Kijken naar 2-5 van deze "early adopter" -type bloggers kan voordeliger zijn dan zich abonneren op elke technische blog die je tegenkomt om verschillende redenen:
Onder de PHP-bloggers die ik vertrouw zijn David Walsh en Chris Shiflett.
Ik wil alleen maar suggereren dat je je als programmeur meer vervuld zult voelen en je talenten steeds meer zult zien toenemen als je ervoor kiest om altijd naar het volgende programmeerniveau te kijken.
Als je niet iets doet dat je uitdaagt, is er iets mis. Het vinden van nieuwe uitdagingen binnen projecten is het grootste deel van wat het belonen van programmeren maakt (of het zou tenminste moeten zijn).
Stel uzelf de volgende vragen wanneer u naar nieuwe projecten gaat kijken:
Houd in gedachten: ik heb het hier niet over het doen van iets heel ingewikkelds.
Het kan zo simpel zijn als onthouden om Docblocks toe te voegen aan uw objecten, of zo complex als het compatibel maken van uw app met XMLRPC, zodat het voor gebruikers eenvoudiger is om updates te plaatsen.
Probeer je gewoon niet te vestigen en overtuig jezelf dat je alles hebt geleerd wat je gaat leren. Dat is wanneer het lelijk voor je zal worden.
Bespreek altijd je code met je mede programmeurs.
De beste manier om te verbeteren, is door je code te bespreken met je mede-programmeurs. Dit kan via meerdere wegen: als u zich bijzonder extrovert voelt, een zelfstudie schrijven of een open-sourceproject vrijgeven; als je iets van die omvang niet voelt, kun je misschien een communityforum bezoeken en hulp bieden aan de nieuwkomers.
"Hoe helpt het om de noobs te helpen me vooruit te komen?" je vraagt. Meestal, als je een oplossing plaatst die kan worden geoptimaliseerd, gaan andere ervaren programmeurs van start en bieden tweaks aan. Dus deze aanpak is een dubbel-zweem van awesomeness: je helpt niet alleen de gemeenschap vooruit te helpen door je kennis aan te bieden aan beginners, maar je bent je eigen skillset aan het verscherpen door je karbonades op te hangen zodat iedereen het kan zien en je kan helpen ontwikkelen.
Als je iets nieuws en gaafs wilt doen dat iets te ingewikkeld is om in een echt project te stoppen, is de beste manier om te leren een bijproject te starten dat deze techniek gebruikt.
Op die manier kunt u in uw eigen tempo vooruitgang boeken, in uw vrije tijd en nooit het risico lopen een deadline te missen of "het verkeerd te doen".
Als we het goed doen, zouden we altijd moeten verbeteren. En de logica vertelt ons dat als we nu beter zijn, we slechter zijn geweest. En als we die redenering ver genoeg volgen, was er een punt waarop we verschrikkelijk waren.
Ik weet dat als ik terugkijk naar een deel van de code die ik in het verleden heb geschreven, ik geschokt ben.
We zullen nooit perfect zijn. Maar we kunnen er alles aan doen om ervoor te zorgen dat we zo dichtbij mogelijk komen.
Wat zijn uw dierenparagnosten als het gaat om de code van andere ontwikkelaars? Laat het me weten in de comments!
Accentsconagua