Hoe schrijf ik betere productie-code?

[walkthisworld]

Mijn vraag
Mijn baan draait om het ontwikkelen van Python code in Azure. Ik heb altijd wel Python code geschreven, maar op een wat lager niveau. Ik schreef vaak wat scriptjes om wat analyses te doen op data. Nu wordt van mij verwacht dat ik code schrijf om systemen aan elkaar te koppelen. Dit is code die van hoge kwaliteit moet zijn; code die betrouwbaar moet zijn.

Ik wil graag mijn niveau wat opkrikken. Wie een goede cursus (voorkeur), boek, website.

Relevante software en hardware die ik gebruik
Python, Azure

Wat ik al gevonden of geprobeerd heb
Domain-Driven Design van Eric Evans is een boek dat ik thuis heb liggen, maar goed, als ik dat zie, dan zakt de moed me alweer in de schoenen. Weet ook niet of dit het beste boek is, en of dit boek aansluit bij het praktische probleem waar ik mee zit.

[Cyphax]

Wat voor ontwikkelmethodes worden of werden er tot nu toe gebruikt? Er zijn best wel wat methoden (DDD, TDD, etc) maar ben jij nu degene die daar een keuze moet maken?

[BCC]

Tests Ik wou je doorsturen naar Corey Haines, maar die was blijkbaar 12 jaar geleden hip Ik denk dat z'n fimpljes op youtube nog steeds een goed startpunt zijn - YouTube: Fast Rails Tests Corey Haines

Software Craftsmanship is een goede zoekterm.

Domain-Driven Design vindt ik na 20 jaar nog steeds niet direct nuttig voor software ontwikkeling, met zoveel dingen - het is goed om van het bestaan te weten, zodat je het kan toepassen als het nuttig is

[ Voor 33% gewijzigd door BCC op 01-02-2024 09:33 ]

[Kalentum]

Ik denk dat DDD zeker interessant is, maar dat jij meer behoefte hebt aan inzichten voor hogere kwaliteit van de code zelf?

Alles wat ingewikkelder is dan een scriptje, dan kom je vanzelf bij objecten uit. Een mogelijk startpunt voor je reis is zoeken naar SOLID. Dit zijn een paar designprincipes die helpen om na te denken over 'wat zet ik waar' en wat dan uiteindelijk leidt tot betere code in de zin van onderhoudbaarheid.

En code reviews, laat je code reviewen door anderen, en review code van anderen. Leer je veel van.

Ik persoonlijk heb veel baat gehad van TDD, omdat je dan eerst nadenkt hoe je code in elkaar moet steken (welke methods, argumenten, wat moet er weer uit komen) voordat je echt veel code gaat schrijven.

Oh en een linter, die, voordat je je code commit in een versiebeheersysteem, checkt of het allemaal wel ok er uitziet qua stijl, te lange methods etc

[ Voor 35% gewijzigd door Kalentum op 01-02-2024 09:35 ]

[Cartman!]

Je zou een static analysis tool als bijv Sonarqube kunnen overwegen. Dergelijke tools kunnen potentiele bugs en niet goed onderhoudbare code detecteren en geven tips om dit te verbeteren.

[Haan]

Bovenstaade tips kunnen zeker helpen, maar wat je eigenlijk nodig hebt is iemand met meer ervaring om mee samen te werken. Je kunt niet alles leren uit boeken of via videos en forums, je hebt ook feedback nodig op wat je in de praktijk aan het doen bent en daar heb je gewoon een of meer collega's voor nodig die al wel die ervaring hebben.
Ik dacht na vijf jaar bij een klein bedrijfje ook dat ik alles wist, tot ik bij een ander bedrijf deel werd van een groter team en er toen pas achter kwam hoeveel er nog was dat ik niet wist. En nu tien jaar later nog steeds Maar ik heb wel een team van developers die samen voldoende kennis hebben van alle onderwerpen waar we mee te maken hebben.

[ocf81]

