[Alg] Refactoring, hoe ver te gaan?

[whoami]

Ikzelf ben wel een 'voorstander' van het refactoren van code, en ik doe het zelf ook regelmatig op m'n werk; Als ik een stuk code bekijk, en ik denk 'Dit kan wel even anders of beter', of 'als ik dat nu zo ff wijzig, dan is m'n code makkelijker uitbreidbaar', etc... dan doe ik het ook meestal.

Echter, ik stel me soms toch vragen. Refactoring is voor mij een middel, maar geen doel op zich. Als ik echter soms zie hoe ver sommige personen daar in gaan, dan denk ik toch 'schiet je nu niet een beetje je doel voorbij'? Waarom persé aan bepaalde regeltjes (one line methods, geen private methods, etc...) voldoen ?
Zo kwam ik vandaag deze post tegen op de weblog van Brian Button, en ik dacht na het lezen toch van: 'heb je hier nu niet wat overdreven? Was het wel de moeite om al die tijd en moeite hierin te steken? Je kon die code wel verbeteren qua design, maar moest je het zo ver drijven?

In het Refactoring boek van Fowler staan wel enkele handige en bruikbare tips (polymorphise vs condities, factory methods/classes, ...), maar ik vind toch ook dat je niet te ver mag gaan hierin ('geen private methods', 'one line methods', ....). IMO is het de tijd en de moeite niet waard.

Refactoring kan z'n vruchten af werpen vind ik, maar 'extreme refactoring' zoals BB het hierboven noemde, vind ik toch wel zwaar overdreven.
Hoe denken jullie erover ? Zijn er hier mensen die toch bij die extreme dingen zweren en waarom ? Zijn er mensen die dit al eens toegepast hebben, en wat vonden ze er achteraf zelf van ? Was het de moeite waard ?

[prototype]

Opzich geen problemen mee, zolang het de interface/signatuur maar blijft handhaven; het gebruik van private methods staat dit ook niet in de weg. Het echter veelvuldig gebruik maken van private/one line methods kan mijns inziens bijdragen aan spaggetti code. Een method heeft op een gegeven moment dan veel dependencies, die wellicht niet eens gedocumenteerd zijn (omdat dit ook niet echt deel uit maakt van het interface); inhoeverre laatstgenoemde een probleem moet vormen is de vraag aangezien we 't hebben over kleine methods van relatief kleine 'complexiteit'. Ik kan me dan ook aan de andere kant voorstellen dat het soms dan fijner is om een kleine method te implementeren die herhaaldelijke handelingen uit handen neemt of een abstractie bied, en in feite in zekere zin onderhoudbaarheid/flexibiliteit verbeteren (door o.a. complexiteit/omvang tegen te gaan?). Kwestie van in hoeverre je het doordrukt dunkt me zo (afhankelijk van de bestaande structuur), maar als we encapsulation in acht houden dan zou het opzich voor de 'user' geen zak uit moeten maken.

[Alarmnummer]

whoami schreef op zondag 16 januari 2005 @ 13:48:
Ikzelf ben wel een 'voorstander' van het refactoren van code, en ik doe het zelf ook regelmatig op m'n werk; Als ik een stuk code bekijk, en ik denk 'Dit kan wel even anders of beter', of 'als ik dat nu zo ff wijzig, dan is m'n code makkelijker uitbreidbaar', etc... dan doe ik het ook meestal.

Ik maak iets pas uitbreidbaar als ik weet dat het uitbreidbaar gemaakt moet worden. Maar ik merk wel dat sinds ik met spring werk automatisch gebruik maak van dependency injection. Dit heeft als leuk bijeffect dat het dus erg configureerbaar is, maar voor mij is de belangrijkste toevoeging vanuit praktisch oogpunt: testbaarheid.

Als ik echter soms zie hoe ver sommige personen daar in gaan, dan denk ik toch 'schiet je nu niet een beetje je doel voorbij'? Waarom persé aan bepaalde regeltjes (one line methods, geen private methods, etc...) voldoen ?

Ik vind het verplicht aan regels voldoen ook onzin. Als het maar duidelijk is.. dan vind ik het goed genoeg. Maar geen private methods?? Wat is daar mis mee??

Hoe denken jullie erover ? Zijn er hier mensen die toch bij die extreme dingen zweren en waarom ?

De hele kleine refactorings doe ik op het moment dat ik er langs loop, maar de grote zaken daar moet je wel mee oppassen omdat je een systeem volledig over hoop kan halen.

Dus refactor met beleid.. kleine refactorings (en dan moet je vooral denken aan renamen en kleine methode aanpassingen) doe ik niet moeilijk over aangezien de scope van de wijzigingen vrij klein is. Maar pas op met grote refactoringen, binnen de korste keren ben je het hele systeem aan het verbouwen.

[ Voor 7% gewijzigd door Alarmnummer op 16-01-2005 15:08 ]

