Sir, step away from that keyboard!

Refactoring is making your software do the same ... just better.

Thomas

... eller blot at gøre det det gør nu, uden at det er en langvarig pine at få det til også at gøre den næste, der ønskes af det.

Som den heldige kartoffel jeg er, beskæftiger jeg mig for tiden med at skrive min afsluttende hovedopgave på mit studie.

Det er fantastisk at føle frihed til, at skrive en fuldstændig implementation, teste og fejlrette på den i nogen tid, og så smide den væk og starte forfra på en ny.

Det er fantastisk at kunne frakoble sig opgaven, og begrave sig i teori og artikler om datastrukturer i et par dage, når man opdager at dén man benytter, ikke er optimal til formålet.

Forstå mig ret - det bliver, forhåbentlig, også fantastisk at ramme arbejdsmarkedet og tjene lidt mere til livet på det man laver, men jeg er spændt på hvor meget det kommer til at gå ud over grundigheden og fordybelsen.

Jesper

Eneste problem er at hvis jeg bruger for meget tid væk fra keyboardet så har jeg det med at starte fra scratch når jeg kommer tilbage, for der var godt nok meget som jeg kunne have gjort bedre.

Og nu du skriver det med at bruge 20 minutter på at kompilere, ja så er det jo nærmest uundgåeligt, jeg kan lige så godt bringe linket som en anden kan: http://xkcd.com/303/

Tager I kodekvalitet så seriøst, at I tør stå på retten til at gå en tur på en halv times tid, midt i arbejdstiden, for at tænke over koden?

Jah ... men jeg ved ikke om jeg vil kalde det "kodekvalitet" - det har en tendens til at lyde som ren pyssenysset æstetik. Jeg foretrækker at tænke på at "have en kinamands chance for at hitte på en løsning som ikke bliver blæst omkuld af næste uforudsete situation".

Nu har jeg heldigvis aldrig arbejdet for en chef som ikke havde forståelse for at det er en del af arbejdsbeskrivelsen at gå ture og tænke dybt. Skulle jeg nogensinde komme til det, ville jeg næppe arbejde der længe.

Det vigtigste ved refaktorisering er processen. Når man programmerer, så befinder man sig i en erkendelsesproces, hvor problemets dybde ikke er helt klart fra starten. Hvis man sidder og programmerer "med blæk", så falder man tit ned i nogle tankefælder, hvor prøver at fantasere en struktur, man ikke har skrevet endnu.

Refaktorisering sætter en fri til at skrive en implementation, man øjeblikkeligt er parat til ændre. Man behøver ikke at kæmpe mod sine fantasifostre, men kan forholde sig til de strukturer, man har. Hvis de ikke er tilstrækkelige, så kan man bare lave dem om.

Prøv at tænk på dagen i går: Hvor stor en del af din tid blev brugt på at skrive nye rutiner, hvor stor en del blev brugt på at ændre noget, du har skrevet tidligere, og hvor meget tid går med at holde styr på et design, der ikke har taget form endnu.

Jeg har en bekendt, der arbejdede et sted, hvor chefen mente, at deres kildetekster var likvid kapital. Ingen måtte rette i noget, der var skrevet, og det gav to frustrationer: Enten sad man og prøvede finde en vej til at få noget klytkode til at gøre noget smart, eller også sad man på hænderne for ikke at komme til at skrive noget klytkode. Begge dele er meget uproduktivt.

Thomas

Jeg har aldrig set en autoritativ definition af "refaktorisering", men har indtryk af at det temmelig bredt dækker noget i retning af "at skrive sin software om så det gør det samme som før, men i en pænere arkitektur der gør det lettere at tilføje funktionalitet og/eller rette fejl fremover".

Og det er klart at det er en vigtig del af udvikling -- jeg vil skyde på at jeg bruger en tredjedel af min arbejdstid i dén mode. Men jeg har svært ved at se at vi får noget ud af at finde på et fint ord for det og lade som om det er noget helt nyt der vil ændre alting.

Når vi snakker om at "refaktorisere" på mit arbejde, er det sædvanligvis med henvisning til "refactor"-menuen i Eclipse, som kan automatisere en række simple omskrivninger i koden -- men som langtfra når de arkitekturtilpasninger jeg bruger 1/3 af min tid på.

Om refactoring virker eller ej, handler primært om hvorvidt programmøren har selvkontrol nok til at lægge keyboardet fra sig og stirre lige ud i luften og om firmaet er villig til at betale løn for det.

Jeg ved ikke om jeg vil uddybe for meget, men når der virkelig skal laves seriøst, og gennemtænkt' edb, så læner jeg mig tilbage, stængerne op på bordet, og kigger ud af vinduet.

Det er for mig den perfekte udviklerstilling.

Det med 'uddybe' beror på en sceance hvor jeg skulle lave nogle opgaver for en 'biks'.