Kalentum schreef op donderdag 1 februari 2024 @ 09:32:
Ik denk dat DDD zeker interessant is, maar dat jij meer behoefte hebt aan inzichten voor hogere kwaliteit van de code zelf?

Alles wat ingewikkelder is dan een scriptje, dan kom je vanzelf bij objecten uit. Een mogelijk startpunt voor je reis is zoeken naar SOLID. Dit zijn een paar designprincipes die helpen om na te denken over 'wat zet ik waar' en wat dan uiteindelijk leidt tot betere code in de zin van onderhoudbaarheid.

En code reviews, laat je code reviewen door anderen, en review code van anderen. Leer je veel van.

Ik persoonlijk heb veel baat gehad van TDD, omdat je dan eerst nadenkt hoe je code in elkaar moet steken (welke methods, argumenten, wat moet er weer uit komen) voordat je echt veel code gaat schrijven.

Oh en een linter, die, voordat je je code commit in een versiebeheersysteem, checkt of het allemaal wel ok er uitziet qua stijl, te lange methods etc

Goed advies. Maar ik zou daar aan willen toevoegen dat als je SOLID zegt, je ook wel eens mag kijken naar design patterns. Wel met de voetnoot dat deze heel nuttig kunnen zijn maar dat het overmatig toepassen ervan dan weer te veel van het goede is.

[P_Tingen]

Ik heb echt heel veel gehad aan Code Complete, van Steve mcConnell (Bol). Dit boek focust heel erg op de praktische zaken rond programmeren. Laat je niet afschrikken door het verschijningsjaar en de omvang; de eerste is lang geleden en de tweede is groot maar het boek richt zich heel erg op jou als programmeur.

Ik heb het zelf achter elkaar uitgelezen, ook al programmeer ik in een andere taal dan wat mcConnel gebruikt om zijn punten te illustreren. De code is eenvoudig genoeg om het principe erachter te begrijpen en die zullen over het algemeen ook gelden voor Python

[SiErRa]

Naast de goede bovenstaande tips is het misschien goed om naar wat grote opensource projecten die in Python zijn geschreven te kijken. Maak eens een clone van de source van bijvoorbeeld HomeAssistant en kijk eens hoe dat is opgezet, hoe ze het modulair houden, hoe ze builden. Dat is vaak heel leerzaam.

ps. Ik ben niet zo into Python, dus ik weet niet of Homeassistant een goed voorbeeld is, maar het is wel een flinke codebase waar veel mensen aan werken.

[CodeCaster]

SiErRa schreef op donderdag 1 februari 2024 @ 10:45:
Naast de goede bovenstaande tips is het misschien goed om naar wat grote opensource projecten die in Python zijn geschreven te kijken. Maak eens een clone van de source van bijvoorbeeld HomeAssistant en kijk eens hoe dat is opgezet, hoe ze het modulair houden, hoe ze builden. Dat is vaak heel leerzaam.

ps. Ik ben niet zo into Python, dus ik weet niet of Homeassistant een goed voorbeeld is, maar het is wel een flinke codebase waar veel mensen aan werken.

Hoe grote jongens het doen is zelden een goede raadgever. Een beetje data-uitwisseling (wat ik versta onder "systemen koppelen") is heel wat anders dan een platform dat op een verscheidenheid aan hardware draait, met verschillende soorten hardware en software praat, een (geneste) marketplace bevat voor het installeren van plugins (al dan niet van derden), onbegrijpelijke en/of niet geteste en/of niet gedocumenteerde legacy, ontwerpkeuzes die alleen de architect begrijpt, enzovoorts.

Kun je er dingen van leren als je weet waarnaar je moet kijken: sure. Kom je net uit de "ik kan een script schrijven"-fase, dan verdrink je gegarandeerd in de omvang.

Zoals @Haan zegt, je hebt ervaring nodig. Ofwel eigen, dan wel van anderen die met hetzelfde bijltje hebben gehakt.

[eric.1]

