Refactoring - (Extract Method)

- Att skriva kod som en maskin kan förstå kan nästan vem som helst göra, men att skriva kod som en människa kan förstå är inte alls lika lätt får många.

Diskutera gärna ämnet här. Läs min krönika för mer info.
Mvh Johan

tänkte bara lämna en länk till en vs.net addin som jag själv kör med.

http://www.jetbrains.com/resharper/

mycket trevlig addin , även om den bara är beta än så länge.
den har stöd för extract method och renaming av klasser,metoder osv.


//Roger

Verkar jättespännande, men det var inte lätt att få ett inloggningsnamn.

För er som inte har hunnit ta en titt på VS 2005, så ingår refactoring i VS 2005. Den påminner mycket av resharper. En publik Beta 1 av VS 2005 kommer förhoppningsvis ut under Juli månad.

/Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog

Verkar intressant, vet någon när 2005 kommer ut som fullverision?

// Micke

Troligtvis slutet av våren 2005.

/Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog

Ett litet tips om en mycket enkel "refactoring":

<code>
public static bool IsNullOrEmpty(string val)
{
if(val == null || val.Length == 0)
return true;
else
return false;
}
</code>
kan kortare skrivas
<code>
public static bool IsNullOrEmpty(string val)
{
return (val == null || val.Length == 0);
}
</code>

Absolut. Om du syftar på att min kod inte hade så i exemplet så beror det på att jag inte ville
rafatorera koden för mycket för dem som inte är vana vid det. Tack för att du tog upp det här o nu, tror det kom passande. Det finns massa små knep som kan göra kod ännu snyggare. Men det skulle ta upp en hel bok om man skulle gå genom dem alla :-) Håller just nu på att skriva en artikel till min blog om att ändra Case till classer. Publiceras väldigt snart.

Mvh Johan

När det gäller testet av om användarnamnet och lösenorden är på rätt format, skulle det kunna bli ännu smidigare genom att ha en konstruktor User som kastar undantag:
<code>
User user = User("Pelle", "987654"); // Kastar undantag vid felaktigt anv.namn eller lösenord
Membership.CreateUser(user);

Membership.CreateUser(User("Lasse", "123456"));
</code>


Ett annat exempel där jag nyligen prövat detta - snitt av rektanglar:
<code>
class Rectangle {
private:
int left, top;
int width, height;

public:
class NoRectangle : public Exception {
...
};

public:
Rectangle(int l, int t, int w, int h) : left(l), top(t), width(w), height(h) {
if(w<0 || h<0)
throw NoRectangle();
}

Rectangle operator & (Rectangle r) {
int resLeft = max(left, r.left);
int resTop = max(top, r.top);
int resRight = min(left+width, r.left+r.width);
int resBottom = min(top+height, r.top+r.height);

return Rectangle(resLeft, resTop, resRight-resLeft, resBottom-resTop);
}
};
</code>
Om nu de två rektanglarna (operander till &) inte överlappar, så blir den resulterande rektangelns bredd eller höjd negativ och ett undantag kastas.

Och för er som har arbetat i andra miljöer än Microsoft, t ex Java, så vet ni att refaktorering via IDE:er har varit möjligt sedan låååångt tillbaka :)

Jepp.... Men då MS miljöer inte vart så OO baserade har Refactoring inte direkt gett jätte mycket, eftersom tanke banan var funktions orineterade med MASSOR av rader kod / Funktion. Funktions orintering är ju att tänka som en dator...

Mvh Johan

Nils,

Kan nog tillägga att refactoring visst har funnits i VS.NET sen en god tid tillbaka, men då i form av tredjeparts tillägg :P

<b>Funktions orintering är ju att tänka som en dator...</b>
Tänker verkligen en dator och i så fall hur?

"Funktions orientering är att tänka som en datar!" är en klassisk liknelse för att beskriva en metafor av funktionsorienterade sättet. Man tänker i processer typ. Medans OO är mer hur verkligheten fungerar, man tänker i objekt.

