I 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!
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:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki:
- DevTalk#41 – O legacy code z Jarosławem Pałką: http://devstyle.pl/2016/10/03/devtalk41-o-legacy-code-z-jaroslawem-palka
- “Working Effectively with Legacy Code”: https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
- posty na devstyle:
- 3 sprawdzone sposoby na wprowadzanie testów do istniejącego kodu: http://devstyle.pl/2016/10/06/3-sprawdzone-sposoby-na-wprowadzanie-testow-do-istniejacego-kodu/
- Refactoring sprint? Plażo, please…: http://devstyle.pl/2016/11/15/refactoring-sprint-plazo-please/
- Visual Studio code maps: https://msdn.microsoft.com/en-us/library/jj739835.aspx
- moja prezentacja Testy konwencji: https://www.youtube.com/watch?v=zvrxNubED_E
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
Mięcho MNIAM! Lubię to
Najs, smacznego! :)
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?
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.
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.
Przepisanie od nowa raczej rzadko jest dobrym pomysłem. Albo nawet nigdy.
Tak jak pisze Mariusz: lepiej refactoring. Ale nie taki “zaplanowanych na miesiąc że tylko poprawiamy i nic nie dodajemy i po miesiącu będzie super”. A refactoring stały, codzienny, celujący w długoterminowe korzyści.
Dziękuję za komentarze :) miałam na myśli refactoring oraz zastosowanie jakiejś korzystnej architektury, przebudowę zamiast pisania od nowa.
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.
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.
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.