Theorie is er in overvloed, volgens mij is daar genoeg input geleverd. Al heb ik zelf meer gehad aan praktische input van collega's op basis van mijn voorstellen en hun ervaringen - de valkuilen ... zijn er in overvloed, die kunnen we ook met de beste theorie niet altijd in de praktijk aan zien komen zonder ervaring.

Ik denk dat vanuit praktisch oogpunt het nog wel het belangrijkste is om je code testbaar te maken/houden, begrijpelijk en ook over 5 jaar nog te snappen. Specifieke afgebakende taken per functie -> voorspelbare uitkomsten. Commentaar erbij, een dozijn test-cases erop, en je bent aardig op weg naar 'maintainable' code.

[Bezulba]

Ik ga even gemeen doen maar verwacht jouw bedrijf niet gewoon teveel van je? Of ben je niet duidelijk geweest naar de opdrachtgever dat wat zij willen niet gaat lukken?

Want zoals je zelf zegt heb je kleine dingen geprogrammeerd en nu moet jij "opeens" een veilige, snelle, 100% betrouwbare datakoppeling maken in je eentje. Lijkt mij een recept voor teleurstelling.

Ik begrijp overigens absoluut dat je het wil gaan doen en dat je mogelijkheden zoekt om jouw kennis op te krikken en dat is op zich een goed iets, maar verwachtingsmanagement is belangrijk, dat zorgt er namelijk voor dat jij aan het einde van het jaar geen slechte beoordeling krijgt omdat je 6 maanden bezig bent geweest iets te programmeren wat uiteindelijk niet lekker werkt.

[BCC]

ocf81 schreef op donderdag 1 februari 2024 @ 10:34:
[...]
Wel met de voetnoot dat deze heel nuttig kunnen zijn maar dat het overmatig toepassen ervan dan weer te veel van het goede is.

/offtopic

Design patterns maken meer kapot dan je lief is FactoryFactoryFactory

[Knutselsmurf]

P_Tingen schreef op donderdag 1 februari 2024 @ 10:43:
Ik heb echt heel veel gehad aan Code Complete, van Steve mcConnell (Bol). Dit boek focust heel erg op de praktische zaken rond programmeren. Laat je niet afschrikken door het verschijningsjaar en de omvang; de eerste is lang geleden en de tweede is groot maar het boek richt zich heel erg op jou als programmeur.

Ik heb het zelf achter elkaar uitgelezen, ook al programmeer ik in een andere taal dan wat mcConnel gebruikt om zijn punten te illustreren. De code is eenvoudig genoeg om het principe erachter te begrijpen en die zullen over het algemeen ook gelden voor Python

Hier kan ik mij bij aansluiten. Dit is een prettig leesbaar boek, wat je heel veel handvatten geeft op diverse vlakken. Niet alleen wat betreft de processen van het programmeren, maar bijvoorbeeld ook wat betreft naamgeving van variabelen en functies, of het gebruik van comments in je code. Er wordt niet gezegd "zo moet je het doen", maar je wordt gestuurd om over dit soort zaken na te denken.

Los hiervan is het schrijven van goede, robuuste, leesbare code een kwestie van ervaring. Dat leer je niet alleen uit een boek, maar vooral door te doen. Feedback van een collega is cruciaal, evenals openstaan voor (kritische) feedback. Zeker als je met meerdere mensen aan dezelfde codebase werkt is dat cruciaal. Het zorgt er namelijk ook voor dat de codebase uniform wordt qua naamgeving, wijze van probleem oplossen, etc. dit zorgt er vervolgens voor dat iedereen in staat is om een specifiek stuk code aan te passen, en niet alleen de persoon die het oorspronkelijk geschreven heeft.

Wat mij verder geholpen heeft bij het schrijven van robuuste code, is een pessimistische denkwijze Vraag je altijd af "wat kan er mis gaan", en houd daar vervolgens rekening mee in je code.

De door andere genoemde punten als bijvoorbeeld DDD, unittesting en design patterns zijn goede gereedschappen om te beheersen en in je toolbox te hebben. Maar het blijven gereedschappen en het is aan de vakman om deze te beheersen en te weten wanneer welke gereedschap het beste gebruikt kan worden. En dat kan alleen met ervaring, die je opdoet door fouten te maken en te leren van die fouten.