Mvh Johan

Men refactoring är inte ett sätt som endast fungerar i oo språk. refactoring är bara ett namn på en metod för att omarbeta kod så den blir effektivare, renare, lättare att förstå. Har flera kompisar som jobbat med vb, pl/sql och ada som nyttjar refactoring. (känns väldigt mycket som kejsarens nya kläder)

Men en intressant artikel

Jepp. Men tack vare OOP blir det ännu snyggare och effektivare.
Men Sql? hum... Refactorign är ingen metod. det är oftast en fas i Utvemodeller. Dock finns det olika metoder man kan nyttja innom refactoring. Om man skall vara lite petig.
Är det något mera du vill läsa om eller att jag skriver om? Lite svårt att veta vilken nivå man skall lägga sig på m.m.
Tack!

Mvh Johan

Hmm.. De som jobbar med pl/sql är inte så förtjusta i OO-tänket vad jag förstått, så om det blir snyggare för dem vet jag inte ;). . (btw, pl/sql är inte sql).

Sen håller jag inte riktig med dig om att refactoring enbart skall ses som en fas i en utvecklingsmodell. Jag kan tex sitta å jobba med min modul och sen så ser jag en kodsnutt som jag anser att jag behöver skriva om, eller något som stör mig då använder jag refactoring, men inte har projektet gått in en ny fas för det.

Sen skulle man mycket väl kunna lägga in det som en fas i ett projekt, men jag ser det mer som ett namn på en metod/teknik för att förbättra kod, oavsett vad det är för kod, jag använder refactoring när jag skriver i word också :). Att sedan Fowler satt namn på de vanligaste refactoringprinciper är ju kanon, för då kan man förhoppningsvis använda samma namn på de olika metoderna, vilket förenklar.

Vad exakt menar du med pl/sql

fas o fas. ok, fel ord. Jag menar tyå så här. koda, testa, refatorera, testa - klart. Tre olika faser, kanske finns bättre namn på det? När man sedan kansk ebyggt en itteration kan man även dörefter köra refacotring i högra nivå, där man flyttar metoder mellan klasser etc... Ja du vet så jag behöver ju inte gå in på det.

Det är ju inte Folwler ensam som tagit fram namnen på de olika refactoring metoderna, men det är som du säger bra att han satte ett namn på dem så man kan hänvisa till de olika. Det jag tycker är effektivare under OOP är mer det polyforma stödet som du inte finner i icke OO språk.

Mvh Johan

http://otn.oracle.com/tech/pl_sql/index.html
http://searchdatabase.techtarget.com/sDefinition/0,,sid13_gci535052,00.html

fas är nog ett bra ord.. Men man menar kanske olika saker när man skriver/läser det.. Bra att fowler skrev den där boken så att man har samma tänk när man refererar till ett ord :)

pl/sql är oracles implementation av ISO SQL standarden, precis som T-SQL är Microsofts implementation

OT
grattis till din mvp, Patrik.

Har inte sett det förrän på nu..

grr nu försvann mitt inlägg.. gör en kort lista istället på saker som jag tror skulle vara intressant att läsa

*utvecklingsmetoder, ytligt om vad det finns för några metoder och hur de fungerar. kanske referenser där man kan läsa mer.
*tips på hur man skriver kravspecar. och varför.
*hur fångar man kraven från kunden? Tips på intervjuer. gärna reflektioner från egna upplevelser.
*modellering av affärsprocesser. kanske mha UML
*testning, dock inte unittests finns redan mycket om detta, dock inte på svenska.
*hur hittar man sina objekt i sin problemdomän.
*hur upptäcker man att man inte gjort rätt i OOP. (finns det rätt å fel?) Kanske ta en bit kod på nätet som du ser några problem med och sen så skriver du runt detta. om vad som du tycker är fel och hur du tycker man skall förbättra det.
*begrepp inom OOP, coupling, cohesion osv.. tips och tankar om när man inte fått en bra objektmodell.
*O/R-mapper. hur fungerar de, vad är deras starka sidor, svaga sidor.

