Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: milos 01. 07. 2018, 12:04:57
-
Nazdar kluci a holky,
Chci slyset vas nazor, kdy je refaktorizace uz hodne? Proc se ptam? Pracuji ve firme uz nekolik let, kde nedavno ku nam nastoupil kolega a strasne ma potrebu neco refaktorovat. I celkem dost starej kod. My si to jako uvedomujem, ze nejaka ta refaktorizace by se hodila, jenomze nekdy nemame na to prostor. Podle me nedelame zly kod, taky si delame codereviews. A ten novy udelal asi pred mesicem takovy refaktor, tak to byla zmena cca. 60 fajlu. A nase nova funkcionalita mela cca 10 souboru, takze kdyz jsme s kolegama delali review, tak misto pulhodky, jsme zabili hodku a pul.
-
Tak pokud na to neni prostor, a ten protor na to neni proto, ze vas kod je na hovno (investice do budouci uspory casu), tak v ten moment je refaktorizace asi uz hodne, ne?
-
Pokud změnil za měsíc jen 60 souborů, tak je to docela OK. Někdo jich i za den udělá víc a to už pak problém. Podstatné je, že ses zmínil o kvantitě, ale nikoli o kvalitě. Právě kvalita rozhoduje o tom, zda to refaktorování má smysl nebo ne.
-
když se nezeptáš na konkrétní příklady refaktorizace, tak to IMHO na technický web nepatří.
-
když se nezeptáš na konkrétní příklady refaktorizace, tak to IMHO na technický web nepatří.
Technické disciplíny neznají kouzlo generalizace?
-
Nazdar kluci a holky,
Chci slyset vas nazor, kdy je refaktorizace uz hodne? Proc se ptam? Pracuji ve firme uz nekolik let, kde nedavno ku nam nastoupil kolega a strasne ma potrebu neco refaktorovat. I celkem dost starej kod. My si to jako uvedomujem, ze nejaka ta refaktorizace by se hodila, jenomze nekdy nemame na to prostor. Podle me nedelame zly kod, taky si delame codereviews. A ten novy udelal asi pred mesicem takovy refaktor, tak to byla zmena cca. 60 fajlu. A nase nova funkcionalita mela cca 10 souboru, takze kdyz jsme s kolegama delali review, tak misto pulhodky, jsme zabili hodku a pul.
V první řadě bych se vyvaroval nějakých hurá akcí. Ono jedna věc je opravit nějakou drobnost ve starém kódu, když už daný soubor edituji kvůli jinému úkolu, a jiná věc je rozsáhlejší refaktoring – ten už je potřeba dělat nějak řízeně a po domluvě s ostatními a s vedením projektu. Jak sám píšeš, je potřeba udělat revizi (což žere další čas). Tím to ale nekončí, dále je potřeba výsledek otestovat a ověřit, že nedošlo ke změně chování navenek. K tomu potřebuješ dobré automatické testy a/nebo dobrou dokumentaci a ruční testy. To stojí zase další čas a peníze.
Dokud to neprojde revizí a testy, tak refaktoring není hotový. A polovičatý refaktoring víc škodí než přináší. Pokud tedy nemáš kapacity/rozpočet i na ty revize a testy, tak je lepší nechat starý kód tak, jak je.
Za rozumný přístup považuji vyčlenit si nějaký paušální podíl času (% pracovní doby), který se věnuje údržbě kódu potažmo produktu – tzn. refaktoring, dopisování dokumentace, doplňování testů atd.
-
když se nezeptáš na konkrétní příklady refaktorizace, tak to IMHO na technický web nepatří.
Technické disciplíny neznají kouzlo generalizace?
diskuze směřuje k nadávání do lopat a hodnocení kódu, který nikdo neviděl. Anonym už začal.
-
A ten novy udelal asi pred mesicem takovy refaktor, tak to byla zmena cca. 60 fajlu.
Samotný počet souborů nic neříká. Stačí opravit gramatickou chybu v názvu hodně používané knihovní funkce a je to. Co přesně předělal?
-
Code review je skvělá věc, ale jak tu psali nademnou, bez testů to je stejně nejde.
-
Podle mého názoru, v červenci bude hodně horko a bude pršet jen občas.
-
Ja myslim, ze to muze byt dobry krok dat novemu seniornimu kolegovi
Za ukol refaktoring. Koukne se na to novyma ocima, neco zjisti o produktu a muzete pri code review dohodnout tohle ano, tohle uz ne.
-
Co funguje, to se neopravuje. :)
-
Jo, to moc dobře znám... tolik write-only sračkódu ve starém projektu, že jakákoliv i malá změna je utrpení a kvůli začarovanému kruhu s tím nikdo nemá čas něco dělat, takže se to už jen zhoršuje. Je to dokonce tak strašné, že to vidí i nováček, který zatím ještě má snahu a odhodlání to aspoň trochu napravit navzdory ošoupaným lopatám, které už ve firmě mají vlastní inventární číslo a těžce nesou, když jim kdokoliv sáhne na ty mnohaleté výplody, jež považují za vrchol geniality.
Já už jsem na projektu několik let, spoustu těch ošoupaných lopat se už povedlo odsud vyštípat nebo vyměnit a refactoring mě pořád ještě neomrzel, takže za chvíli ta aplikace snad už bude trochu k světu ;-)
-
Co funguje, to se neopravuje. :)
Definuj "funguje".
-
Co funguje, to se neopravuje. :)
Co se nedá lehce upravit moc nefunguje.
Co nemá testy nefunguje.
-
To ale nemusí moc vadit pokud to bude mikroservisa. Já bych definoval "funguje" tím, že to dělá co má a nemá to bezpečnostní bugy.
Často je ideální nechat to dožít a plynule přejít na něco zcela jiného - modernějšího.
Co funguje, to se neopravuje. :)
Co se nedá lehce upravit moc nefunguje.
Co nemá testy nefunguje.
-
Já už jsem na projektu několik let, ... refactoring mě pořád ještě neomrzel, takže za chvíli ta aplikace snad už bude trochu k světu ;-)
Klasika, nicméně po pár letech už člověk refaktoruje i svůj vlastní kód a kroutí hlavou, jak to mohl tehdy tak načunit. Je to řemeslo jako každé jiné, člověk se pořád učí...
Decentní kód je i podmínkou pro získání dobrých spolupracovníků, nikdo šikovný se nechce celý den brodit bahnem. Samozřejmě pokud je byznys typu "napras, do/prodej a zapomeň", pak opravdu platí, že se na funkční kód nesahá.
-
To ale nemusí moc vadit pokud to bude mikroservisa. Já bych definoval "funguje" tím, že to dělá co má a nemá to bezpečnostní bugy.
Často je ideální nechat to dožít a plynule přejít na něco zcela jiného - modernějšího.
Co funguje, to se neopravuje. :)
Co se nedá lehce upravit moc nefunguje.
Co nemá testy nefunguje.
tu microservisu testujete ručně?
-
Já už jsem na projektu několik let, ... refactoring mě pořád ještě neomrzel, takže za chvíli ta aplikace snad už bude trochu k světu ;-)
Klasika, nicméně po pár letech už člověk refaktoruje i svůj vlastní kód a kroutí hlavou, jak to mohl tehdy tak načunit. Je to řemeslo jako každé jiné, člověk se pořád učí...
Decentní kód je i podmínkou pro získání dobrých spolupracovníků, nikdo šikovný se nechce celý den brodit bahnem. Samozřejmě pokud je byznys typu "napras, do/prodej a zapomeň", pak opravdu platí, že se na funkční kód nesahá.
Psal jsem vlastni prispevek a server se zakuckal a prisel jsem o nej. Takze podepisuju Tvuj. Refaktorovat se ma, jak chces treba novackum vysvetlovat, ze nejake API je vylozene spatne ci prezite a ze musi delat hrozne voodoo, aby system rozsirili. Pritom po nich chces kvalitni vystup a oni kazdy den vidi ten binec okolo,
-
To ale nemusí moc vadit pokud to bude mikroservisa. Já bych definoval "funguje" tím, že to dělá co má a nemá to bezpečnostní bugy.
Často je ideální nechat to dožít a plynule přejít na něco zcela jiného - modernějšího.
Co funguje, to se neopravuje. :)
Co se nedá lehce upravit moc nefunguje.
Co nemá testy nefunguje.
Zasadni chyba. Prechod bude hodne bolet, protoze to stare ma v sobe zadratovane opravy chyb, ktere Vas pri "prepisu" nenapadnou a vzdy je potreba nejaka drobna uprava, takze budete reimplementovat "bezici cil" a vzdy, kdyz by byla vhodna doba "to" nahradit, tak tam bude neco chybet a odlozi se to a porad dokola.
Nejsem proti rewrite, ale je to risk, ktery nemusi vzdy vyjit, proto je lepsi postupna uprava existujiciho kodu.
Rewrite bych delal v pripade velkeho zasahu do architektury. e.g. immutable metadata, streaming misto vsechno nacti a pak s tim vsim neco udelej atd.
Vysledek rewrite muze byt taky ze budete myt na spravu projekty dva :), protoze se nekteri (obvykle ti nejlepe platici) zakaznici nehodlaji stareho kodu vzdat, protoze kolem toho udelali hromadu prace a konecne to po letech funguje k jejich spokojenosti :).
-
Když se živý projekt pořád průběžně aktualizuje/refaktoruje/čistí/upřesňují názvy/posouvají verze knihoven/atd., není důvod jej nechat a začít na zelené louce znovu. Naopak si myslím, že takových přepsání skončí úspěchem naprosté minimum. Když se netlačí pořád na kvalitu, bude předělávka úplně stejný humus, jako předchozí verze.
Naopak postupný refaktoring stávajícího projektu je daleko jednodušší, protože je po každé změně pořád funkční projekt. Samozřejmě to vyžaduje pořádné vývojové nástroje, které umožní mít kód pod kontrolou...
-
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
-
Pokud se jedna o nejaky vetsi refaktoring, tak to chce podlozit testy. Proc ne.
Jinak casem dojde k nejake chybe zpusobene refaktoringem.
Asi by to chtelo domluvit s kolegou, ze kvalita kodu se bude vylepsovat celkove.
Idealne to spojit i s pokrytim testy. A taky aby jste nedelali jen pak cely den merge.
Delal jsem neco podobnyho na projektech jako mladsi a neni to davno. Toto delaji i novacci. A je skoda o takovehoto cloveka prijit, pokud neni uplne mimo a neumi jen refaktorovat.
Pokud Vas kolega cisti kod (viz nejaky sonar) a jsou to bezpecne upravy, tak jej podporte.
Pluginy typu CodeCity asi znate. To Vam muze pomoci.
gf
-
A taky aby jste nedelali jen pak cely den merge.
Nejlepší je refaktorovat po malých (samozřejmě funkčních) částech a hned je pouštět dál, aby si ostatní mohli mergnout/rebasnout změny a nečekali až na veliký balík změn. Samozřejmě mluvím o projektech, kde to lze.
Stejně tak ten, kdo refaktoruje, musí často mergovat/rebasovat své nepushnuté commity, aby nedělal změny na starém kódu. Něco si syslit do šuplíku a neposouvat to s HEADem je nejlepší cesta, jak následně pracně (a draze) udělané změny zahodit. Ale to platí pro každý vývoj, nejen pro refaktorování/čištění, běžný denní chléb.
-
Přehnaně nadšené a notorické refaktoristy doporučuji aspoň tak na rok zařadit na pozici, kde bude rutinní součástí jejich práce backport oprav do různých verzí od nejnovějších po deset let staré a dohledávání, kde v historii došlo ke konkrétní změně. To by v tom byl čert, aby nezměnili pohled na to, jestli je bezpodmínečně nutné neustále něco učesávat a upravovat, aby to vypadalo víc cool.
-
Přehnaně nadšené a notorické refaktoristy doporučuji aspoň tak na rok zařadit na pozici, kde bude rutinní součástí jejich práce backport oprav do různých verzí od nejnovějších po deset let staré a dohledávání, kde v historii došlo ke konkrétní změně. To by v tom byl čert, aby nezměnili pohled na to, jestli je bezpodmínečně nutné neustále něco učesávat a upravovat, aby to vypadalo víc cool.
Az na to, ze ne kazdy software se udrzuje v mnoha historickych verzich. To si vzdycky muzes vybrat nejakou specifickou situaci a na ni skolit nekoho, kdo se pohybuje v jinych podminkach. *facepalm*
-
Deset let je možná extrém, ale jinak je ta "specifická situace" častější, než si myslíte. Ale pokud vám to umožní cítit se nadřazeně, facepalmujte si podle libosti.
-
Přehnaně nadšené a notorické refaktoristy doporučuji aspoň tak na rok zařadit na pozici, kde bude rutinní součástí jejich práce backport oprav do různých verzí od nejnovějších po deset let staré a dohledávání, kde v historii došlo ke konkrétní změně. To by v tom byl čert, aby nezměnili pohled na to, jestli je bezpodmínečně nutné neustále něco učesávat a upravovat, aby to vypadalo víc cool.
Prostě výpověď (nebo odchod ve zkušebce) a nazdar bazar...
Pokud má ten člověk alespoň minimální možnosti a ty nenabízíš pozlacený kosmodrom jako bonus, tak se s tebou dotyčný rozloučí a půjde někam, kde se dá pracovat.
-
Nazdar kluci a holky,
Chci slyset vas nazor, kdy je refaktorizace uz hodne? Proc se ptam? Pracuji ve firme uz nekolik let, kde nedavno ku nam nastoupil kolega a strasne ma potrebu neco refaktorovat. I celkem dost starej kod. My si to jako uvedomujem, ze nejaka ta refaktorizace by se hodila, jenomze nekdy nemame na to prostor. Podle me nedelame zly kod, taky si delame codereviews. A ten novy udelal asi pred mesicem takovy refaktor, tak to byla zmena cca. 60 fajlu. A nase nova funkcionalita mela cca 10 souboru, takze kdyz jsme s kolegama delali review, tak misto pulhodky, jsme zabili hodku a pul.
Myslím, že na to nemáš tak úplně správný pohled.
Množství refactoringu je spíše otázka ekonomická. Pokud si ji nemůžete dovolit, tak máte dost velký problém.
Pokud se domníváš, že neděláte zlý kód, tak je otázka, proč kolega chce refaktorovat? Protože se mu nelíbí váš styl? Protože refactoruje pro zábavu? Nebo je ve skutečnosti ten váš kód tak hroznej, že ten refactoring opravdu potřebuje?
A do třetice - vzhedeme k tomu, že vývojáři se účí, tak málokdy bude starý kód dostačující. Takže mě vůbec nepřekvapuje, pokud padesát procent času strávíte refaktoringem.
-
Přehnaně nadšené a notorické refaktoristy doporučuji aspoň tak na rok zařadit na pozici, kde bude rutinní součástí jejich práce backport oprav do různých verzí od nejnovějších po deset let staré a dohledávání, kde v historii došlo ke konkrétní změně. To by v tom byl čert, aby nezměnili pohled na to, jestli je bezpodmínečně nutné neustále něco učesávat a upravovat, aby to vypadalo víc cool.
Již jsme se tu o tom bavili. Vždy je to přece o možnostech projektu. Projekt s backporty do 10 let starého kódu (např. LTS kernel) je úplně jiný než projekt, který provozuje firma sama a jen v jedné verzi (náš případ, ale takových je spoustu, typicky webové projekty). Proto vždy uvádím "pokud to projekt umožňuje".
Vůbec nejde o "cool" vzhled, ale o bezpečné a pohodlné provádění změn do dalších verzí. Když si každý featuru naprogramuje po svém, máš po pár letech 5 různých variant a žádná není pořádně. Při šestém požadavku je daleko smysluplnější sednout a tři dny to čistit, sjednotit/zredukovat do jedné pořádně funkční a aktuální, než tam zase copy/paste naládovat šestou verzi. To není nic notorického, ale normální rozum.
Požadavky na změny jsou každodenní realitou spousty firem/projektů. A opravdu ne všichni vyvíjejí kernel.
-
Pokud má ten člověk alespoň minimální možnosti a ty nenabízíš pozlacený kosmodrom jako bonus, tak se s tebou dotyčný rozloučí a půjde někam, kde se dá pracovat.
Jednak jsem (naivně, jak vidím) doufal, že bude zřejmé, že jde o nadsázku, jednak pokud by někdo opravdu ihned po příchodu trval na tom, že se musí bezpodmínečně překopat podle jeho představ projekt, který už nějakou dobu běží a na kterém pracují další vývojáři, aby "se dalo pracovat", pak by asi musel být sám pozlacený. Ona je spousta lidí, kteří jsou přesvědčeni o své genialitě (a někdy, i když zřídka, třeba i právem), ale pracovat s nimi na společném projektu je za trest.
-
Již jsme se tu o tom bavili. Vždy je to přece o možnostech projektu. Projekt s backporty do 10 let starého kódu (např. LTS kernel) je úplně jiný než projekt, který provozuje firma sama a jen v jedné verzi (náš případ, ale takových je spoustu, typicky webové projekty). Proto vždy uvádím "pokud to projekt umožňuje".
Jednak jsem už psal, že 10 let je extrém (i když někdy to je v praxi ještě víc, a nejde jen o jádro, kde navíc velkou část upstreamových vývojářů starší verze také nezajímají), ale i u projektu, který nepotřebuje udržovat starší stable verze, je potřeba se každou chvíli podívat do historie, kde se ta či ona konstrukce vlastně vzala a proč (a ne, nejde to mít všechno v komentářích).
Vůbec nechci tvrdit, že refactoring je a priori špatně. Ale když tu vidím některé nadšené komentáře, jak je potřeba přepisovat průběžně, často a radostně, tak mi z toho trochu běhá mráz po zádech a vyprovokovalo mne to napsat podobně přehnaný příspěvek z druhé strany. Ono těch projektů, kde maintenance je výrazně méně než práce na nové funkcionalitě, nakonec až tak moc není a některým lidem by opravdu prospělo, kdyby si mohli na čas vyzkoušet odvrácenou stranu toho, co jim připadá tak skvělé a žádoucí. Takže než se člověk do něčeho takového pustí, měl by si sakra dobře rozmyslet, jestli jsou důvody dostatečně vážné (tj. ne jen "kdybych to psal dneska, udělal bych to jinak") a jestli přínos dostatečně převáží problémy, které tím způsobí.
Když si každý featuru naprogramuje po svém, máš po pár letech 5 různých variant a žádná není pořádně. Při šestém požadavku je daleko smysluplnější sednout a tři dny to čistit, sjednotit/zredukovat do jedné pořádně funkční a aktuální, než tam zase copy/paste naládovat šestou verzi. To není nic notorického, ale normální rozum.
Vidíte, mně třeba přijde, že "normální rozum" velí nenechat to dojít takhle daleko. Při nejlepší vůli se může stát, že se tam objeví dvě skoro stejné verze téhož a pak je většinou opravdu na místě to napravit (čím dříve tím lépe). Ale pět? To už IMHO signalizuje vážné problémy v komunikaci nebo absenci review (dost možná oboje).
-
Deset let je možná extrém, ale jinak je ta "specifická situace" častější, než si myslíte. Ale pokud vám to umožní cítit se nadřazeně, facepalmujte si podle libosti.
Na pocity nadrazenosti nehraju, reagoval jsem na konkretni prispevek, jehoz dikce se mi nelibila. Nejsme ve sporu, pokud se tyka situaci, kde refaktorizace udela vic skody nez uzitku. Vyhodnost a nevyhodnost musi urcit spravce produktu.
-
Již jsme se tu o tom bavili. Vždy je to přece o možnostech projektu. Projekt s backporty do 10 let starého kódu (např. LTS kernel) je úplně jiný než projekt, který provozuje firma sama a jen v jedné verzi (náš případ, ale takových je spoustu, typicky webové projekty). Proto vždy uvádím "pokud to projekt umožňuje".
Jednak jsem už psal, že 10 let je extrém (i když někdy to je v praxi ještě víc, a nejde jen o jádro, kde navíc velkou část upstreamových vývojářů starší verze také nezajímají), ale i u projektu, který nepotřebuje udržovat starší stable verze, je potřeba se každou chvíli podívat do historie, kde se ta či ona konstrukce vlastně vzala a proč (a ne, nejde to mít všechno v komentářích).
Vůbec nechci tvrdit, že refactoring je a priori špatně. Ale když tu vidím některé nadšené komentáře, jak je potřeba přepisovat průběžně, často a radostně, tak mi z toho trochu běhá mráz po zádech a vyprovokovalo mne to napsat podobně přehnaný příspěvek z druhé strany. Ono těch projektů, kde maintenance je výrazně méně než práce na nové funkcionalitě, nakonec až tak moc není a některým lidem by opravdu prospělo, kdyby si mohli na čas vyzkoušet odvrácenou stranu toho, co jim připadá tak skvělé a žádoucí. Takže než se člověk do něčeho takového pustí, měl by si sakra dobře rozmyslet, jestli jsou důvody dostatečně vážné (tj. ne jen "kdybych to psal dneska, udělal bych to jinak") a jestli přínos dostatečně převáží problémy, které tím způsobí.
Když si každý featuru naprogramuje po svém, máš po pár letech 5 různých variant a žádná není pořádně. Při šestém požadavku je daleko smysluplnější sednout a tři dny to čistit, sjednotit/zredukovat do jedné pořádně funkční a aktuální, než tam zase copy/paste naládovat šestou verzi. To není nic notorického, ale normální rozum.
Vidíte, mně třeba přijde, že "normální rozum" velí nenechat to dojít takhle daleko. Při nejlepší vůli se může stát, že se tam objeví dvě skoro stejné verze téhož a pak je většinou opravdu na místě to napravit (čím dříve tím lépe). Ale pět? To už IMHO signalizuje vážné problémy v komunikaci nebo absenci review (dost možná oboje).
Podílím se poměrně často na vývoji softwaru s historií 10+ let, není to nic neobvyklého a zcela chápu ty argumenty, že refaktoring brání portování změn do starších verzí. Ale je otázka, kde si nastavit tu hranici. Přijde mi přehnané očekávání, že udělám třeba git merge nebo git cherry-pick z aktuální větve do té deset let staré a ono si to na sebe sedne. Teoreticky by to šlo, ale za cenu toho, že se ten software bude měnit extrémně konzervativně – a tím budou trpět aktuální verze. Nepřijde mi rozumné obětovat kvůli historickým verzím a snadnému portování zájmy současných uživatelů. Možné to bude jen u softwaru, který byl víceméně hotový už před těmi deseti lety a už není moc kam ho posunout a všichni chtějí, aby fungoval pořád stejně. Tam tenhle přístup aplikovat půjde. Ve většině případů mi ale přijde rozumnější si nechat možnost hladkého/automatického portování změn jen pro 1-2 roky staré verze nebo poslední major verze – a do těch starších ty změny (opravy) portovat ručně. Tím je možné dělat refaktoring, upravit návrh, aby odpovídal aktuálním požadavkům, přejít na novější/jiné knihovny atd. Prostě udržovat software ve formě, tak, aby odpovídal aktuálnímu letopočtu a aktuálním požadavkům a nebyl to jen historický artefakt, který se oprašuje a raději se na něj moc nesahá.
-
Refaktoring v ramci urcitych mezi je fajn. Ne to delat porad, nebo kdyz delame novou funkcionalitu, tak si poznacime, ze tohle musime predelat tak ci tak, jenom aby to boli lepsi, ikdyz to funguje. Takze takhle si pridavame jenom robotu
-
Pochybuju, že by někdo dobrovolně platil předělání rozumného fungujícího kódu jen tak pro zábavu.
Předělává se to proto, aby to šlo lépe používat v budoucnu, aby se z konkrétního kódu vytáhly obecné části (typově obvykle přes rozhraní), které se doplní/opraví/urychlí a následně využijí i jinde. Obvykle v okamžiku, kdy je něco v dané oblasti potřeba upravit/přidat a zjistí se, že se podobná věc během dosavadních let projektu řešila na více místech různě. To není nic neobvyklého, jsem přesvědčený, že takové věci jsou ve všech časově i objemově rozsáhlejších projektech.
-
Přínos zásahu do zdrojáku musí převážit nad možnými riziky - zanesením nové chyby. Jestli je kolega akční, tak ať se hrabe jen v tom, co je živé - kde se s kódem bude dále aktivně pracovat.