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!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). 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 »

Moja książka

Facebook

Zobacz również