Vet inte om det var i denna tråden eller någon annan. Men det dök upp problem om hur man motiverar sin chef att satsa på utbildning. Ett exempel från verkligheten hade varit intressant å läsa. Vad skall man eftersträva och vad skall man se upp med, hur kan man visa att en utbildning lönar sig... osv..


En del av dessa ämnen kanske det finns artiklar om redan och det kanske är ganska stora ämnen. Och en del av förslagen är inte så tekniska, men utveckling och programmering är inte alltid tekniskt.
Om du är osäker på nivån så kanske det kan fungera å skriva en hel serie av artiklar. En som börjar på en lägsta nivå å blir det mer och mer avancerat.


Hoppas där är något ämne som du tycker verkar intressant.

Tack Walle *S*

Blev klart i torsdags, så har inte haft den så länge ...

Walle,

Hej, Allt det du tog upp är intressant. Men svårt att tecka. Det är svårt att prata lätt om saker som då ger kunskap i hur man använder det. Kan nog bli lätt att man tänker aha men jag förstår inte allt så det låter bra men är nog inget för mig.

O/R Mapping är ett intressant ämne. OOP samma. Jag kommer nog skriva mer om tekniska saker än teoretiska men skall nog försöka refferera mera och kanske förklara kort vad olika saker är.
Om jag var en duktik skribent hade jag faktiskt velat skriva en bok om allt det du tog upp, kanske själv eller med andra. Men tyvärr är skriva min svaga sida. Men försöker så gott det går.