[GarBaGe]

Unit testen, inderdaad super belangrijk.

Afhankelijk van de complexiteit van je scripts, kan dependency management ook erg belangrijk worden.
Welke libs gebruik je van andere?
Welke versies daarvan?
Hoe oud zijn deze?
Er zijn er mogelijk (security) issues gevonden, die mogelijk gefixed zijn...

[Cloud]

BCC schreef op donderdag 1 februari 2024 @ 11:00:
[...]

/offtopic

Design patterns maken meer kapot dan je lief is FactoryFactoryFactory

Als je ze blind (en onterecht/onjuist) toepast inderdaad wel ja; maar om nu alle patterns over één kam te scheren, lijkt me wat gortig.

Ik snap overigens wel dat het soms misgaat, omdat vroeger wel eens gesteld werd dat je alles per definitie met een design pattern moest oplossen. Dan kun je inderdaad zulke overdreven enterprisey complexiteit krijgen. De meeste design patterns moet je er eigenlijk pas bij pakken als je een probleem in je design hebt, niet direct designen met patterns in gedachten.

Wel denk ik niet dat de TS nu toe is aan boeken over design patterns, ik denk dat meer naar de basis van goede code moet voordat je die gereedschappen erbij pakt

---

Ik kan ook "Code Complete" als goed boek onderschrijven Verder zou je ook boeken over SOLID en Clean Code kunnen lezen maar voor met name die 1e geldt dat het beter "klikt" als je tegen de problemen aangelopen bent die je daarmee kunt oplossen.

[BCC]

Cloud schreef op donderdag 1 februari 2024 @ 11:16:
[...]

De meeste design patterns moet je er eigenlijk pas bij pakken als je een probleem in je design hebt, niet direct designen met patterns in gedachten.

Ja, vaak worden ze toegepast bij veel te eenvoudig problemen - dat is ook het lastige eraan, je kan wel een simpel voorbeeld geven waar je een design pattern uitlegt, maar ze zijn pas echt nuttig bij complexe scenarios. Je leert dit ook door ervaring ben ik bang .

Code complete is een prima boek, maar geeft imho ten onrechte af op Functionele talen, terwijl die met Clojure en Elixir juist enorm in de lift zitten. Net als design patterns: alleen toepassen waar toepasselijk

https://cleancoders.com/ heeft ook nog wel een paar prima gratis videos om te kijken.

[ Voor 5% gewijzigd door BCC op 01-02-2024 11:38 ]

[P_Tingen]

Een ding om ook in gedachten te houden is dat je code aan drie dingen moet voldoen:

1. Simpel
2. Simpel
3. Simpel

Code wordt maar 1x geschreven en daarna 1000 keer gelezen en aangepast. Focus je dus niet op dat allereerste proces van schrijven. Maak code dus ook niet "slim".

Zoals Edsger Dijkstra al zei in 1972:
"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague"

Ik kom vaak genoeg code van mezelf tegen die al wat ouder is en ook daar moet ik vaak nog veel te veel terug zoeken om goed te achterhalen wat de code ook alweer doet. Dus houd procedures en functies redelijk overzichtelijk; laat het maar 1 ding doen en niet meer. Gebruik guard clauses om grote blokken te vermijden, trek complexe calculaties eerst in een variabele en gebruik dan die variabele ipv de complexe calculatie etc etc etc

Voor het werken met ouwe meuk bestaande code, heb ik ook nog wel wat gehad aan de tips van https://understandlegacycode.com/ Die vaak nog wel concrete tips geeft. Het probleem met heel veel van de sites en boeken is dat het allemaal richt op een hoger abstractieniveau en waar je nu behoefte aan hebt is concrete feedback/sturing denk ik.

[remyz]

