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