Tak ostatnio refaktoryzowałem jedną klase w systemie przy którym pracuje i naszła mnie tak refleksja czy to w ogóle ma sens. Projekt ma 400k linijek kodu i jest w całości beznadziejnie napisany (nieobiektowo, funkcje mają mase efektów ubocznych więc trudno się refaktoryzuje itp). Jak poprawie 300 linijek w projekcie to i tak wiele się nie zmieni bo 399700 linijek będzie zwalonych więc to mi się wydaje syzyfową pracą. A czy wy staracie się refaktoryzować kod w Waszych projektach?
0
0
rnd napisał(a)
A czy wy staracie się refaktoryzować kod w Waszych projektach?
Tak. Do tego czesto bywa tak ze zanim jakas klasa osiagnie porzadany ksztalt jest refaktoryzowana wielokrotnie. Czesto zdarza sie ze refaktoryzowane sa cale grupy klas np. po to zeby zmienic jakas koncepcje w architekturze.
0
niestety nie ma na to czasu, a nawet jak sie wygrzebie troche w ciagu dnia to i tak nikt tego nie zauwazy - ewentualnie zauwazy i opierniczy ze cos trzeba teraz pisac inaczej niz dotychczas... stary kod kłuje w oczy, zedytowanie czegokolwiek wymaga przegladania mega duzej ilosci kodu...ale co poradzic?
0
Jak wpomniales syzyfowa praca, ale tak. Idzie bardzo wolno (wynik zlych podjetych dzialan na poczatku, naglych - szybkich zmian by przypodobac sie klientowie ...). Jednak powoli pojawiaja sie wysepki gdzie dodanie czegos nowego jest banalne ... a zatem warto (ale to czas ...... czasami lata)
0
Ja jestem zdecydowanym zwolennikiem refaktoryzacji. Gdy mam UnitTesty jest to niemal czystą przyjemnością. Refaktoryzacja jest jak spłacanie długu: możesz mieć 400k zł długu i spłacać co miesiąc 300zł, albo nie spłacać nic i czekać aż odsetki (bugi i koszty dodania nowej funkcjonalności) was zjedzą.
0
A ja nie jestem w 100% za refaktoryzacją.... tylko w 200%!
Zauważ proszę, że gdyby ci kolesie, po których dostałeś kod w spadku robili regularnie refaktoryzację, to nie miałbyś problemu z ich kodem w pierwszej kolejności! Refaktoryzacja najlepiej się sprawdza, gdy dotyczy Twojego kodu. Jeszcze w miarę świeżego. Napisz moduł. Użyj go. Zobacz, czy wygodnie się go używa, czy może jednak używasz go inaczej, niż z początku planowałeś. Może przyda się zrobić inny, wygodniejszy interfejs? Jeśli tak, to to zrób. To nie jest taki ból, gdy dotyczy kodu, który powstał tydzień (czy nawet kilka tygodni) temu, a nie był zrobiony parę lat temu przez inną ekipę.
Nawet jednak gdy masz do czynienia z -- nie ma co używać ładnych słów -- ch#@%^ kodem, to i tak może się okazać, że refaktoryzacja się opłaci. Ja nie cierpię babrania się w takim kodzie. Po czymś takim niemal czuję się brudny. Praca z takim kodem jest o wiele mniej wydajna, niż być powinna. Wszystko robisz nie tyle 2x dłużej, co wręcz 5x dłużej. Koszmar!
Jeśli masz nad tym kodem pracować przez kolejny rok, czy dwa, to kto wie czy nie opłacałoby się poświęcić PÓŁ ROKU (!) na refaktoryzacją. Może wtedy koniec końców miałbyś większą wydajność.
Ja w swoim kodzie stosuję również "mikrorefaktoryzację" -- dotyczy ona nie interfejsu, ale implementacji. Gdy mam na to czas, to bardzo chętnie czynię wewnętrzny, prywatny kod bardziej zrozumiałym. Bo ktoś będzie chciał go zmienić. Albo zrozumieć. Choćby po to, by poprawić jakiegoś buga (niestety niemożliwe jest, żebym wyłapał wszystkie, nawet stosując TDD). Albo zwiększyć wydajność. Może pewien fragment kodu, który nie był nigdy wąskim gardłem, po jakimś czasie nagle nim będzie. Ale jeśli masz pół miliona lipnych linii kodu, to ważniejsza jest oczywiście "makrorefaktoryzacja". Kij z tym, jak to działa i czy wewnętrzny kod jest czytelnie napisany. Najważniejsze, by wygodnie się go używało z zewnątrz.
Refaktoryzacja jest IMO najskuteczniejsza, gdy przeprowadza się nią systematycznie i najlepiej wobec własnego kodu. Bo jakby nie planować, to i tak w praktyce często wychodzi, że coś można było zrobić inaczej i tak by było wygodniej i skuteczniej (inna sprawa, że w metodologiach "na pałę" /programowanie zwinne/ za wiele się i tak nie planuje). Refaktoryzacja zwiększa jakość kodu -- jest to jej głównym zadaniem! Ponieważ w praktyce jakość kodu nigdy nie jest zbyt wysoka, refaktoryzacja niemal zawsze jest pomocna.
0
Oczywiście na 100% za.
- Kod do refaktoringu wymaga przynajmniej szczątkowych testów. Zarówno jednostkowych jak i integracyjnych.
- Kod refaktoryzuję jeżeli w momencie gdy muszę po raz drugi napisać taki sam lub podobny kod.
- Kod podlega ciągłej refaktoryzacji.
- Kod nigdy nie jest dostatecznie dobry by oprzeć się refaktoryzacji.
- Refaktoryzacja wymusza pisanie dodatkowych testów.
- Testy są przez to dokładniejsze.
- Dokładniejsze testy to więcej wykrytych braków.
- Bugi są likwidowane w trakcie refaktoryzacji, bo bug "razi po oczach".
- Kod nie zrefaktoryzowany to kod z założenia zły ponieważ od czasu jego powstania dopisano kolejny kod, który zapewne można ujednolicić z tym już istniejącym.
- Każdy kod da się zrefaktoryzować, chyba że napisano go w COBOLu.
- Jak twój manager mówi nie refaktoryzacji to przestań wprowadzać zmiany w dokumentacji. Jako przyczynę podaj brak zmian w kodzie :) - stosuję z powodzeniem i szefowa wie, że zanim nie skończę z kodem to do tego czasu nie powstanie nowa dokumentacja.
- Z kodu zrefaktoryzowanego bardzo dobrze generuje się dokumentację.
- DRY, KISS i SOLID to twoje cele.
- Jeżeli twoją ulubioną książką jest kod po refaktoryzacji to dopisz kolejny rozdział ;)
0
Jak najbardziej za i do tego zgadzam sie z przedmowcami. Ja stosuje zasade drobnych krokow, chyba ze dostaje czas wlasnie na refaktoryzacje (co sie zdarza). Jesli widze kod, ktory jest sredni, mozna go uogolnic, wyodrebnic kawalek kodu, ktory uzywany jest co najmniej 2 razy, to refaktoryzuje. Jeszcze sie na tym nie przejechalem - co najmniej 80% z tego zostalo uzyte po raz 3 ;) Zwykle taka refaktoryzacja zajmuje mi tyle samo czasu, co naprawienie bledu i przetestowanie. Z tego powodu, ze zwykle duzo latwiej pisze sie unit test na zrefaktoryzowanym kodzie (bo np. mozna napisac jeden test ogolny, zamiast 15 podobnych do siebie). Czesto tez refaktoryzuje przy okazji pracy nad wydajnoscia modulu.
//edit
Ogolnie rzecz biorac czuje sie lepiej jak wiem, ze kod jest znowu lepszy, testy znowu dokladniejsze, jest o jedna dziure mniej a do tego nie powstala nowa, bo kolejny kawalek kodu dostal swoj test :)