Selvfølgelig ville tilfældet, at der var en såkaldt ergoterapeut rundt og skulle kontrollere stolehøjde, bordhøjde, afstand til keyboard, sigtelinie til skærm, så den havde den ergonomiske korrekte højde osv.

Jeg var ekstern, og lavede ting på fast pris, men for s*tan ham ergoterapeuten gloede lidt på mig.

Just a story men - refactoring ?
Hvis man laver ordentlig kode i første omgang er der ikke brug for noget refactoring.

Just a story men - refactoring ? Hvis man laver _ordentlig_ kode i første omgang er der ikke brug for noget refactoring.

Ja, men jeg vil nu vove at påstå at enhver som påstår at lave ordentlig kode første gang hver gang enten mangler selverkendelse eller sidder med nogle lidt for trivielle opgaver.

Jeg er lidt uenig i PHK's version af Refactoring, men det skyldes nok der ikke er nogen formel definition. For mig er refactoring en lang raekke af smaa skridt der gradvist forbedrer et stykke kildekode fra l*rt til noget bedre. Det kan benyttes til at loese op paa visse kodebaser - men bestemt ikke alle.

Nogen gange er det langt bedre med nogle andre omgivelser: Gaature, A4-blokken + blyant i sofamiljoet etc. Men det kalder jeg personligt ikke refactorisering. Det handler som regel om at faa kildekoden til at have abstraktion, struktur og elegance. Det er da langt bedre at have en god ide foer man kaster sig over kodebasen. I ordentlige sprog med fornuftig styrke i typesystemet[1] handler det i hoej grad om at finde de rigtige typer til ens problem.

Refactorisering er bedst naar man har et stykke crap-kode som man ikke helt forstaar formaalet med, men man kan se er ustruktureret. Som ofte kan et antal mindre omskrivninger finde formaalet med koden. De fleste gange er man endda heldig nok til at den fremkomne kode har et acceptabelt hoejt niveau. Nogen gange gaar den plan dog i vasken. Og saa er der grobund for at tage taenkehatten paa og finde den rigtige loesning.

En anden ting: Vi mennesker udvikler meget forskelligt, naar vi programmerer. Jeg har en hypotese om at det er een af grundene til at vi har saa mange forskellige programmeringssprog. Derfor er det ikke helt utaenkeligt at hvad der virker for en person er komplet ubrugeligt for en anden. Alderen spiller formentlig ogsaa ind her. 20 minutter fra ny kode til at man har et testresultat aendrer ens arbejdsgange radikalt. Vi "unge" programmoerer er voldsomt utaalmodige hvis ikke vores program kan oversaettes paa et par sekunder.

[1] Det er saa hverken C, C++, Java, C#, Ruby, PHP eller Python vi snakker om her.

Sådan som jeg har forstået refactoring, så er det "bare", at man har noget software, og man ønsker ny funktionalitet, og refactoring er en måde at komme dertil i mindre trin, hvor man prøver at holde tiden hvori systemet er i en "ikke brugbar" tilstand nede.

Jeg har en professor, som mener, at refactoring kommer fra industriel produktion, hvor man ikke bare kunne stoppe hele produktionen, men ændrede funktionaliteten ved samlebåndet i mindre skridt, og til sidst fik, så det kunne håndtere ny produktlinje, uden at den gamle produktion undervejs var blevet stoppet ("re-factory-ing").

Man havde så bragt den analogi over i software-branchen til at implementere større projekter som mindre forbedringer.

I praksis kan det selvf. godt være noget med at slam-kode noget som virker, og derefter modificere koden til noget som er "korrekt" og også passer ind i den øvrige arkitektur, men jeg mener stadig det er grundlæggende anderledes end prototyping.

Hvad PH så spørger om er om man tager tiden til trin to med, eller nøjes med slam-koden? Personligt har jeg aldrig været med i nogen projekter der ikke kunne undvære mig i en halv time ad gangen, så det må være ja ;-)

Mvh,
Søren

Enhver moderne IDE har efterhånden værktøjer til refactoring, men det er kun simple syntaktiske transformationer, der understøttes, og faren herved er, at man aldrig får lavet de mere omfattende omskrivninger, der måske var det, der egentlig skulle have været gjort.

Og det betyder også, at (nogen) udviklere ikke tænker nok over deres refactoring: De anvender det samme sæt af standardtransformationer uden at tænke over deres ønskelighed. Bøger om refactoring hjælper heller ikke altid, da de ofte også tager den nemme vej: Små ændringer, der nemt kan argumenteres at have en gavnende effekt, men ikke de mere problemspecifikke transformationer, der kræver omtanke før brug.

Du spørger:
"Tager I kodekvalitet så seriøst, at I tør stå på retten til at gå en tur på en halv times tid, midt i arbejdstiden, for at tænke over koden ?"

