Dus in mijn ogen is het geen kwestie van competentie op het gebied van programmeren, maar het durven geven van garanties op werk van anderen.
Maar ook dit grijpt weer terug op de essentie van hoe we programmeren.
Waarom zouden mensen deze garantie moeten durven te geven op het werk van anderen? Waarom is deze garantie niet af te lezen uit de code zelf?
Er bestaat wel degelijk het concept van formal correctness proofs, alleen deze zijn opzich zelf met de huidige middelen dan ook weer veels te complex om practisch toe te passen. Je ziet dit eigenlijk alleen gebeuren voor algoritmes die voor extreme omgevingen gebruikt moeten gaan worden (denk kerncentrale toepassingen, ruimtevaart, etc). En zelfs DAAR gaat het fout!
Embedded (b.v. via annotations) assertions en constraints op code gaat al een stukje de goede kant op (voor hele simpele gevallen denk b.v. aan @NonNull, @NonEmpty etc op variables en return values), maar we zijn er nog lang niet.
we schrijven sneller code dan documentatie echter daardoor mis je wel een essentieel onderdeel van je ontwerp proces
Maar als de bedoeling van code in de eerste instantie helderder en more consise zou zijn, dan was documentatie helemaal niet nodig!
Sterker nog, documentatie is JUIST een ENORME bron van bugs!
Het probleem is namelijk dat documentatie in de regel eigenlijk altijd achterloopt. Men past de code aan, maar 9 van de 10 keer vergeet men dat er ergens anders documentatie was die nu verkeerd is. Of helemaal erg, men copy/paste code, past wat aan, en laat de oorspronkelijke embedded documentatie (b.v. in Java de JavaDoc) staan. Deze documentatie klopt nu echter totaal niet meer. Je wilt niet weten hoe vaak, hoe gruwelijk vaak we dat tegenkomen in code bases die we moeten cleanen.
Dit heeft te maken met een slecht ontwerp proces.
En slechte en niet duidelijke requirements. Bij het klassieke waterval model was dit natuurlijk helemaal een ramp, waar de requirements eigenlijk in een final versie opgeleverd worden, dan er een final design kwam en dan pas met code werd begonnen.
Eigenlijk wist men dan al lang al dat de requirements ondertussen compleet veranderd waren, maar ja... het process he? Het process zei dat er niets meer veranderd mocht worden, dus pech! Maar lekker gaan implementeren en met het volgende produkt doen we het dan wel weer goed.
Maar ook met zeer korte iteraties (i.e. 2/3 weken zoals bij Scrum) gaat dit net zo goed fout. "Men" weet namelijk ook niet precies wat ze nou willen, en veranderd vaak van mening. Ene sprint gaan we focussen op het verwerken van de geld stromen, andere sprint moet dat er toch maar weer uit want money is toch evil, en dan de volgende sprint maar weer erin want hey, we hebben toch ook inkomsten nodig.
Ook hier blijkt weer dat eigenlijk de huidige best practice processen ook helemaal niet zo super werken. Ik voorspel dat zoals we nu met minachting op waterfall terugkijken, men over 10 jaar met minachting terug kijkt op Scrum, als het volgende best practice process is uitgevonden.
Hierbij krijg je code die veel dichter bij het mental model van een normaal mens komt en daarbij leesbare code omdat de code gebaseerd is op classes en objecten die functionaliteit uit de realiteit over neemt.
Inderdaad, dit is een belangrijk ding. Ik voer b.v. vaak als regel in dat de namen van domain classes MOETEN overeenkomen met het daadwerkelijke domain. Heet iets in de UI "Car", dan MOET de bijbehorende page (indien het een web UI is) /cars zijn, en indien er een id doorgegeven moet worden car_id, en de bijhorende class Car zijn, etc.
Vaak zie je mensen die dit niet snappen. Car in de UI wordt dan opeens een page /auto, een id wordt amid (automobile id), en de class heet dan opeen MotorVehicle.
Kortom, men doet eigenlijk maar wat en gebruikt een naam die gewoon ter plekken in ze opkomt, zonder te kijken of er voor een concept al een bepaalde term in gebruik is.
In een erg extreem geval heb ik ooit een software systeem moeten cleanen waarbij er een klein handboekje (10 bladzijden) met tabellen was die termen bevatten met daarbij alle alternatieven variable namen die in de code voorkwamen. Daar had je sommige termen bij die meer dan 10(!) totaal verschillende namen in code hadden. En dan had je nog overlappende namen ook. Dus in het voorbeeld boven was "vehicle" dan een alternatief voor "car" (en een -direct- alternatief, niet als een super class!), maar "vehicle" bestond ook en dat was wat anders als een "car", maar... een alternatief voor "vehicle" was... "car"! En dan als echt alternatief ook, niet in de betekenis van sub class!
Deze naamsverwarring bleek na een lange analyse een enorme bron van bugs en tijdsverspilling (en dus geld) te zijn.
Programmeurs bleken continu de namen door elkaar te halen. Dan werd er b.v functionaliteit voor een Car geschreven, en dan nog gecontroleerd ook of Car daadwerkelijk een Car was (door b.v. 4 lagen diep de variable te volgen), maar ja, dan ging het uiteindelijk toch weer fout na dagen van programmeren want helemaal down in de DB bleek het dan toch om een Vehicle te gaan.
Er zo waren er nog veel meer onzinnige dingen in de code alleen al qua namen (kan er een klein boekwerk over schrijven waarbij The Daily WTF! verbleekt).
[Reactie gewijzigd door flowerp op 23 juli 2024 23:18]