Hitta objekt är intressant, det kan man skriva om. Fast då måste man utgå från att man redan förstår objekt tänkandet och inte det funktionstänkande man hela tiden haft med sig från MS tidigare utvecklingsverktyg. Svårt att skriva hur man vänder ett tankesätt :-( Haf försökt förklara för många men inte lyckats. Det är lättare att tänka som en dator än att se systemet mer objektivt eller vad man skall säga.

Objektmodell är intresant. Men frågan är om det finns ett bra svar på det? När än sådan är bra?
Arkitektur och design är ju som olika dialekter och religioner. Dock kan man ju skriva hur man själv anser en bra objektmodell bör se ut. Sånt är ju levande då man får mer o mer erfarenheter.

Tycker som sagt du tar upp väldigt bra ämmen, Har man föståelse över dem alla så lovar jag att man kan komma långt. Jag har själv inte svaren på allt. Specielt den biten med hur man får sin chef att förstå olika saker o ting, ex kan en utbildning vara lönsam för företaget? eller är det slöseri med pengar? Hur får man en chef att lockas av nya idéer eller nya tankar ang att effektivisera organisationen etc?

Måste sova nu. Ha det... Tack igen.
Har du messneger? Adda mig gärna: johan.normen@home.se alltid kul att snacka om olika saker innom vår utv värld. Dela tankar, åsikter m.m.

Sov gott.
Mvh Johan

Jag är inte alls insatt i .net, så det får ni ha överseende med.
Tänkte bara fråga om det här "refactoring". Har hört det flera gånger och stundom tänkt att det bara är ett buzzword, och annars att det säkert är jättebra men inte för det jag håller på med.

Efter att ha läst krönikan så är jag lite förbryllad. Refactoring är då alltså att man "snyggar upp kod" för att den ska bli lättare att läsa?
Och en av dessa uppsnyggningar är "extract-metoden"?
Och extract-metoden går ut på att man letar reda på ofta använda, logisk sammankopplade bitar kod, och placerar dem i en separat metod, t.ex.

Har jag uppfattat det korrekt?

För i så fall så har jag alltid ägnat mig åt refactoring, under hela utvecklingsprocessen, helt naturligt. Behöver man verkligen ett ord för att säga "snygga upp koden", och behöver man verkligen prata om olika metoder för det?

Hej, du har greppat det ganska rätt.
Det finns olika metoder under refactoring extract method är en.
Refactoring ger ju snyggare kod, men även en hel del andra fördelar. Jag anser väl att det inte driekt finns en föklaring så som "snyggar upp kod" utan flera.

Man strukturerar helt enklet om sin kod för en del ändamål.

Mvh Johan

Men är det verkligen så speciellt att man behöver prata om det som ett eget begrepp?
Naturligtvis förstår jag att det ger fördelar som att koden blir lättare att underhålla, osv., men fortfarande är ju själva processen så naturlig att jag inte förstår syftet med att beskriva den så.

För min del skulle det kännas krångligare om någon började prata om att han/hon hade använt "den och den" metoden för att förbättra koden.

Niklas,

Det är snarare så att om du hade kunskap om vad "den och den" metoden innebär (vilka regler och principer de följer) så skulle du enklare kunna förstå vad personen i fråga har gjort med sin kod.

Okej, så refactoring är snarare en katalog med olika typer av "koduppsnyggningar" som man kan använda för att systematiskt förbättra koden, och beskriva det. Läste lite på internet också, och det verkar ju nästan vara så.

Det låter lite rimligare i så fall, och inte helt dumt.

Hur gör man om man redan skriver bra kod då?
Om man under kodskrivandet förutser hur det kommer fungera, och snabbt skriver ihop små kodklumpar som man redan från början har delat upp.

Ska man beskriva det på det sättet i efterhand eller är det bara för förändringar?

Niklas,

Om man har sånn järnkontroll på koden från förjan så refactorar man juh per automatik. Oftast är bilden i huvudet / på papper tydlig när man börjar men förändras under projketets gång, kanske för att kundens krav ändras eller någon annan teknisk/tidsförutsättning förändras.. då blir koden inte alltid som man vill och som man vet att man borde göra.

Niklas:

Refactoring brukar i stort sett användas för att förbättra befintilig kod. Du kan läsa mer om refactoring på http://www.refactoring.com, där har du även en katalog över alla olika refactorings.

/Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog

Okej, då är det egentligen inget för mig just nu. De applikationerna jag skriver har jag så god koll på att jag vet vad jag ska göra, även efter några år. Dessutom är i stort sett inga av de programmen jag skriver objektorienterade.

Kan väl vara intressant med någon artikel då och då, men jag kommer nog inte bry mig nämnvärt på ett ganska bra tag. Bra att veta vad det är iaf.

För att lägga till lite mer information om refactoring

När ska refactoring användas.

1) När du lägger till en ny funktion.

Om en anna person har srivit koden som du ska lägga till en ny feature, så kan det
vara bra att göra en refactoring på befintlig kod om det går, för att "snygga" upp koden
samt för att du själv ska skapa en bild av vad koden gör.

2) När du behöver fixa en bugg.

Igentligen samma sak som punkt 1, se till att göra en refactoring när en bug ska fixas,
det kan undelätta dig att förstå koden (om någon annan har skrivit den). Refactorign kan (OBS behöver inte) se till så det blir lättare att hitta buggar.

3) När du kodgranskar.

När du granskar en annans person kod, se vad som kan göra bättre. Kod review är ett bra
sätt att sprida kunskap inom en organisation.

Behöver du berätta för din "ledare" att du lägger tid på refactoring när du ska tex fixa en bug

Säg inget, gör det bara ;) Om din "ledare" tycker att kvalitet är vikitgt (vilket man tycker att alla borde vara men så är det inte) så är refactoring ett perfekt "verktyg" för att öka kvalitén.
Ofta har vi alla en tidspress som kan leda till att vi måste fixa en bugg så fort som möjligt. Utveckalre är professionalla, vårt jobb är att bygga effektiva lösnignar. Det är vår ensak om vi anser att vi behöver använda oss av refactoring eller inte för att klara av vårt arbete, speciellt för att förstå en annan persons kod och för att lättare kunna hitta buggar vi ska fixa.

