10 Basisprincipes voor programmeren Elke programmeur moet volgen

Iedereen kan code schrijven. Maar goede code? Dat is waar het moeilijk wordt.

We hebben allemaal horrorverhalen gehoord over spaghetti-code, massale if-else-ketens, hele programma's die kunnen breken door simpelweg een variabele te veranderen, functies die eruitzien alsof ze versperd zijn, enzovoort. Dat is wat er gebeurt wanneer u een verzendbaar product probeert te maken met slechts een semester aan programmeerervaring onder uw riem.

Neem geen genoegen met het schrijven van code dat werken. Streef ernaar om code te schrijven die dat wel kan wordt onderhouden - niet alleen door uzelf, maar door iemand anders die op enig moment in de toekomst aan de software kan werken. Daartoe zijn er verschillende principes om je act op te ruimen.

1. KISS

De “hou het simpel, stom” beginsel is van toepassing op vrijwel al het leven, maar het is vooral nodig in middelgrote tot grote programmeerprojecten.

Het begint helemaal in het begin wanneer je de reikwijdte definieert van wat je wilt creëren. Alleen omdat je een passie hebt voor het ontwikkelen van games, wil dat nog niet zeggen dat je het volgende kunt maken World of Warcraft of Grand Theft Auto. Als je denkt dat je genoeg hebt vereenvoudigd, vereenvoudig het nog een niveau verder - feature creep is onvermijdelijk, dus begin klein.

Maar zelfs nadat het coderen is begonnen, houd het eenvoudig. Complexe code duurt langer om te ontwerpen en te schrijven, is meer vatbaar voor fouten en fouten en is later moeilijker aan te passen. In de wijze woorden van Antoine de Saint-Exupery, “Perfectie wordt bereikt, niet wanneer er niets meer aan toe te voegen is, maar wanneer er niets meer over is om mee te nemen.”

2. DROOG

De “herhaal jezelf niet” beginsel is cruciaal voor schone en eenvoudig te wijzigen code. Bij het schrijven van code wilt u dubbele gegevens en dubbele logica vermijden. Als je merkt dat hetzelfde stuk code telkens opnieuw wordt geschreven, verbreek je dit principe.

Het tegenovergestelde van DRY-code is WET-code: “schrijf alles tweemaal” (of “verspillen ieders tijd”). Een van de beste manieren om WET-code te diagnosticeren, is jezelf afvragen: om het gedrag van het programma op de een of andere manier te wijzigen, hoeveel codevelden zou je moeten aanpassen?

Stel dat je een podcast-directory-app schrijft. Op de zoekpagina heb je een code voor het ophalen van de details van een podcast. Op de podcastpagina heb je een code om de details van die podcast op te halen. Op de favorietenpagina dezelfde ophaalcode. Overweeg dit allemaal in een functie samen te vatten, zodat je alles op één plek kunt doen als je het later nog moet bewerken.

3. Open / Gesloten

Of u nu objecten schrijft Wat is objectgeoriënteerd programmeren? The Basics Explained in Layman's Terms Wat is Object Oriented Programming? The Basics Explained in Layman's Terms De meeste moderne programmeertalen ondersteunen het "object-oriented programming" (OOP) paradigma. Maar wat is OOP precies en waarom is het zo nuttig? Lees meer in Java of modules in Python, je moet proberen je code te maken open voor uitbreiding maar gesloten voor wijziging. Dit is van toepassing op allerlei soorten projecten, maar is vooral belangrijk bij het vrijgeven van een bibliotheek of een raamwerk dat voor anderen bedoeld is om te gebruiken.

Stel dat u een GUI-framework onderhoudt. Je zou het in de huidige staat kunnen vrijgeven, en verwachten dat eindgebruikers je vrijgegeven code direct zullen aanpassen en integreren. Maar wat gebeurt er als u vier maanden later een belangrijke update uitbrengt? Hoe implementeren ze al je toevoegingen zonder al het werk dat ze hebben gedaan weg te gooien?

In plaats daarvan, geef de code vrij voorkomt directe wijziging en moedigt uitbreiding. Dit scheidt kerngedrag van gewijzigd gedrag. De voordelen? Grotere stabiliteit (gebruikers kunnen niet per ongeluk kerngedrag breken) en een grotere onderhoudbaarheid (gebruikers maken zich alleen zorgen over uitgebreide code). Het open / gesloten-principe is de sleutel tot het maken van een goede API Wat zijn API's en hoe zijn open API's die het internet veranderen Wat zijn API's en hoe veranderen open API's het internet Heb je je ooit afgevraagd hoe programma's op je computer en de websites die je bezoekt "met elkaar praten? Lees verder .

