Make IT Work Extra informatie en bronnen

by alexanderSoftware Engineering Basis

In de terugkomdag van Make IT Work heb ik een workshop gegeven rondom OO principes. Hier zijn een aantal onderwerpen in teruggekomen. In dit artikel kom ik terug op de paradigma’s en zijn ook extra bronnen te vinden over de onderwerpen waar we over gesproken hebben.

Table of Contents

Software Paradigma’s

In software engineering zijn er meerdere paradigma’s, die allemaal een deel van de mogelijkheden die een software engineer heeft wegneemt. In het boek Clean Architecture worden er drie besproken.

Structured Programming

Structured programming imposes discipline of transfer of control

Simpel gezegd betekent dit dat je binnen een stuk code ZELF de controle wilt hebben. Een voorbeeld hiervan is dat variabelen altijd alleen maar bestaan binnen de scope van de methode waarin je zit en daarbuiten nooit beschikbaar zullen zijn. Edsger W Dijkstra (lange tijd professor geweest aan de TU/e) heeft dit geduid in het artikel Go To Statement Considered Harmful.

In de basis is structured programming dus het uitvoeren van een gedefinieerde set van stappen. Hierbij is het gedrag van het systeem een vaste volgorde van stappen die er voor zorgen dat de gewenste taak uitgevoerd wordt.

Software gebouwd binnen dit paradigma is vaak eenvoudig te doorgronden, omdat er een duidelijk stappenplan wat de software volgt te ontdekken is.

Object-Oriented Programming

Object-oriented programming imposes discipline on indirect transfer of control

Hier gaat het om de controle juist wel delen en uit handen geven. Variabelen bestaan juist WEL buiten de scope van de methode en kunnen daarbuiten ook aangepast worden. Een voorbeeld hiervan is als je een object meegeeft als parameter aan een functie, kan binnen die functie dit object gebruikt en aangepast worden, waarmee ook het oorspronkelijke object gewijzigd is.

Je laat de controle over hoe het gedrag van het systeem is dus expliciet los, waarmee het een soort natuurlijke tegenpool is van structured programming. Je roept dus in je eigen methode, andere methoden aan die stappen uitvoeren die jij niet kent, en ook niet weet welke volgorde van stappen toegepast zal worden.

Software die gebouwd wordt met dit paradigma is vaak goed te doorgronden, omdat het een abstracte weergave is van de werkelijkheid.

Functional Programming

Functional programming imposes discipline upon assignment

Waar bij structured programming en object-oriented programming alles draait om de assignments (alles leidt uiteindelijk tot het aanpassen van een variabele, of het veranderen van de toestand van de applicatie), laat je dit bij functioneel pogrammeren los. Alles in functioneel programmeren beschrijf je in (wiskundige) functies en de assignment bestaat in principe niet.

Functioneel programmeren vindt zijn oorsprong in de lamda-calculus in de wiskunde en is daardoor vaak wat lastiger te doorgronden dan de andere twee paradigma’s. In plaats van een stappenplan of een abstracte weergave van de werkelijkheid, gaat het over het uitvoeren van een functie, op data met een verwachte uitkomst.

Boeken over OO-principes en Software engineering

Er zijn een flink aantal boeken over (objectgeorienteerd programmeren) en het zijn van software engineer. Ik zou tegenwoordig niet meer aanraden om boeken aan te schaffen rondom een specifieke (versie van een) taal, maar je te richten op de concepten achter programmeren. Die blijven veel constanter en vormen de basis van het zijn van software engineer.

Een aantal boeken op dit vlak zouden (naar mijn mening) door elke software engineer gelezen moeten worden:

Clean Code (Robert C. Martin)

Wat mij betreft HET boek over het schrijven van goede code. De focus ligt hierin niet op het bovenliggende ontwerp, maar echt op de code zelf. In het eerste deel van het boek worden veel bad programming practices besproken en hoe je dit kunt verbeteren. In het tweede deel (Smells and Heuristics) worden vervolgens een flink aantal code smells (bad practices) benoemd als een soort van referentielijst.

Veel tools die geintegreerd zitten in IDE’s of de IDE kunnen helpen om code clean te maken en houden. Denk hierbij aan IntelliJ voor Java, Resharper als plugin voor Visual Studio, maar ook losse tools als SonarQube, Tics.

Clean Architecture (Robert C. Martin)

In dit boek wordt de basis gelegd voor hoe je op een goede manier een software project ontwerpt. Het gaat daarbij door de basis van software engineering heen. Hierbij komen aan bod:

Programmeer paradigma’s. Een beschrijving van de drie belangrijkste programmeer paradigma’s en waarom deze belangrijk zijn

SOLID principes. Uitleg van de basis-principes om goede software te ontwerpen. Voor elk onderdeel is een hoofdstuk met een duidelijke beschrijving.

Component principes en architectuur. Waar SOLID vooral over classes en methods gaat, kijken de component principes over deze grenzen heen: hoe laat je componenten op een goede manier samenwerken in een architectuur

Wanneer deze basis er is, worden design patterns ineens veel eenvoudiger te herkennen en toe te passen.

Refactoring (Martin Fowler)

Wat mij betreft DE bijbel als het gaat om bestaande code beter te maken. Het boek is opgezet als referentie voor code smells en biedt een gestructureerd stappenplan om het probleem te identificeren en op te lossen.

Het boek is een praktische aanvulling op de eerste twee boeken. Waar de boeken van Robert C. Martin vooral gaan over de concepten, gaat refactoring over hoe je dat vervolgens aanpakt. Het boek is opgedeeld in verschillende probleemgebieden (bijvoorbeeld Composing Methods) en biedt dan oplossingen om problemen hierin op te lossen (zoals Extract Method, Inline Method). Dit alles wordt voorzien van voorbeelden en uitleg.

Op de website van SourceMaking wordt deze methodiek ook toegepast.

The Pragmatic Programmer (Andrew Hunt, David Thomas)

In dit boek gaat het niet over programmeren of over programmeerconcepten, maar over jou als software engineer, soms ook wel gekoppeld aan het programmeren en de concepten. Er wordt duidelijk uitgelegd welke gedragingen er bij een software engineer horen als je langere tijd een goede software engineer wilt zijn.

Ondanks dat het boek inmiddels meer dan 20 jaar oud is, is het wat mij betreft nog steeds één van de beste, zo niet het beste boek over het zijn van software engineer.

Overige boeken die interessaant kunnen zijn, afhankelijk van je interessegebied:

  • Working Effectively with Legacy Code (Michael C. Feathers) – Hoe kun je bestaande code beter maken, zonder dat er problemen ontstaan
  • The Pragmatic Programmer (Andrew Hunt, David Thomas) – Allerhande tips en tricks over het zijn van een goede software engineer. Niet als programmeur, maar als persoon.
  • The Clean Coder (Robert C. Martin) – Waar Clean Code gaat over waar goede code aan moet voldoen, gaat dit boek in waar een goede programmeur aan moet voldoen.
  • Head First Object-Oriented Analysis & Design – Een zeer toegankelijk boek over analyse en design, waarin vanuit de basis toegewerkt wordt naar de OO principes.
  • Design Patterns (Erich Gamme, Richard Helm, Ralph Johnson, John Vlissides) – DE bijbel op het gebied van Design Patterns. Bevat de belangrijkste patterns en volgt een vergelijkbare strategie als Refactoring.
  • Head First Design Patterns – Bevat de belangrijkste design patterns uit het andere design patterns boek, maar wordt veel toegankelijker gebracht, met ook koppelingen naar OO principes.

Bonus: Enkele artikelen over de geschiedenis van software engineering

Alle programmeertalen en paradigma’s vinden uiteindelijk hun oorsprong is de wiskunde, de reden dat software engineering in veel opleidingen in het technische of zelfs wiskundige domein geplaatst is. Dat is ook de reden dat “programmeren” al veel langer bestaat dan computers. Daarom als bonus een aantal links naar artikelen over de geschiedenis van software engineering en computers.