Je zou ook eens op realpython.com kunnen kijken. Die hebben naar mijn mening best interessante artikelen en cursussen, van beginners niveau tot wat meer gevorderd. Een prima manier om te kijken waar je zo’n beetje staat. Volledige toegang gaat je wel geld kosten, maar dat is misschien als studiekosten op te voeren bij je werkgever.

[walkthisworld]

Bedankt voor de reacties.

Op basis van de wat er hier geschreven wordt, zie ik een aantal opties:

• opzoeken en naleven van principes
• begeleiding voor ervaren coder
• bestaande code bekijken

Er worden een aantal boeken genoemd, waaronder deze:

• Code Complete, Steve McConnell

En dan zijn er nog de meer praktische tips. Tips die meer vertellen hoe ik het werk moet doen (zeker nuttig), maar iets minder helpen bij het maken van een plannetje voor de toekomst:

• TDD wordt ook genoemd. Hier gaat het bedrijf waar ik voor werk langzaam naar toe. We hebben een aantal ervaren krachten ingehuurd die ons hierbij helpen. Ze helpen ook bij het vastleggen van infra in code, en bij het automatiseren van deployments.
• Linters zijn we inderdaad ook mee bezig.
• Andere tools worden hierboven ook genoemd.

Dan nog kort iets over de relatie tussen mij en mijn werkgever:

• Ik ben in vaste dienst en heb bij mijn sollicitatie heel duidelijk gemaakt wat ik wel en niet kon. Ik heb een assessment moeten doen, daar ben ik voor geslaagd. Ik heb veel domein-kennis. Dat is ook een reden dat ik werk waar ik werk.
• Er worden mij absoluut geen verwijten gemaakt.
• We zijn samen aan het kijken wat het beste voor mij is en hoe ik snel (nog meer) waarde kan leveren.

Dan nog een paar concrete vragen:

• Kunnen jullie een cursus aanraden?
• Boeken zijn al genoemd, die ga ik zeker bekijken
• Eigenlijk moet je iets van een checklist hebben, maar zo eenvoudig zal het niet zijn. Er zijn natuurlijk wel linters en formatter, maar die helpen denk ik minder bij de grote lijnen.

[walkthisworld]

Nog een kleine update, en nog een vraag (naast de vragen die nog open staan).

Ik heb ook het volgende boek gevonden: Fluent Python van O'Reilly Media. Dit lijkt me een boek dat wat dieper ingaat op Python. Het lijkt mij ook een goed hulpmiddel om de volgende stap te kunnen zetten.

Ik heb met mijn manager besproken dat het ontwikkelen van Python/programming skills een persoonlijk doel wordt. Dat dit dus onderdeel wordt van mijn ontwikkelingsplan. Nu is de vraag hoe ik dit S.M.A.R.T. zou kunnen maken. Het lezen van een boek of het bestuderen van code is moeilijk S.M.A.R.T. te maken. Het volgen van een cursus of het doen van een examen is dat wel.

Suggesties?

[OverloadOfRed]

walkthisworld schreef op vrijdag 16 februari 2024 @ 07:23:
Nu is de vraag hoe ik dit S.M.A.R.T. zou kunnen maken. Het lezen van een boek of het bestuderen van code is moeilijk S.M.A.R.T. te maken. Het volgen van een cursus of het doen van een examen is dat wel.

Suggesties?

Klinkt voor de hand liggend, maar stel een doel wat je wil halen.
Wat wil je doen? Python schrijven, of wil je een business doel halen mét je code? Python schrijven is geen doel op zich, maar een business doel voldoen is iets wat je SMART kan maken en wat je uit kan leggen aan een manager.

[Kalentum]

walkthisworld schreef op vrijdag 16 februari 2024 @ 07:23:
Nog een kleine update, en nog een vraag (naast de vragen die nog open staan).

Ik heb ook het volgende boek gevonden: Fluent Python van O'Reilly Media. Dit lijkt me een boek dat wat dieper ingaat op Python. Het lijkt mij ook een goed hulpmiddel om de volgende stap te kunnen zetten.