4. Samenstelling> Nalatenschap

De “samenstelling over overerving” beginsel stelt dat objecten met complex gedrag dit zouden moeten doen door instanties van objecten met individueel gedrag te bevatten in plaats van een klasse te erven en nieuw gedrag toe te voegen.

Overbetrokkenheid bij overerving kan tot twee grote problemen leiden. Ten eerste kan de overervingshiërarchie in een oogwenk rommelig worden. Ten tweede hebt u minder flexibiliteit bij het definiëren van gedrag in speciale gevallen, met name wanneer u gedrag wilt implementeren vanuit een overervingsvertakking in een andere overervingsactiviteit:

Compositie is een stuk schoner om te schrijven, gemakkelijker te onderhouden en zorgt voor bijna oneindige flexibiliteit voor zover je weet wat voor soort gedrag je kunt definiëren. Elk individueel gedrag is zijn eigen klasse en je creëert complex gedrag door individueel gedrag te combineren.

5. Enkele verantwoordelijkheid

De principe van enkele verantwoordelijkheid zegt dat elke klasse of module in een programma zich alleen moet bezighouden met het bieden van een beetje specifieke functionaliteit. Zoals Robert C. Martin zegt, “Een klasse zou maar één reden moeten hebben om te veranderen.”

Klassen en modules beginnen vaak op deze manier, maar als je functies en nieuw gedrag toevoegt, is het gemakkelijk voor hen om te evolueren naar God-klassen en God-modules die honderden of zelfs duizenden regels met code bevatten. Op dit punt moet je ze opdelen in kleinere klassen en modules.

6. Scheiding van zorgen

De principe van scheiding van bezorgdheden is als het principe van één verantwoordelijkheid maar op een meer abstract niveau. In essentie moet een programma zo worden ontworpen dat het veel verschillende niet-overlappende encapsulaties heeft, en deze inkapseling moeten elkaar niet kennen.

Een bekend voorbeeld hiervan is het model-view-controller (MVC) paradigma, dat een programma scheidt in drie verschillende gebieden: de gegevens (“model-”), de logica (“controleur”) en wat de eindgebruiker ziet (“uitzicht”). Variaties van MVC komen vaak voor in de populairste web frameworks van vandaag.

De code die het laden en opslaan van gegevens in een database afhandelt, hoeft bijvoorbeeld niet te weten hoe deze gegevens op het web moeten worden weergegeven. De weergavecode kan invoer van de eindgebruiker in beslag nemen, maar geeft vervolgens die invoer door aan de logische code voor verwerking. Elk deel behandelt zichzelf.

Dit resulteert in modulaire code, waardoor het onderhoud veel eenvoudiger wordt. En in de toekomst, als u ooit al de weergavecode moet herschrijven, kunt u dit doen zonder u zorgen te maken over hoe de gegevens worden opgeslagen of de logica wordt verwerkt.

7. YAGNI

De “je hebt het niet nodig” beginsel is het idee dat je nooit moet coderen voor functionaliteit die jij bent mei behoefte in de toekomst. De kans is groot, jij zal niet nodig hebben en het zal een verspilling van tijd zijn - en niet alleen dat, maar het zal de complexiteit van je code nodeloos verhogen.

Je zou dit kunnen zien als een specifieke toepassing van het KISS-principe en een reactie op degenen die het DRY-principe te serieus nemen. Vaak proberen onervaren programmeurs de meest abstracte en generieke code te schrijven die mogelijk is om WET-code te vermijden, maar te veel abstractie eindigt in opgeblazen code die onmogelijk te onderhouden is.

De truc is om het DRY-principe alleen toe te passen wanneer dat nodig is. Als je merkt dat stukjes code telkens opnieuw worden geschreven, ontsier ze dan - maar nooit wanneer je denken een stuk code zal steeds opnieuw worden geschreven. Meer keren dan niet, zal het niet zijn.

8. Voortijdige optimalisatie vermijden

De geen voorbarig optimalisatieprincipe is vergelijkbaar met het YAGNI-principe. Het verschil is dat YAGNI de neiging tot aanpakken aanpakt gedrag implementeren voordat ze nodig zijn, terwijl dit principe de neiging om aan te pakken versnellen algoritmen voordat het nodig is.

Het probleem met voortijdige optimalisatie is dat je nooit echt weet waar de knelpunten van een programma liggen tot na het feit. Je kunt het natuurlijk raden en soms heb je zelfs gelijk. Maar vaker wel dan niet, verspil je kostbare tijd om een ​​functie te versnellen die niet zo traag is als je denkt of die niet zo vaak wordt gebeld als je zou verwachten.

Bereik uw mijlpalen zo eenvoudig mogelijk profiel uw code om echte knelpunten te identificeren.

9. Refactor, Refactor, Refactor

Een van de moeilijkste waarheden om te accepteren als een onervaren programmeur is dat code komt zelden de eerste keer uit. Het kan voelen precies wanneer je die glimmende nieuwe functie implementeert, maar naarmate je programma complexer wordt, kunnen toekomstige functies worden gehinderd door hoe je die vroege hebt geschreven.

Codebases evolueren voortdurend. Het is volkomen normaal om hele brokken code opnieuw te bezoeken, te herschrijven of zelfs opnieuw te ontwerpen - en niet alleen normaal, maar ook gezond om dit te doen. U weet meer over de behoeften van uw project nu dan wanneer je het deed bij de begin, en je moet deze nieuw verworven kennis regelmatig gebruiken om oude code te refactoren.

Merk op dat dit niet altijd een groot proces hoeft te zijn. Neem een ​​pagina van de padvinders van Amerika, die leven volgens deze woorden: “Verlaat de camping schoner dan dat je hem gevonden hebt.” Als u ooit oude code moet controleren of wijzigen, moet u deze altijd opschonen en in een betere staat achterlaten.

10. Reinig code> Slimme code

Over schone code gesproken, laat je ego bij de deur en vergeet het schrijven van slimme code. Je weet waar ik het over heb: het soort code dat meer op een raadsel lijkt dan een oplossing en alleen bestaat om te laten zien hoe slim je bent. De waarheid is dat niemand echt iets kan schelen.

Een voorbeeld van slimme code is het inpakken van zoveel mogelijk logica in één regel. Een ander voorbeeld is het exploiteren van de fijne kneepjes van een taal om vreemde maar functionele uitspraken te doen. Alles dat iemand kan laten zeggen “Wacht wat?” bij het overlopen van uw code.

Goede programmeurs en leesbare code gaan hand in hand. Laat indien nodig opmerkingen achter. Houd u aan stijlgidsen, gedicteerd door een taal (zoals Python) of een bedrijf (zoals Google). Observeer de idiomatische uitdrukkingen per taal en stop met het schrijven van Java-code in Python of omgekeerd. Zie ons artikel over tips voor het opschonen van code 10 Tips voor het schrijven van schonere en betere code 10 Tips voor het schrijven van schonere en betere code Het schrijven van schone code lijkt eenvoudiger dan het in werkelijkheid is, maar de voordelen zijn het waard. Hier leest u hoe u vandaag schonere code kunt gaan schrijven. Lees verder .

Wat maakt een goede programmeur?

Vraag vijf mensen en je krijgt 10 verschillende antwoorden. Voor mij is een goede programmeur iemand die begrijpt dat codering uiteindelijk de eindgebruiker dient, die gemakkelijk in een team kan werken en die zijn projecten afrondt naar specificatie en op tijd.

Als je net begint, maak je daar niet al te veel zorgen over. Focus op het leren coderen zonder stress. Als je vastzit, lees dan ons artikel over het overwinnen van het programmeerblok. En als je gewoon niet blij bent met het schrijven van code, lees dan ons artikel over tekenen dat je geen programmeur hoeft te zijn. 6 Tekenen dat je niet programmeur wilt zijn 6 Tekenen dat je niet programmeur hoeft te zijn Niet iedereen is uitgesneden om een ​​programmeur te zijn. Als je niet helemaal zeker bent dat je een programmeur moet zijn, zijn hier enkele aanwijzingen die je in de juiste richting kunnen wijzen. Lees verder .

Hoe zou je een goede programmeur definiëren? Hebt u tips voor onervaren programmeurs die willen verbeteren? Deel het met ons in de reacties hieronder!

Ontdek meer over: Programmeren.