Kdy je refaktorizace už hodně?

[Jan Forman]

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.

[Reklama]

[dustin]

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á.

[gll]

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ě?

[Inkvizitor]

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,

[zdenek henek nereg.]

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 .

[Reklama]

[dustin]

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...

[Ondra Satai Nekola]

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[Pavel.Kysilka]

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

[dustin]

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.

[Michal Kubeček]

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.

[Inkvizitor]

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*

[Michal Kubeček]

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.

[Ondra Satai Nekola]

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.

[BoneFlute]

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.

[dustin]

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.