[Alarmnummer]

prototype schreef op zondag 16 januari 2005 @ 14:03:
Het echter veelvuldig gebruik maken van private/one line methods kan mijns inziens bijdragen aan spaggetti code.

Yep... dat is ook mijn grote probleem met van die kleine flut methodes. Ze hebben een betekenis binnen een bepaalde context (binnen een methode). Maar nu zit je hele class opgescheept met troep dat alleen binnen die context een betekenis had.

Wat ik wel vaak doe is even een variable aanmaken waarin de waarde van een conditie komt te staan. Vooral met complexe condities zie je beter wat er aan de hand is.

code:

boolean geldigeLeeftijd = p.leeftijd>8 && p.leeftijd<88 && p.leeftijd%2==0;
if(geldigeLeeftijd){
     ....
}

vs

code:

if(p.leeftijd>8 && p.leeftijd<88 && p.leeftijd %2 ==0){
    ....
}

[ Voor 38% gewijzigd door Alarmnummer op 16-01-2005 15:13 ]

[prototype]

Alarmnummer schreef op zondag 16 januari 2005 @ 15:07:
[...]

Yep... dat is ook mijn grote probleem met van die kleine flut methodes. Ze hebben een betekenis binnen een bepaalde context (binnen een methode). Maar nu zit je hele class opgescheept met troep dat alleen binnen die context een betekenis had.

Wat ik wel vaak doe is even een variable aanmaken waarin de waarde van een conditie komt te staan. Vooral met complexe condities zie je beter wat er aan de hand is.

code:

boolean geldigeLeeftijd = p.leeftijd>8 && p.leeftijd<88 && p.leeftijd%2==0;
if(geldigeLeeftijd){
     ....
}

vs

code:

if(p.leeftijd>8 && p.leeftijd<88 && p.leeftijd %2 ==0){
    ....
}

Ja, daar herken ik mezelf in terug, maar ja, dit is dan ook zoals je zegt binnen het context van gebruik. Een andere optie zou zijn om elke conditie apart te beschouwen:

code:

    boolean isTeJong = p.leeftijd < 8;
    boolean isTeOud = p.leeftijd > 88;
    boolean isEvenLeeftijd = p.leeftijd % 2 == 0;

    boolean isGeldigeLeeftijd = !isTeJong && !isTeOud && isEvenLeeftijd;

Op deze manier heb je in zekere zin een abstractie gecreeerd van wat nou beschouwd wordt als zijnde te jong of te oud. Het bepalen van een geldige leeftijd is hiervan afhankelijk. Een voordeel hiervan zou kunnen zijn dat je bv de boolean isTeJong en isTeOud misschien vaker zult gebruiken binnen je code. Het refactoren naar een andere leeftijdscriterium die effect heeft op de hele context is dan binnen 2 regels gebeurd door het aanpassen van de booleans isTeJong en isTeOud. De dependencies nemen dit over. Dit kan soms wenselijk zijn. Aldus mijn 2 cent.

[ Voor 8% gewijzigd door prototype op 16-01-2005 15:33 ]

[Alarmnummer]

prototype schreef op zondag 16 januari 2005 @ 15:30:
Ja, daar herken ik mezelf in terug, maar ja, dit is dan ook zoals je zegt binnen het context van gebruik. Een andere optie zou zijn om elke conditie apart te beschouwen:

Ik zou dit alleen doen als het echt een complexe conditie is die ik in meerdere stappen moet opbouwen. Dan is het idd een stuk handiger om het op te breken in kleine onderdelen.

Maar dit zijn echt van die kleine refactorings die je meteen moet doorvoeren als je een onduidelijk stuk code tegen komt. Kan je het niet in 1 oog opslag begrijpen? -> opschonen.. Zelfde geld voor namen van velden, variablen, methodes, classes en packages. Niet duidelijk? Schroom niet om het aan te passen.

Grote structurele wijzingen... tja.... pas op...

[ Voor 29% gewijzigd door Alarmnummer op 16-01-2005 15:48 ]

[Verwijderd]

Ik heb even http://dotnetjunkies.com/...ive/2005/01/15/44622.aspx doorgenomen. Belachelijk imho, als je al for-loops wil gaan factoren, erop kickt om van elke functie een one-liner te maken en private functies kost wat kost wilt vermijden, dan snap je volgens mij echt niet wat refactoren inhoudt.

[Verwijderd]

Alarmnummer schreef op zondag 16 januari 2005 @ 15:07:
[...]

Yep... dat is ook mijn grote probleem met van die kleine flut methodes. Ze hebben een betekenis binnen een bepaalde context (binnen een methode). Maar nu zit je hele class opgescheept met troep dat alleen binnen die context een betekenis had.

Wat ik wel vaak doe is even een variable aanmaken waarin de waarde van een conditie komt te staan. Vooral met complexe condities zie je beter wat er aan de hand is.

code:

boolean geldigeLeeftijd = p.leeftijd>8 && p.leeftijd<88 && p.leeftijd%2==0;
if(geldigeLeeftijd){
     ....
}

vs

code:

if(p.leeftijd>8 && p.leeftijd<88 && p.leeftijd %2 ==0){
    ....
}

Dit is toch een verschuiving van het probleem? Waar je eerst "spaghetti" methodes had, zit je nu met "spaghetti" variabelen. Ik zie niet in waarom dit netter is dan een methode er voor schrijven...

[Voutloos]

Ik vind het ook niet zo veel netter (er van uitgaande dat deze complexe conditie niet vaker terugkomt in de code). Toch is het beter te begrijpen voor de lezer, want de lezer krijgt dmv de naam die de variabele heeft extra info. Maar als dit maar op 1 plek gebeurt zou je het net zo goed met commentaar extra info kunnen verschaffen.

[prototype]

Ik denk dat Alarmnummer eerder doelt op 't feit dat je misschien deze boolean statement vaker zult gebruiken. In dit geval is dat opzich niet eens zo ondenkbaar.
En "spaghetti", tjah, soms zijn dependencies wenselijk (zie mijn voorbeeld/scenario + toelichting); bij mijn voorbeeld is het nog zelfs zo dat je schakelingen kunt maken.

[ Voor 16% gewijzigd door prototype op 16-01-2005 17:43 ]

[Alarmnummer]

Verwijderd schreef op zondag 16 januari 2005 @ 17:34:
[...]
Dit is toch een verschuiving van het probleem? Waar je eerst "spaghetti" methodes had, zit je nu met "spaghetti" variabelen. Ik zie niet in waarom dit netter is dan een methode er voor schrijven...

