Kdy je refaktorizace už hodně?

Re:Kdy je refaktorizace uz hodne?
« Odpověď #30 kdy: 04. 07. 2018, 21:47:18 »
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.


Re:Kdy je refaktorizace uz hodne?
« Odpověď #31 kdy: 04. 07. 2018, 22:13:33 »
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í.
Citace
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).

Inkvizitor

Re:Kdy je refaktorizace uz hodne?
« Odpověď #32 kdy: 05. 07. 2018, 10:44:03 »
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.

Franta <xkucf03/>

Re:Kdy je refaktorizace uz hodne?
« Odpověď #33 kdy: 05. 07. 2018, 12:46:47 »
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í.
Citace
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á.

mikino

Re:Kdy je refaktorizace uz hodne?
« Odpověď #34 kdy: 05. 07. 2018, 13:17:49 »
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


dustin

Re:Kdy je refaktorizace uz hodne?
« Odpověď #35 kdy: 05. 07. 2018, 13:53:56 »
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.

Jarda Kuba

Re:Kdy je refaktorizace uz hodne?
« Odpověď #36 kdy: 05. 07. 2018, 23:43:23 »
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.