Ik heb met mijn manager besproken dat het ontwikkelen van Python/programming skills een persoonlijk doel wordt. Dat dit dus onderdeel wordt van mijn ontwikkelingsplan. Nu is de vraag hoe ik dit S.M.A.R.T. zou kunnen maken. Het lezen van een boek of het bestuderen van code is moeilijk S.M.A.R.T. te maken. Het volgen van een cursus of het doen van een examen is dat wel.

Suggesties?

Certificering halen. BV https://pythoninstitute.org/pcep

[MarcoC]

Haan schreef op donderdag 1 februari 2024 @ 10:27:
Bovenstaade tips kunnen zeker helpen, maar wat je eigenlijk nodig hebt is iemand met meer ervaring om mee samen te werken. Je kunt niet alles leren uit boeken of via videos en forums, je hebt ook feedback nodig op wat je in de praktijk aan het doen bent en daar heb je gewoon een of meer collega's voor nodig die al wel die ervaring hebben.
Ik dacht na vijf jaar bij een klein bedrijfje ook dat ik alles wist, tot ik bij een ander bedrijf deel werd van een groter team en er toen pas achter kwam hoeveel er nog was dat ik niet wist. En nu tien jaar later nog steeds Maar ik heb wel een team van developers die samen voldoende kennis hebben van alle onderwerpen waar we mee te maken hebben.

Helemaal mee eens. Ik denk dat je max. 20% uit boeken kunt halen, de rest moet je d.m.v. praktijkervaring opdoen.

[Guus...]

Qua tools zou ik pre-commit aanraden om te installeren voor je repositories. Daar kan je een reeks linters, formatters en typecheckers op instellen.

Black en flake8 voor het formaten, isort om dependencies op de juiste volgorde te zetten, ruff als linter en eventueel mypy om static typing toe te passen.

Dit neemt je een hoop werk uit handen om het eens te worden over hoe code eruit moet zien en kan sommige onhandige fouten of keuzes alvast aan je laten weten. In het begin zal je meer dingen moeten aanpassen dan als je eenmaal gewend bent aan de structuur.

[Lethalis]

Mensen worden vast boos op mij: Geen Python meer gebruiken, maar een statically typed taal zoals C#.

Python is leuk voor scripts en daar gebruik ik het zelf ook voor. Even snel iets in elkaar flansen en Python is your friend. Maar zodra je iets groters gaat programmeren wat kritiek is, dan heb je zoveel meer plezier van een taal als C# (of Java / Kotlin).

De compiler ondervangt een hoop domme foutjes dan al meteen voor jou.

Los van de taal zijn design patterns belangrijk om te leren, maar gebruik ze wijselijk. Ik heb een periode gehad dat ik er helemaal los mee ging en als ik mijn code dan nu tegenkom, word ik meestal ongelukkig van het aantal stappen dat ik moet doorlopen voordat ik eindelijk bij een stuk code kom dat iets doet wat ik zoek.

Soms is simpelweg rechttoe rechtaan programmeren helemaal prima (transaction script). Moet je dan 3 jaar later een keer iets er aan veranderen, dan zie je tenminste in 1 oogopslag wat de code doet.

KISS en YAGNI.

Maar goed, leer de patterns wel... want ze kunnen erg handig zijn áls je ze nodig hebt.

PS
Gebruik een logging oplossing. Wij gebruiken Graylog op mijn werk en onze API's loggen naar Graylog. Je kunt eventuele issues op deze manier snel opsporen. In Graylog kun je hele dashboards maken met de informatie die relevant voor jou is.

In de praktijk heeft ons dat meer opgeleverd dan design patterns

[ Voor 12% gewijzigd door Lethalis op 16-02-2024 22:28 ]

[Lethalis]

walkthisworld schreef op maandag 5 februari 2024 @ 11:18:
Ik heb veel domein-kennis. Dat is ook een reden dat ik werk waar ik werk.

Als je die domein kennis kunt combineren met programmeren is dat goud waard Je kunt dan waarschijnlijk behoorlijk zelfstandig werken en heel goed de requirements interpreteren.