När ska du "använda" dig av refactoring när du utvecklar.

Tre regeln:

Först när du gör något, gör det bara, andra gången du gör något liknande även om det innebär duplicering av kod, strunta i det, gör dupliceringen, tredje gången du gör något liknande så "använder" du refactoring.

När du är en erfaren porgammerar så tänker du automatiskt på refactoring när du skriver kod, så ibland kan det hända att du aldrig behöver "använda" refactoring, för att koden är redan så bra den går att få.

/Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog

<b>>När du är en erfaren porgammerar så tänker du automatiskt på refactoring när du skriver kod, så ibland kan det hända att du aldrig behöver "använda" refactoring, för att koden är redan så bra den går att få. </b>
Så värst erfaren kanske jag inte är; bara jobbat med programmering på konsultbasis i 4-5 år, men det främst typen av uppgifter som gör så att jag inte har något behov av det.

Lösningar som jag tillhandahåller är till för att lösa ett specifikt behov, och kan oftast inte göras generella, och i stort sett aldrig objektorienterade. Dessutom är det relativt sällan jag delar kod med andra.
Om jag sen skriver koden logiskt och vettigt uppdelad så kommer det nästan aldrig behov av att skriva om koden, och i så fall bytar jag bara ut den modulärt.

Sålunda är refactoring ganska onödigt för mig. Har dock ändrat uppfattning om hela grejen under dagen.

Fast själva principerna borde väl vara uppenbara för de flesta; refactoring borde väl handla om att sätta namn på metoderna och ange lämplig ordning, etc., snarare än att förklara metoderna?

Johan här, vaknade precis.

Refactoring är något du gör, så fort du bara strukturerar om din kod så ut för du refactoring. Byta namn på en metod, flytta en metod, splittra en metod till flera små etc...
Man har satt ett namn på detta för att kunna kommunicera med varandra. Ex när en hårddisk är rörig med en massa framgment ber du din kompis att defragmentera den, genast fattar han vad du menar. Skulle du säga, ja din hårdsik ser rörig ut, rör ordning den så kanske han inte direkt förstår vad du menar. Refactoring kan ses som en struktur renare. Man strukurerar om sin kod till något bättre, resultatet blir, mer självbeskrivande kod, mättre struktur och ökad återanvändning av metoder, färre redundans i koden etc...

Lasse tar och gör en review av din kod och skriver ner på ett papper följande.
Du har en metod här med en rad parametrar jag tycker du skall ta och göra en "ersättning av parametrar till data klass" ("replace parameter with data class") iställte. Metoden DoStuff() bör du göra ett namn byte av. ("Rename method") Du har en if sats här med likasinade kontroller det enda som skiljer dess interna kontroll är namn på en variabel och ett värde., här kan du göra en metod extrahering ("Extract Method") istället. Du har en metod som heter ChangePassword() i klassen User, men du har även en klass Password. Flytta all logik från ChangePassword till Password och från ChangePassword() ropar du på Password.Change(..) gör en extrahering av denna metods ("extract method") logik till Change(...) sedan gör du en metod förflyttning ("Move method") av Change(...) till din Password klass. etc...

Så namnen finns för att kommunikationen skall underlättas. Strukturering (Refactoring) finns för att göra koden mer överskådlig, minimera antalet buggar genom bland annat nedbrytandet av redudant data. Göra koden mer självbeskrivande och logisk...

Om du fortfarande har frågor och är lite osäker tycker jag du skall kolla in www.refactoring.com eller köpa någon bok ang ämnet.

"What is Refactoring?
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring."

mvh Johan


Mvh Johan

För er som är intreserade av "Extract Method" och andra refoctorings så finns nu en artikel om hur ni kan göra refactoring med hjälp av VS 2005 (Nästa version av Visual Studio):

http://msdn.microsoft.com/vcsharp/default.aspx?pull=/library/en-us/dnvs05/html/vs05_refac.asp

/Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog