De leercurve van Angulartests beklimmen - deel 2
In een vorige blog beschreef ik de keuze van mijn team om de front end van onze Angular-applicatie te testen via end to end-tests - en waarom we daar uiteindelijk op terugkwamen. Nu we besloten hadden inderdaad te willen (nee, moeten) unit testen, doemde er een nieuwe keuze op in de beslisboom: gaan we ons in het zweet werken om Angulars steile leercurve te beklimmen, of bekijken we of er een manier is waarop we het testen voor ons kunnen vergemakkelijken?
Hoe droog wil je je test hebben?
Ik heb in het verleden over droger tests geschreven, want ik ben een softwareontwikkelaar en wij herhalen onszelf niet graag. En precies daarom ga ik het nóg een keer over droger tests hebben - of liever: minder droge tests. Want, anders dan je als naïeve ontwikkelaar zou verwachten, gelden er voor productiecode en testcode andere regels wat betreft de mate waarin herhaling tolerabel of zelfs wenselijk is.
De leercurve van Angulartests beklimmen - deel 1
Niet lang nadat we Angular als front end-framework besloten te gebruiken, maakten we de keuze de unit tests te laten voor wat het was. We waren heus wel overtuigd van het belang ervan, dat was het probleem niet, maar de stijle leercurve van Angulars tests verleidde ons daar niet naar te handelen. Toch lieten we het testen van de front end niet helemaal schieten. Onze tester had zich verdiept in end to end testframework Selenium, en het team wilde graag geloven dat dit een acceptabel alternatief was voor het schrijven van front end tests. Maar uiteindelijk dwong de werkelijkheid ons toch die beslissing te herzien.
Hoe lang hoort een Sprint Review te duren?
Soms sluit ik wel eens aan bij de Sprint Reviews van collega-teams. Wat me daarbij opvalt, is dat er een behoorlijke diversiteit in tijdsduur is tussen de Reviews van de verschillende teams. De onze zijn getimeboxt op een uur en ‘n kwartier, al duren ze in de praktijk meestal ongeveer een uur. Maar ik woon ook Reviews bij van een halfuurtje. Wat is er aan de hand?
Waarom ik twee keer per week blog
Een collega vroeg me eens: “Twee keer per week bloggen, is dat niet heel erg veel?” Mijn antwoord was: “Het is uitdagend.” Nu ik erop reflecteer, besef ik dat je zijn vraag op twee manieren op kan vatten. De eerste, en volgens mij meest voor de hand liggende: zitten er wel genoeg uren in de week om goed en wel twee blogs te kunnen schrijven? Maar de tweede is even gegrond: heb je wel genoeg materiaal om twee keer per week over te schrijven?
Hoe leer je eigenlijk programmeren?
Hoe leert iemand programmeren? Felienne Harmans stelt deze vraag naar aanleiding van een persoonlijke anekdote over de tijd dat ze jonge kinderen lesgaf over het onderwerp. Ze geeft ruiterlijk toe, als onbewust onbekwame leraar, in eerste instantie terug te vallen op de manier waarop ze zelf leerde programmeren: door het te doen. Maar is ontdekkend leren de beste manier om te leren programmeren? Te oordelen naar het succes van haar leerlingen, concludeert Hermans: nee, bepaald niet.
Code reviews als leermiddel
Toen ik begon als softwareontwikkelaar, was ik eerlijk gezegd een beetje bang voor code reviews. Inmiddels zijn de rollen omgedraaid, en zijn mijn collega’s banger voor mijn code reviews dan ik voor die van hen. Feit is dat ik een stuk scheutiger ben met mijn opmerkingen dan mijn collega’s. Toch denk ik dat er in mijn commentaar maar weinig is om bang voor te zijn. Ik zie code reviews namelijk niet als middel en moment om kritiek te geven op andermans code. Of liever: niet alleen als middel en moment om kritiek te geven.
Vakantie vs. enigszins vakantie
Er zijn twee soorten activiteiten in het leven: activiteiten die je energie kosten en activiteiten die je energie opleveren. De truc is een balans te vinden. Om manieren te zoeken om de balans tussen de eerste en de tweede soort activiteit in het voordeel - hoe licht ook - van de eerste te beslechten. Deze vakantie heb ik enigszins bewust het besluit genomen me zo min mogelijk met softwareontwikkeling bezig te houden. Ik was van mening dat het tijd was om de energiebalans met andere activiteiten aan te vullen.
Over het hek van Chesterton
Ik ben niet vies van het refactoren van code die ik onduidelijk vind, of zelfs van weggooien van (meestal dode) code. Dat is een goede eigenschap wanneer je het met beleid doet en een slechte als het uit louter enthousiasme voorkomt. De eerste resulteert in helderder en eenvoudiger code, de tweede in buggy software. Waar zit hem precies het onderscheid in? Het antwoord vond ik in Software Engineering at Google in het hoofdstuk over kennisdeling.
Twee sonnetten over software ontwikkelen
Stakeholder, u stijgt pas echt in achting / Als u - prijs de Heer voor dit geluk! - / Inziet wanneer niet de code de bug / Herbergt, maar uw eigen verwachting.