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/
0 0 votes
Article Rating
10 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Kamil
7 years ago

Mięcho MNIAM! Lubię to

Marta Banasiewicz
Marta Banasiewicz
7 years ago

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
7 years ago

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 dokonać refaktoringu.

Marta
Marta
7 years ago

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 czynienia z “produkcją kodu” ale jednak przychodzą mi do głowy kiedy słucham DevTalka.

Marta
Marta
7 years ago

Dziękuję za komentarze :) miałam na myśli refactoring oraz zastosowanie jakiejś korzystnej architektury, przebudowę zamiast pisania od nowa.

Tom
Tom
7 years ago

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
Tom
7 years ago

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
Tom
7 years ago

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, niż zarabiać gówno za zrobienie super kodu, ewentualnie warto zmienić team, każdy się rozwija w swoim tempie i nie każdy ma szefa który mu dozgonnie ufa.

Kurs Gita

Zaawansowany frontend

Szkolenie z Testów

Szkolenie z baz danych

Książka

Zobacz również