Don't Repeat Yourself (DRY) - Hoe gaan jullie er mee om?

[Michali]

Don't Repeat Yourself (DRY)

Een voor vele (hopelijk) bekend principe. Maar ik ben benieuwd hoe jullie er mee omgaan.

Ik probeer me er aan te houden, maar ik als het op pragmatische manier goed aanvoelt, dan ben ik er niet vies van even te copy pasten en aan te passen. Als ik echter 4 of 5 keer veel op elkaar lijkende code tegenkom, dan doe ik vaak een poging er een generiek component/class van te maken. Dit heeft voordelen, maar ik heb er ook nadelen van ondervonden. Zo blijkt vaak toch ineens een uitzondering te voorschijn te komen, op meerdere plaatsen, waardoor je soms met vreemde sub componenten of veel checks in een class komt te zitten.

Ik probeer van te voren meestal niet zo na te denken over of ik iets in een generieke vorm kan ontwerpen. Als ik herhalende code ontdek, dan refactor ik mijn weg meestal wel naar wat generieks. Dat vind ik persoonlijk wel prettig werken, maar brengt soms misschien wel wat extra werk met zich mee. Ik ben sowieso wel erge refactoring aanhanger. Ik doe dan ook vaak code reviews van eigen code om herhalende stukken te ontdekken en probeer dan te achterhalen wat het achterliggende concept is, als dat er is.

Al met al ben ik zeker voor dit principe, maar je moet er (net als met alles) niet te overdreven mee omgaan en toepassen als het nuttig is. Hoe gaan jullie er mee om en hebben jullie misschien nog wat tips op dit gebied?

[RobIII]

IMHO is DRY weer zo'n lekker vage term om interessant te kunnen doen op (nerd)feestjes
Een beetje van het DRY principe moet IMHO gewoon in de genen van een beetje devver zitten. Echt "regels" heb ik er niet voor, ik doe het een beetje op gevoel.

Met (regelmatig) refactoren kom je vaak genoeg dingen tegen die generieker kunnen, en dan los je dat gewoon ter plekke op; net zoals je, als je tijdens het devven een "deja vu" krijgt, het meteen generieker oplost met een sub/functie/class/whatever.

Echte tips heb ik niet, behalve het vooruit plannen van je code (blauwdrukken, functionele ontwerpen en dat soort dingen); dan kom je die "uitzonderingen" eerder tegen en kun je beter (=eerder) besluiten of iets wel of niet "DRY" moet worden

[whoami]

Tja, in ieder geval niet van in het begin alles zo generiek mogelijk willen doen, anders ga je gewoon niet vooruit.
Bepaalde dingen waarvan je zeker weet dat je duplicated code gaat hebben als je het niet 'generiek' doet (method maken, class, whatever), daar moet je gewoon voor zorgen dat je geen 'DRY' hebt.
Verder ben ik het met RobIII eens; als tijdens de implementatie blijkt dat je een bepaald stuk code beter generieker zou hebben, kan je het gaan refactoren.

[kenneth]

Ik zie meestal meer het tegenovergestelde gebeuren, waar dingen übergeneriek worden gemaakt, wat draken van ontwerpen oplevert, dan dat mensen braaf DRY toepassen: pas bij herhaling generaliseren.

Verder, net als RobIII een beetje op gevoel

[JKVA]

kenneth schreef op woensdag 04 oktober 2006 @ 22:39:
Ik zie meestal meer het tegenovergestelde gebeuren, waar dingen übergeneriek worden gemaakt, wat draken van ontwerpen oplevert, dan dat mensen braaf DRY toepassen: pas bij herhaling generaliseren.

Verder, net als RobIII een beetje op gevoel

Dat merk ik ook regelmatig, ook bij mezelf. Vooral dat je vooruit denkt te kunnen denken over wat een klant over 10 jaar eventueel zou willen hebben.

Ik probeer me meestal in te houden omdat je generiek-maak-acties toch meestal zinloos zijn omdat je van te voren toch vaak niet zeker weet wat generiek en specifiek moet zijn.

Te generiek programmeren kost A) tijd bij het bouwen omdat je meer en complexer programmeert en als het gewijzigd moet worden omdat je code vaak omslachtiger/complexer/groter is dan wanneer je het rechttoe rechtaan gemaakt hebt.

Dus, alleen generiek als je het echt zeker weet. En refactor het dan nog een keer zodat je generieke code duidelijk blijft.

[mulder]

Ik ben dol op generieke code, maar je kunt altijd overdrijven. Tegenwoordig is het belangrijker in je achterhoofd te houden dat je code evt kan genereren ipv dat code generiek is.

[MSalters]

Dupliceren, taggen, testen, en pas blijkt dat de code op allebei de plekken correct is recfactoren. Als je het meteen generiek maakt en in testen blijkt het maar in 1 van de 2 situaties correct, dan kun je daarna een boel moeite gaan doen om je originele situatie terug te krijgen.

[RobIII]

MSalters schreef op donderdag 05 oktober 2006 @ 21:13:
Dupliceren, taggen, testen, en pas blijkt dat de code op allebei de plekken correct is recfactoren. Als je het meteen generiek maakt en in testen blijkt het maar in 1 van de 2 situaties correct, dan kun je daarna een boel moeite gaan doen om je originele situatie terug te krijgen.

Met de nadruk op "taggen" ja. Het zou bijna verdwijnen in de rest van je reply, maar dat is inderdaad iets wat ik wel (vaak, niet altijd) hanteer. Copy/pasten, commentje erbij met een vaste "TAG" als "/* DUPLICATED */" en gaan met die banaan. En dan aan het eind van de rit refactoren.

[RedRose]

RobIII schreef op donderdag 05 oktober 2006 @ 23:43:
[...]

Met de nadruk op "taggen" ja. Het zou bijna verdwijnen in de rest van je reply, maar dat is inderdaad iets wat ik wel (vaak, niet altijd) hanteer. Copy/pasten, commentje erbij met een vaste "TAG" als "/* DUPLICATED */" en gaan met die banaan. En dan aan het eind van de rit refactoren.

Dat doe ik dus ook heel vaak. Een comment als //Do this better if possible, see line x as well

Voor de rest blijft het fingespitzengefuhl en voortschrijdend inzicht denk ik

[Michali]

Dat is wel een goed idee wat ik nog niet gebruik. Een stukje code taggen als je het copy-paste. Zo kun je later gemakkelijker herkennen wat openstaat voor refactoring naar een generiekere vorm, en je communiceert duidelijk dat je hier bewust voor hebt gekozen. (Iets wat ik ook erg belangrijk vind.)

Verder doe ik het ook op mijn gevoel, en het is idd. gewoon opdoen van ervaring waardoor je bepaalde patronen in zaken gaat herkennen. Vooral als je bezig bent met zaken die je nog niet eerder hebt gedaan is dit van toepassing. En natuurlijk de taal en framework (if any) goed kennen, zodat je niet onnodig zaken gaat schrijven die al kant en klaar aanwezig zijn om te gebruiken.