Slechte gewoontes zijn moeilijk te doorbreken en nog moeilijker als je je niet realiseert dat wat je doet je werk ondermijnt. Als je het wel weet, maar het je niet kan schelen, dat zou het ergste zijn. Maar je bent hier toch?
Als programmeur heb ik veel slechte praktijken gezien, niet alleen rond code, maar ook rond teamwork vaardigheden. Ik heb zelf ook veel van deze slechte gewoontes in de praktijk gebracht. Hier zijn mijn top 35 slechte programmeergewoonten, georganiseerd in vier categorieën: code organisatie, teamwerk, het schrijven van code, en testen en onderhoud.
Code organisatie
1. Zeggen, “Ik zal het later repareren”
De gewoonte om code fixes uit te stellen is niet alleen een probleem van prioriteiten. Het organiseren van uw issue tracker kan enige vooruitgang opleveren, maar u moet ook een manier hebben om kleinere problemen op te sporen. Het toevoegen van “TODO” commentaar is een snelle manier om er zeker van te zijn dat u niets mist.
2. Aandringen op een one-liner oplossing
Het obsessief schrijven van efficiënte, elegante stukken code is een veel voorkomende eigenschap van programmeurs. Het is als het oplossen van een puzzel-je vindt een combinatie van functies en reguliere expressies die 20 regels code veranderen in 2 of 3. Helaas resulteert dit niet altijd in leesbare code, en dat is over het algemeen het veel belangrijkere resultaat. Maak uw code eerst toegankelijk, dan pas slim.
3. Het maken van zinloze optimalisaties
Een andere plaats waar we vaak onze inspanningen misplaatsen zijn optimalisaties. Het klinkt geweldig om de grootte van je website een paar bytes te verkleinen, maar maakt gzip het niet goed? En zijn requests niet belangrijker? Optimaliseer pas aan het eind van een project, want meestal veranderen de eisen en is uw tijd verspild.
“Voorbarige optimalisatie is de wortel van alle kwaad.”
-Donald Knuth
4. De website optimaliseren
Als ik in de loop der jaren iets heb geleerd van het bekijken van andermans code, is het wel dat ontwikkelaars het aanpakken van problemen met de codeerstijl het vaakst uitstellen. Misschien is het moeilijk voor onervaren codeurs om te zien wat voor goeds er uit het aanpakken van styling problemen zal komen, maar na verloop van tijd zal het duidelijk worden dat zodra de kwaliteit van de code ontspoort, een sneeuwbaleffect elk project zal veranderen in een complete puinhoop. Wees strikt over best practices, zelfs als ze verwaarloosbaar lijken. Stel code checking en linting tools in om jezelf ruimte te geven om je zorgen te maken over de belangrijkere dingen.
5. Dingen onder het tapijt vegen
Hetzij door uitzonderingen op te vangen en te negeren, of door bibliotheken te gebruiken die geen fouten rapporteren (zoals jQuery), er zijn veel manieren om dingen onder het tapijt te vegen. Maar wanneer een van die fouten een prioriteit wordt, zal de uitdaging om ze op te lossen vele malen groter zijn, gezien het feit dat je geen idee zult hebben waar te beginnen. Een gemakkelijke manier om dit te voorkomen is door die genegeerde fouten te loggen, zodat u ze later kunt bestuderen.
6. Gebruik namen die geen informatie toevoegen
Naamgeving is moeilijk, maar er is een gemakkelijke manier om ervoor te zorgen dat uw variabele en functienamen op zijn minst van fatsoenlijke kwaliteit zijn. Zolang de namen een soort informatie toevoegen die de rest van de code niet overbrengt, zullen andere ontwikkelaars het gemakkelijker hebben om uw code te lezen. De reden dat naamgeving zo belangrijk is, is dat namen een algemeen idee kunnen geven van wat de code doet. Het kost meer tijd als je in de berekeningen moet graven om erachter te komen wat een stukje code doet, maar een goede naam kan je helpen om in een paar seconden te begrijpen wat de code doet.
7. Bewezen best practices negeren
Code reviews, test-driven development, quality assurance, deployment automation – deze praktijken, en verschillende anderen, hebben hun waarde bewezen in talloze projecten, wat de reden is waarom ontwikkelaars er voortdurend over bloggen. Een goede referentie voor deze best practices is het boek Making Software: What Really Works, and Why We Believe It. Neem de tijd om te leren hoe je ze goed uitvoert, en je ontwikkelproces zal in al je projecten verbeteren op manieren die je zullen verrassen.
Teamwork
8. Te vroeg afzien van plannen
Een trefzekere manier om uw systeem ondoorgrondelijk te maken, is u niet vast te leggen op een plan. U kunt altijd zeggen, wanneer uw code wordt bekritiseerd, dat het plan niet compleet is. Echter, het hebben van half-afgemaakte modules zal leiden tot strak gekoppelde code zodra u probeert om die onafgemaakte modules met elkaar te laten werken. Dit soort complicaties komt ook naar voren wanneer de leiding van een project van rol verandert en de nieuwe leiding besluit dat het belangrijker is om het op hun manier te doen dan architectonische consistentie.
9. Vasthouden aan een plan dat weinig kans heeft om te werken
Net zoals het opgeven van je plannen problemen kan veroorzaken, kan dat ook het vasthouden aan een plan dat niet werkt. Daarom moet u uw ideeën delen met uw team om feedback en advies te krijgen als het moeilijk wordt. Soms kan een ander perspectief het verschil maken.
10. De hele tijd in je eentje werken
Je moet ernaar streven om je voortgang en ideeën met het team te delen. Soms denk je dat je iets op de juiste manier aan het bouwen bent, maar dat is niet zo, dus constante communicatie is erg waardevol. Het is ook gunstig voor andere mensen als je met hen samenwerkt. Hun werk wordt vaak beter als je ideeën met hen bespreekt en mentor bent voor de minder ervaren leden van je team, die meer kans hebben om vast te lopen.
11. Weigeren om slechte code te schrijven
Er komt een moment in het leven van elke ontwikkelaar dat deadlines je dwingen om vreselijke code te schrijven, en dat is oké. Je hebt geprobeerd je klant of manager te waarschuwen voor de gevolgen, maar ze houden vast aan de deadline, dus nu is het tijd om te coderen. Of misschien is er een dringende bug die niet kan wachten tot je met een nette oplossing komt. Daarom is het belangrijk om als programmeur veelzijdig te zijn en zowel heel snel slechte code als goede code te kunnen schrijven. Hopelijk kun je de code opnieuw bekijken en de technische schuld terugbetalen.
12. Anderen de schuld geven
Het is geen geheim dat arrogantie een al te veel voorkomende eigenschap is onder ontwikkelaars en andere technische professionals. Verantwoordelijkheid nemen voor je fouten is een deugd die je zal doen schitteren onder je collega’s. Wees niet bang om toe te geven dat je een fout hebt gemaakt. Als je daar eenmaal vrede mee hebt, ben je vrij om te leren waarom je die fout hebt gemaakt en hoe je die kunt vermijden. Als je het niet toegeeft, wordt leren onmogelijk.
13. Niet delen met je team wat je hebt geleerd
Jouw waarde als ontwikkelaar wordt niet alleen geplaatst op de code die je schrijft, maar ook op wat je leert tijdens het schrijven ervan. Deel je ervaringen, schrijf er commentaar over, laat anderen weten waarom dingen zijn zoals ze zijn, en help hen nieuwe dingen te leren over het project en de fijne kneepjes ervan.
14. Te traag zijn met het geven van feedback aan managers/klanten
Een van de meest waardevolle karaktereigenschappen van een vakman ligt in het zorgen dat iedereen zoveel mogelijk op dezelfde lijn zit over het werk. De reden hiervoor is niet zodat uw manager spreadsheets kan vullen. Het is ook voor uw eigen gewin: Je zult minder onzekerheden hebben en de onzekerheid over de levensduur en toekomst van het project verminderen.
15. Google niet genoeg gebruiken
De beste manier om een complex probleem snel op te lossen is het helemaal niet te hoeven oplossen. Bij twijfel, Google het. Natuurlijk kunt u de ingenieur naast u lastig vallen, maar zelden zal hij een antwoord kunnen geven dat zo gedetailleerd is als Stack Overflow, om nog maar te zwijgen van het feit dat u zijn werk ook onderbreekt.
16. Overwaardering van je persoonlijke stijl
Streef er altijd naar om je werkstijl en omgevingsopzet af te stemmen met je team. Idealiter zou iedereen in uw team onder vergelijkbare omstandigheden moeten werken en dezelfde coderingsstijl moeten volgen. Dingen op jouw manier doen kan leuker zijn, maar collega’s zijn misschien niet gewend aan jouw codeerstijl, en als die ongebruikelijk is, zal het voor de volgende ontwikkelaar moeilijker zijn om te werken aan wat jij hebt gebouwd.
17. Een persoonlijke gehechtheid hebben aan je code
Wanneer iemand commentaar heeft op je code, vat het dan niet persoonlijk op. Uw code moet op een solide basis staan; dat wil zeggen, u moet kunnen uitleggen waarom u het op die manier hebt geschreven. Als het verbetering behoeft, is dat alleen een weerspiegeling van de juistheid van de code, niet van uzelf.
Code schrijven
18. Niet weten hoe te optimaliseren
Een goede optimalisatiestrategie vergt enige ervaring om goed te krijgen. Het vergt verkenning, analyse, en kennis van elk systeem dat bij een proces betrokken is. Informeer jezelf over deze dingen. Leer over algoritmische complexiteit, database query evaluatie, protocollen, en hoe de prestaties te meten in het algemeen.
19.
Je kunt maar zoveel weten, maar de reden waarom je moet blijven leren, is dat elk nieuw probleem een andere context met zich meebrengt en een ander gereedschap vereist – een gereedschap dat meer van toepassing is op de taak bij de hand. Sta open voor nieuwe bibliotheken en talen. Neem geen beslissingen die strikt gebaseerd zijn op wat je weet.
20. Geen moeite doen om je tools en IDE onder de knie te krijgen
Elke nieuwe sneltoets, snelkoppeling of parameter die je leert tijdens het gebruik van de tools waar je dagelijks mee werkt, zal een positiever effect hebben op je codeersnelheid dan je beseft. Het gaat er niet om een paar seconden te besparen door een sneltoets te gebruiken; het gaat erom het wisselen van context te verminderen. Hoe meer tijd u besteedt aan elke kleine handeling, hoe minder tijd u beschikbaar hebt om na te denken over waarom u het doet en over wat er daarna komt. Het beheersen van sneltoetsen zal uw geest bevrijden.
21. Foutmeldingen negeren
Ga er niet van uit dat je weet wat er mis is met je code zonder zelfs maar een foutmelding te lezen, of dat je er snel genoeg achter zult komen. Meer informatie hebben over een probleem is altijd beter, en de tijd nemen om die informatie te verzamelen zal op de lange termijn meer tijd besparen.
22. Het romantiseren van uw ontwikkelaarstoolkit
Soms is uw voorkeurseditor of opdrachtregeltool niet het beste gereedschap voor de taak bij de hand. Visual Studio is geweldig voor het schrijven van IDE’s, Sublime is geweldig voor dynamische talen, Eclipse is geweldig voor Java, enzovoort. Je kunt van vim of emacs houden, maar dat betekent niet dat het het juiste gereedschap is voor elke taak.
23.
23. Hardcoding values instead of making them configurable
Bedenk altijd welke veranderingen er kunnen komen en hoe je daarmee omgaat. Technische schuld zal in een monsterlijk tempo groeien als u de bewegende delen niet scheidt van de rest van uw werk. Gebruik constanten en configuratiebestanden waar nodig.
24. Het wiel steeds opnieuw uitvinden
Schrijf geen code die je niet nodig hebt. Misschien heeft iemand anders al veel tijd aan uw probleem besteed, en heeft hij of zij een goed geteste oplossing die u kunt hergebruiken. Bespaar uzelf wat moeite.
25. Blindelings code kopiëren/plakken
Begrijp code voordat je hem hergebruikt. Soms heb je op het eerste gezicht niet meteen in de gaten wat de code allemaal doet. U leert ook meer over een probleem als u de tijd neemt om de code in detail te lezen.
26. Niet de tijd nemen om te leren hoe dingen echt werken
Neem altijd de kans om uw kennis uit te breiden door na te denken over hoe dingen werken en te lezen over hun onderliggende problemen. Je bespaart misschien tijd door nu geen moeite te doen, maar wat je leert op een project zal op de lange termijn belangrijker zijn dan het daadwerkelijk gedaan te krijgen.
27. Overmatig vertrouwen hebben in je eigen code
Het is gevaarlijk om aan te nemen dat alleen omdat je iets hebt geschreven, het geweldig moet zijn. Je leert meer over programmeren als je aan nieuwe dingen werkt en ervaring opdoet, dus kijk af en toe eens naar je oude code en denk na over hoe je vooruit bent gegaan.
28. Niet nadenken over de trade-offs van elk ontwerp, oplossing, of bibliotheek
Elk product heeft zijn fijne punten die je alleen leert kennen door het te gebruiken en te analyseren. Het zien van een paar gebruiksvoorbeelden voor een bibliotheek maakt je er nog geen meester in, noch betekent het dat het de perfecte oplossing is voor elke situatie die in je project zal voorkomen. Wees voortdurend kritisch op alles wat je gebruikt.
29. Geen hulp krijgen als je vastzit
Het aanhouden van een korte feedbackloop zal altijd minder pijnlijk voor je zijn. Om hulp vragen betekent niet dat u incompetent bent. De juiste mensen zullen uw inspanning en bekentenis van onwetendheid zien als een drang om te leren, en dat is een grote deugd om te hebben.
Testen en onderhoud
30. Tests schrijven om te slagen
Het schrijven van tests waarvan je weet dat ze zullen slagen is noodzakelijk. Ze maken het refactoren en reorganiseren van een project veel veiliger. Aan de andere kant moet je ook tests schrijven waarvan je weet dat ze niet zullen slagen. Ze zijn nodig om het project vooruit te helpen en problemen in de gaten te houden.
31. Het negeren van prestatietests voor kritieke gevallen
Prepareer een geautomatiseerde prestatietestopstelling ongeveer in het midden van het ontwikkelingsproces van een project, zodat u ervoor kunt zorgen dat u geen escalerende prestatieproblemen hebt.
32. Niet controleren of je build werkt
Het komt zelden voor dat een build slaagt maar niet echt werkt, maar het kan gebeuren, en het kan lastig zijn om het probleem op te lossen hoe langer je wacht om het te onderzoeken. Het snel testen van elke build is een belangrijke gewoonte om te hebben.
33. 33. Grote wijzigingen te laat doorvoeren, of weggaan na een grote push
Dit is waar overmoed je zal krijgen, en het kan meerdere keren nodig zijn om je te branden om te leren waarom je dit niet moet doen, dus neem nu mijn advies aan en zorg ervoor dat je er altijd bent als je build uiteindelijk breekt.
34. Het verstoten van code die je hebt geschreven
Wees bereid om code die je hebt geschreven te ondersteunen. U bent de meest geschikte persoon om anderen te helpen het te begrijpen. U moet ernaar streven dat uw code over vele jaren nog leesbaar is voor uzelf en anderen.
35. De niet-functionele vereisten negeren
Wanneer u iets probeert op te leveren, kan het gemakkelijk zijn om enkele belangrijke gebieden te vergeten, zoals prestaties en beveiliging. Houd daar een checklist voor bij. Je wilt niet dat ze je feestje verpesten omdat je je deadlines hebt opgesteld zonder aan deze niet-functionele aandachtspunten te denken.
Wat zijn je slechtste programmeergewoonten?
Zoals vaak wordt gezegd, we zijn gewoontedieren. Het verbeteren van de manier waarop je werkt door middel van gewoonten is een geweldige manier om te voorkomen dat je te veel na te denken over elke afzonderlijke situatie. Als je eenmaal een goede manier om iets te doen hebt geassimileerd, wordt het moeiteloos.