De scope van zo`n conditie variable is maximaal die hele methode. Je kunt dus gerust meerdere keren een isGeldig variable in verschillende methodes maken... maar het is wel vervelend als je meerdere keren een isGeldig methode hebt in je class. Dan vervuild code dat alleen een betekenis had in een bepaalde context je hele class.

Voutloos schreef op zondag 16 januari 2005 @ 17:40:
Ik vind het ook niet zo veel netter (er van uitgaande dat deze complexe conditie niet vaker terugkomt in de code). Toch is het beter te begrijpen voor de lezer, want de lezer krijgt dmv de naam die de variabele heeft extra info. Maar als dit maar op 1 plek gebeurt zou je het net zo goed met commentaar extra info kunnen verschaffen.

Gedeeltelijk mee eens. ik ga ook niet iedere conditie omzetten naar een losse conditie var. Alleen van die lange rotkrengen pak ik aan. of als ik met hele compelxe code bezig ben.. verder niet. En goeie documentatie vind ik in veel gevallen ook een redelijke oplossing.

Als ik maar kan zien wat er staat zonder dat ik een half uur bezig ben met het analyseren van de code. Het is bij mij niet zo dat het altijd zo moet.. dat de oplossing het doel op zich gaat worden.. refactoren moet beter leesbare code opleveren...

[ Voor 63% gewijzigd door Alarmnummer op 16-01-2005 18:06 ]

[Michali]

Ik ben ook zeker een voorstander van refactoring. Ik begin erg te merken dat het juist toepassen van de technieken beduidend duidelijkere code en daardoor ook gemakkelijker debugbare code oplevert. Ik merk ook dat het overdreven toepassen hiervan alleen maar averechts werkt. Het verplaasten van een conditie naar een aparte method doe ik alleen als ik hem op meerdere plaatsen tegenkom. Dit draagt dan eigenlijk meer bij aan "one rule, one place" regel, dan aan het duidelijker maken van de code. Dat gaat idd met een temp ook erg goed.

Verder ben ik wel voor kleine methods, maar je moet niet gaan overdrijven. Als ik binnen een loopje bijvoorbeeld iets opbouw of uitvoer, verplaats ik die acties meestal naar een aparte functie Ook als ik voor bepaalde statements een temp variabel opbouwd die je dan op 1 plaats gebruik, dan verplaats ik dat stukje naar een aparte method als het stukje te groot is. Bij 1-2 regels vind ik het alweer overdreven.

[whoami]

Alarmnummer schreef op zondag 16 januari 2005 @ 15:07:
[...]

Yep... dat is ook mijn grote probleem met van die kleine flut methodes. Ze hebben een betekenis binnen een bepaalde context (binnen een methode). Maar nu zit je hele class opgescheept met troep dat alleen binnen die context een betekenis had.

Idd, daar ben ik het mee eens; je kan wel je systeem gaan opsplitsen in vele kleine, begrijpbare methods, maar hoe zit het dan met het overzicht ?
Ben je dan niet het overzicht kwijt over de 'globale context' ?

Verwijderd schreef op zondag 16 januari 2005 @ 17:17:
Ik heb even http://dotnetjunkies.com/...ive/2005/01/15/44622.aspx doorgenomen. Belachelijk imho, als je al for-loops wil gaan factoren, erop kickt om van elke functie een one-liner te maken en private functies kost wat kost wilt vermijden, dan snap je volgens mij echt niet wat refactoren inhoudt.

Niet snappen wat refactoring inhoudt is misschien wat overdreven, maar ik ben het wel met je eens dat het belachelijk is om het zo ver te gaan doordrijven. Volgens mij schiet je dan aan je doel voorbij, en ben je meer bezig met te gaan refactoren dan dat je met je werkelijke 'core probleem' bezig bent.

[ Voor 40% gewijzigd door whoami op 16-01-2005 21:20 ]

[Boss]

It was hard to code, ot should be hard to understand

Waarom zoveel moeite doen? Code wordt gemaakt door programmeurs, en daarna onderhouden door programmeurs en niet door leken. Het hoeft dus wat mij betreft niet allemaal uitgeschreven te worden...

[whoami]

Boss schreef op zondag 16 januari 2005 @ 21:53:
[...]


Waarom zoveel moeite doen? Code wordt gemaakt door programmeurs, en daarna onderhouden door programmeurs en niet door leken. Het hoeft dus wat mij betreft niet allemaal uitgeschreven te worden...

Mjah..... al ooit eens code van jezelf opgerakeld na 2 of 3 jaar waar je geen documentatie over had? Wist je nog waarom je dit en dat zus en zo gedaan had?
Waarom zou je, als je weet dat de kans groot is dat je je code later zult moeten aanpassen of uitbreiden, je ze nu al niet zo schrijven dat uitbreiden/aanpassen gemakkelijk gaat?

Iemand die de regel handgaaft die jij zonet gequoted hebt, mag van mijn part zo uit mijn team vertrekken.

[Verwijderd]

Refactoring op welk moment, als je dit in je vrije tijd doet ga je gang, als je dit in de baas zijn tijd doet zou ik nog eens eventjes goed de voordelen en nadelen op een rijtje zetten. Er zijn veel puristen die als ze de kans krijgen complete dagen besteden aan het herschrijven van functies naar mooiere methoden, maar daarbij vaak totaal het overzicht in code uit het oog verliezen door het hopeloos ingewikkeld te maken.

Het is leuk voor de programmeur dat zijn code er als een diamantje uitziet, maar uiteindelijk gaat het om het eindresultaat. Daarbij vraag ik me wel eens af of dit soort personen vaak belanden in premature optimizations, en daarbij als een echte purist blijven hameren op een bepaald stukje code om maar vooral mooie code te krijgen. In bedrijfssituaties kan je dat echt niet flikken, en zeker niet in het heetst van de strijd.

[Verwijderd]

Boss schreef op zondag 16 januari 2005 @ 21:53:
[...]


Waarom zoveel moeite doen? Code wordt gemaakt door programmeurs, en daarna onderhouden door programmeurs en niet door leken. Het hoeft dus wat mij betreft niet allemaal uitgeschreven te worden...

Zodra andere mensen aan je code gaan werken, omdat je bijvoorbeeld ziek bent, omdat je het bedrijf verlaat, of omdat je het project gaat outsourcen naar het buitenland, is het belangrijk dat de betrokken partijen weten wat de code uitvoert. Met documentatie kun je situaties voorkomen waarbij je met aanpassingen andere delen van de applicatie beinvloed.

Al ben je nog zo'n goede programmeur, het is altijd wel prettig om te weten hoe de boel in elkaar steekt.

[Eskimootje]

Sommige dingen maak je begrijpbaar door commentaar te gebruiken in plaats van extra methode's/variabelen.
Daarnaast kun je het commentaar bij het maken van de documentatie automatisch toe laten voegen door programma's als phpdoc en javadoc dit bereik je niet door refactoring.

[ Voor 21% gewijzigd door Eskimootje op 16-01-2005 23:38 ]

[prototype]

Hmmm, refactoren is niet alleen voor het verduidelijken van je code, maar ook handig om bv efficientie te bewerkstelligen.

Een veelvoorkomend voorbeeldje:

code:

int c = 2;
int d = 3;
for (int i=0; i<5; i++) {
    System.out.println(i+c*d);
}

beter is het misschien om het te veranderen naar:

code:

int c = 2;
int d = 3;
int f = c*d;
for (int i=0; i<5; i++) {
    System.out.println(i+f);
}

Je kan natuurlijk f ook meteen vervangen met 6; bespaart je misschien wat geheugenregisters. Maar zoals je begrijpt, de berekening c*d wordt maar 1x uitgevoerd en niet 5x. Ik weet niet in hoeverre het compileren dit al voor je invult, maar je zou je bij een interpretive taal als php bv al voor kunnen stellen dat dit performance verspilling is. Ik heb in dit geval dan nog zelfs de loopguard zelfs op i < 5 gezet, maar 'k zou 't ook met i < arraylist.size(); kunnen vergelijken. Bij elke iteratie zou dan ook een beroep gedaan worden op de size method van een arraylist. Soms is dit wenselijk wanneer je bv in je codeblok ergens misschien steeds meer objecten toevoegt/verwijdert van arraylist, maar vaak wordt dit behandelt als zijnde constant. In die gevallen is dit dan dus ook efficient en een int/short eraan opofferen zou geen kwaad kunnen.

[ Voor 6% gewijzigd door prototype op 16-01-2005 23:41 ]

[jvaneijk]

offtopic:
Does that boy have a life...

Op zaterdag nog wel ga gewoon lekker stappen ofzo

Maar idd refactoring moet kunnen maar wel leesbaar en begrijpelijk blijven..

[Alarmnummer]

Verwijderd schreef op zondag 16 januari 2005 @ 22:47:
Refactoring op welk moment, als je dit in je vrije tijd doet ga je gang, als je dit in de baas zijn tijd doet zou ik nog eens eventjes goed de voordelen en nadelen op een rijtje zetten.

Het ligt eraan op welk nivo je gaat refactoren. Als je kleine dingen tegen komen moet je dat eigelijk meteen oplossen. Als code daardoor beter begrijpbaar is, is het even een investering, maar zal zich continu terug betalen. En als je dit continu doet zal het niet zo snel gebeuren dat je veel werk hoeft te verzetten.

Grote refactorings zou ik wel even links laten liggen. En het is niet de bedoeling dat je alle code dan maar bij langs gaat. Maar als ik een stuk code bij langs ga en ik zie een kleine onduidelijkheid, dan pas ik het meteen aan. Betere naamgeving.. extra regel(s) commentaar, etc.

Er zijn veel puristen die als ze de kans krijgen complete dagen besteden aan het herschrijven van functies naar mooiere methoden, maar daarbij vaak totaal het overzicht in code uit het oog verliezen door het hopeloos ingewikkeld te maken.

dat zijn de wat grotere refactorings. Grotere refactorings zijn ook belangrijk. De algehele structuur van de applicatie moet gehandhaafd blijven. Als je dit niet in het oog houd zal je systeem op den duur een stovepipe system worden. Een systeem waarin iedere nieuwe feature meer en meer tijd kost en tijdens het ontwikkelen ervan het systeem continu afbrokkelt. Uiteraard vergrijp je dan aan de lapmiddelen en de noodoplossing -> de feature zit er na veel moeite toch in.. en het werkt... Het probleem.. de volgende feature gaat nog meer tijd kosten... met nog meer moeite... En verder kun je absoluut geen uitspraken meer doen over het systeem mbt performance.. security... uitbreidbaarheid..

jvaneijk schreef op maandag 17 januari 2005 @ 00:19:

offtopic:
Does that boy have a life...

Op zaterdag nog wel ga gewoon lekker stappen ofzo

Maar idd refactoring moet kunnen maar wel leesbaar en begrijpelijk blijven..

Heb je techposts nodig? Wat je hier schrijft is echt volslagen onzin en ik vraag me af of je weet wat refactoring is.

[ Voor 42% gewijzigd door Alarmnummer op 17-01-2005 07:34 ]

[Verwijderd]

Het hebben van private methoden lijkt me overigens in veel gevallen de leesbaarheid juist bevorderen. Wellicht zou je je wel als regel kunnen stellen dat je even goed moet nadenken of het nodig is bij elke private methoden.
Over het algemeen doe ik het alleen bij dingen die vaker terugkomen, maar als ik een methode heb waar ontzettend veel code in moet wil ik het ook wel een opsplitsen in nog een tweede of een derde methode. Soms splits ik de code ook gewoon met:
/**************THE BLA_PART****************/ ofzo, maar dat is misschien meer voor C. In ieder geval heeft elke methoden zijn commentaar erboven staan.
Ook probeer ik altijd nog wel na te gaan of je niet ergens het systeem flexibeler kunt maken door wat extra abstractie, maar eigenlijk had je dat van tevoren al moeten bedenken. Ik kan me goed voorstellen dat de overkill het weer minstens net zo onbegrijpelijk kan maken, maar zoals met alles moet je gewoon het achterliggende idee in de gaten houden.
Het scheelt als je er een klassendiagram bij hebt, maakt het al een stuk makkelijker leesbaar. Vooral als het klassendiagram alleen de echt noodzakelijke methoden bevat.

[Verwijderd]

Verwijderd schreef op maandag 17 januari 2005 @ 07:54:
Het hebben van private methoden lijkt me overigens in veel gevallen de leesbaarheid juist bevorderen. Wellicht zou je je wel als regel kunnen stellen dat je even goed moet nadenken of het nodig is bij elke private methoden.

Je schrijft logischerwijs enkel private methodes als je dubbele code fragmenten hebt. Alleen is het natuurlijk discussieerbaar of je dergelijke code fragmenten niet kunt encapsuleren in een andere klasse.

Neem bijvoorbeeld een sorteer algoritme, je zult hier vaak een methode "swap" tegenkomen voor het wisselen van elementen. Je zou ook kunnen stellen dat een dergelijke methode een public methode dient te zijn van een collectie klasse.

Dus voor het niet hebben van private methodes valt volgens mij altijd wel wat te zeggen. Wat beter is weet ik niet

[Michali]

Als een private method de samenhangedheid van de code niet benadeeld zie ik echt geen probleem. Als het echt bijdraagt bij de taken van de class dan is een private method gewoon een goede oplossing.

[Verwijderd]

Ik stel ook niet dat er een probleem is om private methodes te gebruiken. Ik stel dat ze discussieerbaar zijn. Meestal zijn dergelijke methodes onder te brengen in een andere klasse.

[Alarmnummer]

Verwijderd schreef op maandag 17 januari 2005 @ 10:28:
Ik stel ook niet dat er een probleem is om private methodes te gebruiken. Ik stel dat ze discussieerbaar zijn. Meestal zijn dergelijke methodes onder te brengen in een andere klasse.

Juist niet Private methodes hebben per definitie een betekenis alleen binnen die class en nergens anders. Dus als je iets niet onder zou willen brengen in een andere class, dan is dat wel een private method.

[Verwijderd]

Zie mijn voorbeeld over het gebruik van "swap" binnen een sorteer algoritme alarmnummer.

[Verwijderd]

Alarmnummer schreef op maandag 17 januari 2005 @ 10:34:
[...]


Juist niet Private methodes hebben per definitie een betekenis alleen binnen die class en nergens anders. Dus als je iets niet onder zou willen brengen in een andere class, dan is dat wel een private method.

Dat is dus één van de dingen die je met Refactoring na moet gaan dan denk ik. Of het inderdaad enkel een betekenis heeft binnen die class, of dat het ook een algemene betekenis zou kunnen krijgen. Zoals met de swap-functie dus.
Echter, al die functies, zoals makeButton() ofzo, public maken, lijkt me echter het geheel niet duidelijker maken. Persoonlijk ga ik er van uit dat public methoden zoveel mogelijk met de businesslogic te maken hebben. Functies als swap en makeButton hebben daar weinig tot niets meer mee te maken. Stel je voor als er in een klasse met 8 public methoden nog eens 30 public methoden bij komen die allemaal iets "handigs" doen en dat je dan a.d.v. de code moet achterhalen wat het doel van die klasse ook al weer was?

Of moeten die "handige" functies in een klasse HandigeZooi.class

[Verwijderd]

Zo gek is dat niet, zo'n HandigeZooi.class. Je spreekt immers over een factory method, dus die kan je best in een fabriek klasse onder brengen.

[Alarmnummer]

Verwijderd schreef op maandag 17 januari 2005 @ 10:54:
[...]

Dat is dus één van de dingen die je met Refactoring na moet gaan dan denk ik. Of het inderdaad enkel een betekenis heeft binnen die class, of dat het ook een algemene betekenis zou kunnen krijgen. Zoals met de swap-functie dus.
Echter, al die functies, zoals makeButton() ofzo, public maken, lijkt me echter het geheel niet duidelijker maken. Persoonlijk ga ik er van uit dat public methoden
zoveel mogelijk met de businesslogic te maken hebben.

Slechte aanname. Public methodes zijn methods die publiekelijk toegankelijk zijn.. niet meer niet minder. Totaal niet gebonden aan business logic...

Functies als swap en makeButton hebben daar weinig tot niets meer mee te maken. Stel je voor als er in een klasse met 8 public methoden nog eens 30 public methoden bij komen die allemaal iets "handigs" doen en dat je dan a.d.v. de code moet achterhalen wat het doel van die klasse ook al weer was?

Of moeten die "handige" functies in een klasse HandigeZooi.class

Zo nu en dan krijg je een handige functie class. Zie bv Collections, Arrays etc van Java.

[ Voor 4% gewijzigd door Alarmnummer op 17-01-2005 12:16 ]

[Verwijderd]

Goed, maar dan kun je dat soort dingen beter zo abstract mogelijk in een soort handigetoolkit.jar pakken, dan kun je die jar altijd meenemen naar andere projecten. In die zin is het wel handig dan.

Natuurlijk is het waar dat public niets met business logic te maken hoeft te hebben, maar het is wel de business logic die je als code-lezer eruit moet zien te halen. Een overvloed aan public-methoden maakt dan m.i. moeilijker en onoverzichtelijker dan een overvloed aan private-methoden.
Eigenlijk zou je:
public businesslogic void method() moeten kunnen aanmaken. Dan kan je IDE daar een ander kleurtje in 't overzicht aangeven en dan is het direct een stuk overzichtelijker. De compiler kan die info dan gewoon herkennen en weggooien.

[Alarmnummer]

Ik heb verder een beetje het gevoel dat we verzanden in allerlei oninteressant geneuzel. Dus misschien kunnen we weer ontopic komen: Refactoring, hoe ver te gaan?

[Verwijderd]

Alarmnummer schreef op maandag 17 januari 2005 @ 12:22:
Ik heb verder een beetje het gevoel dat we verzanden in allerlei oninteressant geneuzel. Dus misschien kunnen we weer ontopic komen: Refactoring, hoe ver te gaan?

Hoe ver je gaat hangt samen met de situatie, mogelijkheden, budget, kosten, resultaat verwachtingen, etc.

Er is niet een bepaalde richting te geven aan refactoring, dat hangt echt af van wat je gaat refactoren en de bijbehorende mogelijkheden, uitwerkingen, en variabelen.

[whoami]

Verwijderd schreef op maandag 17 januari 2005 @ 13:06:
[...]


Hoe ver je gaat hangt samen met de situatie, mogelijkheden, budget, kosten, resultaat verwachtingen, etc.

Er is niet een bepaalde richting te geven aan refactoring, dat hangt echt af van wat je gaat refactoren en de bijbehorende mogelijkheden, uitwerkingen, en variabelen.

Idd.
Het hangt voornamelijk af van wat je in de toekomst met die code wilt doen; wat de toekomst is voor de applicatie / systeem; hoe snel het probleemgebied veranderd, etc...

Echter, het ging mij vooral om die extreme gevallen zoals geillustreerd in de weblog die ik gepost heb. Ik kan me bv. niet voorstellen dat er mensen zijn, die in een productie-environment, in het bedrijfsleven, ... zich bezig houden met het refactoren tot op zo'n geneuzel. Ik vraag me af wat de werkelijke toegevoegde waarde daarvan is.

[pjvandesande]

whoami schreef op maandag 17 januari 2005 @ 13:09:
[...]


Idd.
Het hangt voornamelijk af van wat je in de toekomst met die code wilt doen; wat de toekomst is voor de applicatie / systeem; hoe snel het probleemgebied veranderd, etc...

Echter, het ging mij vooral om die extreme gevallen zoals geillustreerd in de weblog die ik gepost heb. Ik kan me bv. niet voorstellen dat er mensen zijn, die in een productie-environment, in het bedrijfsleven, ... zich bezig houden met het refactoren tot op zo'n geneuzel. Ik vraag me af wat de werkelijke toegevoegde waarde daarvan is.

Hangt er een beetje vanaf hoe lang het product nog ontwikkeld word. Als jij het product start voor nieuwe technieken ook geschikt wil maken, dus straks weer een hoop gaat doen met de code, dan heeft het wel zin.

Maar er moet wel tijd en geld voor zijn. Ik kan mij heel erg goed voorstellen dat dit in 9/10 gevallen helemaal geen zin heeft. Maar in sommige gevallen kan het best wel nuttig zijn denk ik.

Toch blijf je met de vraag zitten hoever je hier dan in gaat.

Je gaat zover budget, relevantie en tijd je toelaat.

[whoami]

questa schreef op maandag 17 januari 2005 @ 13:16:
[...]


Hangt er een beetje vanaf hoe lang het product nog ontwikkeld word. Als jij het product start voor nieuwe technieken ook geschikt wil maken, dus straks weer een hoop gaat doen met de code, dan heeft het wel zin.

Je gaat me niet vertellen dat een one-line method, of een class zonder private methods veel beter onderhoudbaar zijn, dan een andere goed gedesignde class (waarbij men dus zo ver niet gegaan is).

[pjvandesande]

whoami schreef op maandag 17 januari 2005 @ 13:19:
[...]

Je gaat me niet vertellen dat een one-line method, of een class zonder private methods veel beter onderhoudbaar zijn, dan een andere goed gedesignde class (waarbij men dus zo ver niet gegaan is).

Dan ga je ook heel ver, alleen ga je heel ver op een ander gebied.

Mij lijkt Onliners absoluut niet duidelijk en overzichterlijk. Persoonlijk zou ik gaan voor een goed gedisignde classen ontwerp met abstractie.
Is onderhoudbaarder en overzichterlijk naar mijn mening.

Maar hoever ga je hier in?

Het gaat opzich niet zozeer om hoever je gaat met onliners, hoever ga jij met je methode die voor jou het overzichtelijkst en onderhoudbaarst lijkt?

[Verwijderd]

Alarmnummer schreef op zondag 16 januari 2005 @ 15:07:
[...]

Yep... dat is ook mijn grote probleem met van die kleine flut methodes. Ze hebben een betekenis binnen een bepaalde context (binnen een methode). Maar nu zit je hele class opgescheept met troep dat alleen binnen die context een betekenis had.

Wat ik wel vaak doe is even een variable aanmaken waarin de waarde van een conditie komt te staan. Vooral met complexe condities zie je beter wat er aan de hand is.

code:

boolean geldigeLeeftijd = p.leeftijd>8 && p.leeftijd<88 && p.leeftijd%2==0;
if(geldigeLeeftijd){
     ....
}

vs

code:

if(p.leeftijd>8 && p.leeftijd<88 && p.leeftijd %2 ==0){
    ....
}

Hier gebruik je toch gewoon comments voor??? //check of de leeftijd wel geldig is

[koli-man]

Ik weet wel dat refactoring altijd een aparte zaak is.
Als je iemand anders zijn werk gaat refactoren kan soms best een rare zaak zijn. Je weet niet vaak de gedachtengang van iemand. Misschien is het vies en snel gedaan, want dat komt maar al te vaak voor. Misschien heeft die voorganger net wat te weinig ervaring gehad en is het een beetje klungelig opgelost.
Wanneer weet je of iets goed genoeg is gerefactored? Op welke basis ga je refactoren: Wil je snelheidswinst of vooral onderhoudbaarheid van de code:
imho denk dat refactoren vaak een tijdrovende klus is en dat het niet altijd even gemakkelijk is.

[Verwijderd]

whoami schreef op maandag 17 januari 2005 @ 13:09:
Ik kan me bv. niet voorstellen dat er mensen zijn, die in een productie-environment, in het bedrijfsleven, ... zich bezig houden met het refactoren tot op zo'n geneuzel. Ik vraag me af wat de werkelijke toegevoegde waarde daarvan is.

Erm.. niet? .. Ik wordt geevalueerd op basis van resultaten, en voor management zal het een worst wezen of ik iets op een mooie of minder mooie manier heb opgelost. Als het maar werkt, "get the job done"..

Als er op een later moment een punt komt dat je zegt, de noodzaak is er vanwege uitbreidingen, vanwege performance issues, vanwege structurele wijzigingen, dan pas ga je samen zitten om de voor en nadelen op een rijtje te zetten, er moet wel geld verdient worden, niet geld verbrand worden.

En uiteraard, er zullen reacties komen als "maar met refactoring bespaar je geld op de langere termijn".. probeer dan eens in management termen te denken, en deze besparing meetbaar te maken, dat kun je niet aangezien software ontwikkeling een continue proces is van wijzigingen en toevaligheden.

[ Voor 6% gewijzigd door Verwijderd op 17-01-2005 13:57 ]

[Alarmnummer]

Verwijderd schreef op maandag 17 januari 2005 @ 13:38:
[...]
Hier gebruik je toch gewoon comments voor??? //check of de leeftijd wel geldig is

Lees mijn tekst nou eens even goed! ALs je lange en complexe condities hebt is het handiger om die conditie eruit te slopen en desnoods de conditie op te breken in verschillende onderdelen. Dan zie je tenminste de structuur van de statements goed...

[ Voor 9% gewijzigd door Alarmnummer op 17-01-2005 14:12 ]

[Michali]

Refactoring zou je als het goed is gewoon binnen ieder project terug moeten zien komen. Een stuk code is nooitzelden perfectgoed in eerste instantie. Je komt altijd wel even terug op een stuk code tijdens de ontwikkeling. Indien dan al niet direct duidelijk is hoe het werkt ga je over op refactoren totdat het voor je gevoel wel duidelijker is. Ga gewoon zo ver totdat het gemakkelijk leesbaar en uitbereidbaar is en niet verder. Ik ben ook van mening dat dit niet zorgt dat een project vertraagd. Juist het uitbereiden gaat dan een stuk sneller en vaak kun je gelijk gebruik maken van functies die net refactored zijn.

[Michali]

Als jullie refactoren, doen jullie het dan echt volgens de regels die in het boek beschreven worden? Dus bij iedere refactoring ook echt testen of alles nog werkt, of zijn jullie daar iets soepeler in?

[Alarmnummer]

Michali schreef op donderdag 20 januari 2005 @ 12:38:
Als jullie refactoren, doen jullie het dan echt volgens de regels die in het boek beschreven worden? Dus bij iedere refactoring ook echt testen of alles nog werkt, of zijn jullie daar iets soepeler in?

Een beetje afhankelijk van het systeem. Ik ben oa bezig met een Prolog compiler en ik heb daar enorm zware testsuites draaien. Voor iedere regel code is er ook wel een regel testcode, want bugs wil je daar zo snel mogelijk opsporen omdat het vaak hele subtiele fouten als gevolg heeft. Ik compileer daar niet eens meer direct, maar draai alleen nog maar testsuites (die het compileren zelf afdwingen)

Bij andere applicaties ligt het er een beetje aan. Op dit moment assisteer ik zo nu en dan ook bij een ander project en aangezien het systeem niet testbaar is, is het voor mij ook erg lastig om daar tests aan toe te voegen.

[ Voor 7% gewijzigd door Alarmnummer op 20-01-2005 12:49 ]