fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
2 minut

DevTalk#58 – O Refactoringu z Łukaszem Karskim


19.06.2017

Łukasz KarskiI stało się, dojechaliśmy do końca trzeciego sezonu podcasta DevTalk! Wielkie dzięki za to, że jesteście, słuchacie i dajecie feedback. Już po raz 58. witam się w Wami przed mikrofonem. Wow.

Dzisiejszym naszym Gościem jest Łukasz Karski. Programista z wieloletnim doświadczeniem, pełen interesujących obserwacji dotyczących naszego rzemiosła, procesów i jakości programistycznej pracy.

Rozmawiamy o refactoringu. Możecie spodziewać się dużo tech-mięsa. Dużo testów. Dużo porad. Dużo dużo!

Ten odcinek dostarcza nam wszystkim firma Ivanti: diamentowy sponsor konkursu Daj Się Poznać. Dzięki serdeczne!

Ivanti_k

Czekamy na pytania i uwagi tutaj, w komentarzu do tego odcinka.

Zrób prezent przed wakacjami i kliknij kilka gwiazdek na iTunes, co Ty na to? ;)

Miłych wakacji, dzięki i pozdro! I… PLAY!


Montaż odcinka: Krzysztof Śmigiel.
Ważne adresy:

Linki:


Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Zapisując się na newsletter zgadzasz się na przetwarzanie Twoich danych osobowych w celu wysyłania na wskazany przez Ciebie adres e-mail informacji handlowych o nowościach, promocjach, produktach i usługach związanych z serwisem devstyle.pl. Będzie to marketing bezpośredni, do realizacji którego wykorzystam Twoje telekomunikacyjne urządzenia końcowe. Administratorem Twoich danych osobowych będzie Maciej Aniserowicz prowadzący działalność gospodarczą w Białymstoku (15-215) przy ul. Konopnickiej 14/8, NIP 5422824401. Przysługuje Tobie prawo do cofnięcia zgody, żądania wglądu do Twoich danych, wniesienia sprzeciwu co do ich przetwarzania, sprostowania, usunięcia i ograniczenia przetwarzania. Więcej informacji o tym jak przetwarzam Twoje dane znajdziesz na devstyle.pl/RODO. Powered by ConvertKit
Notify of
Kamil

Mięcho MNIAM! Lubię to

Marta Banasiewicz
Marta Banasiewicz

Mam pytanie, hipotetycznie mając do czynienia z legacy code który wygląda jakby ktoś wszystko zblendowal i ucielk dobrym pomysłem byłoby ograniczenie funkcjonalności tego magicznego systemu do kilku kluczowych rzeczy po czym przebudowanie wszystkiego tak aby odpowiadało aktualnym potrzebom? Słuchając podcasta przyszła mi taką myśl do głowy. Jak to wygląda w rzeczywistości?

Mariusz Krzanowski

Jest kilka problemów z przepisaniem od nowa. Czasem klient mógł zgłosić wymagania ad hoc. Ktoś to wrzucił, mail zaginął. Przy przepisaniu może być wiele bugów zgłoszonych na zasadzie, a gdzie ta albo inna funkcjonalność? Użytkownicy nie lubią jak im się zabiera coś czego używali i do czego są przyzwyczajeni. A może być wiele takich “drobnych” zmian. Po drugie software ma dawać jak najszybciej wartość. Nieużywany jest tylko kosztem więc długie przepisywanie też jest słabo widziane. Najrozsądniej jest zacząć od refaktoringu poprzez wyciąganie małych podsystemów. P.S. Jeżeli chodzi o legacy code to polecam ten godzinny filmik https://youtu.be/_NnElPO5BU0 który pokazuje jak bezpiecznie… Read more »

Marta
Marta

Dziękuję za odpowiedź. Filmik obejrzałam, wiele mi wyjaśnił. Pisanie od nowa to BARDZO zły pomysł, wiem o tym :) Opisując tę sytuację miałam na myśli właśnie podzielenie wszystkiego na małe części i uporządkowanie ale zabierając niektóre funkcje na czas przebudowy. Jeżeli ograniczenie funkcjonalności nie wchodzi w grę to w jaki sposób zmienić architekturę i “posprzątać” jednocześnie utrzymując działanie całego systemu? I jak wygląda upload takiego przebudowanego systemu z nową architekturą? Dodawane są nowe fragmenty i usuwane stare czy zaplanowana jest data, godzina 0 i pach! mamy nowy system? Dopiero uczę się podstaw, mój kod jest króciutki i nie mam do… Read more »

Tom

a propos prywatnej funkcji…
skoro jest prywatna to znaczy, że nie ma znaczenia dla systemu, tylko ma lokalne zastosowanie, więc po co ją testować?
a jeśli testować, to powinna być zwenętrzną klasą, helperem z publiczną klasą poprzez DI.

i gdzie tu kontrowersje?
czysta logika.

Tom

druga kwestia, męczysz się ze strukturą w klasie z powodu testowania?
wniosek, klasa jest zbyt rozbudowana,
wniosek, za pewne nie spełnia Single Responisibility,
więc zamiast testować jedną dużą klasę, warto ją rozbić na kilka SIngle Responisibility.
Wzrasta czytelność, przeznaczenie kodu oraz nie potrzeba tyle dokumentacji, bo wiadomo co za co odpowiada.

Tom

notatnik zespołowy??? TODO piszesz w komentarzu w kodzie, wtedy każdy widzi zmiany nawet w komentarzu przy commitach/review. Co do architektury, nie ma sensu na siłę budować kolubryny, gdy kod zamykamy w modułach, bilbiotekach, API. Każda architektura ma jakieś cechy, wady, zalety, stąd zamykamy ją w małych boxach i idziemy dalej. Sieć modułów jest z zasady bardziej re-użyteczna. Dziel i rządź, sprawdza się w kodzie i na ludziach. Rozmawiać z zespołem nie ma sensu, gdy z góry odrzuca testowanie, finalnie to nie istotne co robisz, ważne, że dostajesz kasę za to co robisz, więc praktycznie lepiej robić gówno i zarabiać krocie,… Read more »

Kurs Gita

Zaawansowany frontend

Szkolenie z Testów

Szkolenie z baz danych

Facebook

Książka

Zobacz również