Prod

Dit is net het herophalen van data waarvan we al zeker zijn dat bestaat. We hebben in een vorige stap die data opgezocht. Nu willen we die nog eens gaan uitlezen uit de DB.

Nee, het is best van deze data op te kuisen. Kan in het slechtste geval nog vervuild zijn van de vorige iteraties over de bonnummers

OrderAPI newen in constructor graag.

Ook hier gebeurt wel heel erg veel op 1 lijn hé...
Tenminste het product verdient wel een eigen lijn vind ik en dan nog liefst met een ProductRolAPI die in de constructor genewed wordt (en tevens niet van de DomeinContext afgenomen wordt )

Typo

Deze houdt toch risico in, denk ik, want je geeft normaal een object terug van type DS.Prod.OptiBox.BoxDataMetID, maar de logica laat toe dat dit object undefined is en op de volgende lijn van het stuk code dat deze private method gebruikt wordt er gebruik gemaakt van een property van dit object. Je komt ermee weg omdat de repo daar met lege strings overweg kan, maar 't is niet helemaal correct zoals het hier afgehandeld wordt. Minimaal zou je een leeg object moeten teruggeven, of je moet er nog een "Bestaat..." of "Heeft..." tussen moeten steken.

Hier gebeurt wel heel erg veel op 1 lijn hé
Tenminste het product verdient wel een eigen lijn vind ik en dan nog liefst met een ProductRolAPI die in de constructor genewed wordt (en tevens niet van de DomeinContext afgenomen wordt )

Is het niet gevaarlijk die al uit de repo te gaan verwijderen terwijl er nog processen (de calls hieronder) in gang gaan gezet worden, die misschien nog gaan crashen? Moet deze verwijder niet op het einde van deze method uitgevoerd worden (vlak voor het loggen dat hij ermee klaar is)?

Aangezien ge hier beide mogelijkheden voorziet (injecteren of de echte gebruiken) moet ge dat ook bij de parameter duidelijk maken door die als lege string te defaulten, zoals bij de andere parameters gedaan is. Op die manier, als iemand deze klasse instantieert ergens, ziet die persoon gelijk aan de parameterdefinitie dat die niet per se moet meegegeven worden (en dat dan een nieuwe instantie voorzien is door deze constructor).

Graag de èchte instantiëren en niet van de DomeinContext afnemen.

Moet/mag deze lijn in comment blijven staan? Graag comment erachter met meer duiding.

Best diene Partialloadonfloor hier ook nog eens defaulten op 0, want hij wordt in deze method rechtstreeks gebruikt enerzijds en anderzijds wordt hij als parameter in de aanroepende method toch ook al gedefaulted op 0, dus mag consistent zijn, zoals gedaan is bij MinFillPercentage. Kan anders gevaar opleveren als deze private method ooit nog door een andere method gecalled wordt ook, waarin dan deze parameter nergens gedefaulted staat. (= undefined at runtime)

Korttekst = string (gotta love Cache en types )

Moet deze in comment blijven staan? Mag die niet gewoon weg dan? Minstens een comment erachter zetten over het waarom de lijn in comment staat

Lekker muggeziften... dimmekes altijd bovenaan in de method zetten, vóór de setjes.

Graag de èchte instantiëren en niet van de DomeinContext afnemen.

Die Dummy ook buiten de While loop dimmen graag

No big deal.
Codebase in t Nederlands, maar StringUtils.Replace() is Engels, dus wellicht geen taal-reset van mijn brains

Maar in feite zetten we geen commentaar in onze code (= clean code principle!)
Hier, in dit specifiek geval is het echter om te benadrukken dat ALLE spaties moeten vervangen worden.
Uitzondering bevestigt de regel.

Algemene vraag:

Ik heb als PM tester enkele opmerkingen in het Jira ticket geplaatst.
Moet ik hier al reviewer rekening mee houden tijdens de review?

De uitleg van Tom was dat de reviewer enkel de kwaliteit van de code moet beoordelen.
Maar er is een optie 'factually incorrect' in de tool, en mogelijks vallen enkele van mijn opmerkingen onder deze noemer?

Graag advies.

Style:

• Codebase is volledig in het Nederlands, waarom deze comment dan in het Engels?