Ja. Det er den eneste mulige måde at lave ordentlig software på.
Nogen gange er man nød til at starte noget kode op, for ligesom at komme i gang. Men går man i stå, eller ender i en blindgyde, så må der en pause til.
Sjovt nok er det ikke nødvendigt i lange perioder. Der kommer koden i takt med at kaffen gliderne. I andre perioder kan det hele gå lidt trægt. Om der er noget i kaffen i disse perioder er jeg ikke klar over.

God weekend.
Jesper

Sikkert ordkløveri, men

enhver som påstår at lave _ordentlig_ kode første gang

jeg skrev faktisk

i første omgang

'i første omgang' skal hér fortolkes som den 'første version' af færdig kode, ikke 'første kode'.

I øvrigt er jeg med på, at hvis man overtager slamkode, kan der være behov for refactoring, og i grelle tilfælde total omskrivning.

Stig: Din påstand bliver naturligvis mindre stærk hvis du definerer at refaktorisering før man er færdig med "første omgang" ikke tæller med. Men jeg synes stadig ikke den passer på min virkelighed.

For straks man er nået til din "i første omgang" sker der normalt det at nogen finder på at koden også skal bruges i en situation der ikke var tænkt på fra starten, og ville det ikke være smart hvis den liiige også kunne sådan og sådan?

Medmindre man har været meget synsk fra begyndelsen er der en pæn risiko for at designet ikke helt passer til den nye situation. Og så må man i gang med at skrive om, uanset hvor "ordentlig" koden "i første omgang" har været i forhold til de oprindelige krav.

Så simpelt er det, og der er forståelse for det. Det er også min oplevelse at det er sådan de fleste steder.
Det kan dog være at gåturen er noget andet(bordforbold osv.) men noget for lige at komme væk.
Mht. refactoring og IDE'er, så kan det godt være at menupunktet i Eclipse og co. hedder refactoring, men det er det altså ikke i min verden, refactoring skal mere gavne forståelsen for koden - gennem en ny/mere korrekt struktur end blot simpel omdøbning.
Det omvendte ser jeg mere som en kodeabe refleks reaktion, som i sidste ende ikke rigtigt hjælper nogen.
Lidt ved siden af, så snakker folk også så meget omkring kommentar i koden, jeg er ved at blive syg af at se linjer som:
// check if a equals b
if ( a == b )
{
tadadada();
}
Det er sådan noget man næsten bliver opdraget med på skolerne - men det er i mine øjne ubrugeligt, ham der har behov for sådanne kommentar vil med sikkerhed ikke forstå en lyd af ligevel.

Stig: Din påstand bliver naturligvis mindre stærk hvis du definerer at refaktorisering før man er færdig med "første omgang" ikke tæller med.

Det har du ret i.
Jeg vil dog indledningsvis påpege, at jeg ikke synes jeg fremfører en 'påstand', men blot erfaring fra det virkelige liv.

Når vi snakker refactoring skal vi også have referencerammerne på plads.

Du har helt ret i, at forskellige iterationer under et udviklingsforløb, vil jeg ikke kalde 'refactoring'.

I mit vokabularium associerer jeg refactoring med 'oprydning i gammel slamkode'.

Med mindre man har været meget synsk fra begyndelsen

Nu vil jeg ikke kalde mig synsk, men jeg er fra den tid hvor man lavede top-down analyse og bottom-up development.
Jeg plejer bare at kalde det foranalyse/detailanalyse og derefter spec's og udvikling.

En foranalyse/detailanalyse går ud på at dissekere forretningsgange, og evt. optimere dem, for derefter at lave brugbare EDB systemer.

Med andre ord - i min verden påbegynder man ikke een eneste kodelinie før man har komplet overblik over systemet (det færdige resultat).

Jeg kan kun tale for mig selv, det er ikke et forsøg på at være bedrevidende/påståelig.

Jeg er enig i, at hvis man betragter kodeænderinger under iterationsprocessen som refactoring, så er der brug for refactoring i det jeg kalder 'i første omgang'.

Jeg tror vi er enige, vi kalder blot tingene noget forskelligt.

Eclipse og co. hedder refactoring, men det er det altså ikke i min verden, refactoring skal mere gavne forståelsen for koden - gennem en ny/mere korrekt struktur end blot simpel omdøbning.

Jeg er enig i at det ikke er mikro-refaktorering som er interessant, men, lige når vi snakker Eclipse (og Java), så er det at flytte klasser til andre pakker også en slags strukturering der hjælper koden (visualiseret spatielt i Eclipse).

Derudover, begrænser refaktorering i Eclipse (og 'co' hvis man tænker IntelliJ) sig ikke til simpel omdøbning, men også f.eks. at introducere patterns i sin kode (factory og strategy af hvad jeg lige umiddeltbart kan genkende).

Men som sagt, mikro-refaktorering er nok ikke så interessant, men hvis man kender sit IDE's refaktorerings værktøjer, så kan det gøre det hurtigere til at rydde op i en del af "kodeabe" slam-koden :-)

Mvh,
Søren