Czy w praktyce stosuje sie refaktoryzacje kodu?

Question

Jak w temacie.

Czy pracujac w firmie programistycznej ma miejsce refaktoryzacja kodu? Pisze teraz pare projektow i widze jak to rzeczywiscie pomaga z poprawieniem czytelnosci i zrozumieniem co sie wlasciwie dzieje, ale czy w firmach i w pracy jako takiej stosuje sie to w praktyce? Pytanie do osob ktore pracuja/pracowaly jako programisci/webmasterzy itd.

Answer 1

Zależy od firmy

Teraz pracuje zdalnie i akurat tutaj wszystko odbywa się bardzo porządnie
Code review, refaktoryzacja, dbanie o jakość, testy do prawie wszystkiego i ogólnie dobre praktyki

Ale jak na niektórych rozmowach o prace pytałem jak to wygląda u nich, często mówili że zależy od programisty, np raz dowiedziałem się, że testy programiści piszą dla siebie, żeby później oszczędzić sobie czasu z naprawianiem błędów, więc to sprawa indywidualna każdego programisty - efekt jest taki, że zazwyczaj tych testów się nie pisze (podejście jak zrobisz tak masz)
Ale to przykłady z mniejszych firm, nie wiem jak jest w np korporacjach, obstawiam że duże firmy bardziej o to dbają

Pewnie też zależy od tego, na jaki zespół trafisz. Czy będziesz miał np seniorów, którzy nie dopuszczą do wrzucenia kodu na mastera, jeśli nie będzie napisany dobrze i z potwierdzeniem że wszystko działa, w postaci testów
Czy podejście jak wspomniałem wyżej - rób jak chcesz, ale jak coś się wysypie to ty sie męczysz i naprawiasz (może zbyt źle to określam, no ale jeśli na rozmowie o prace dowiaduje się o takim podejściu, to wątpię żeby w tej firmie wewnątrz o to dbali)

Comments

Test driven naprawde jest tak przydatne?

---

Spróbuj i sie przekonaj. Jak zaczniesz to już w tym zostaniesz ;)

---

W ASP.NET na studiach raz to probowalismy ale tyle bylo cyrku wokol konfiguracji ze nawet nie widzialem na ile byloby to praktyczne. Ale teraz w nodzie moze kukne.

---

Czemu cyrk ?

Same zalety:

Przyspieszenie pisania kodu,

latwosc w odnajdowaniu bledow,

przyspieszenie wprowadzania zmian w kodzie,

ladniejszy kod

---

Moze zle zostalo mi to przedstawione. U nas profesor pokazal nam to na juz dzialajacej aplikacji, czyli trzeba bylo wszystkie modele i metody przebudowywac

---

Dlatego pisanie aplikacji zaczyna sie od pisania testów :)

---

A nie jest tak ze testy tworza wiecej klopotow niz pomocy? Zawsze jak cos dorzucalem do kodu to tylko komplikowalo sprawe.

---

Wlasnie o to chodzi w tdd. Piszesz testy, ktore sprawdzaja czy twoja funkcjonalnosc dziala(bedzie dzialac) prawidlowo. przy kazdej zmianie funkcji, wiesz ze dziala ona prawidlowo, bo testy przechodza. Jak nie przechodza to znaczy, ze rzeczy, ktore dodales do funkcjonalnosci dzialaja zle - robia cos innego niz powinny.

---

Yhm. No to pewnie przy nastepnym projekcie sprawdze z czym to sie je

---

to bardziej kwestia doświadczenia

jak napiszesz kilka testów to nauczysz się jak pisać kod, żeby był prostszy do testowania
i też nie potrzebujesz do tego lat doświadczenia i ostrej analizy, jakiś tydzień klep sobie projekt gdzie prawie wszystko będziesz testował i zauważysz jak powinien wyglądać kod, który jest możliwy i łatwy do testowania
np dobrą opcją jest używanie interfejsów, żeby dało się mockować

co do samego "wszystko musi być przetestowane", prawie zawsze (przynajmniej u mnie, poziom juniora asp net) jest jakiś szczegół, przez który aktywność który nie działa
więc możesz sam sobie odpowiedzieć co by było gdyby ten błąd odkrył użytkownik a nie osoba testująca kod
co prawda jak błąd jest delikatny to łatwo naprawić, ale lepiej od razu sprawdzić czy wszystko jest ok, niż później się stresować bo użytkownicy dostają błędy

też czasami zmiana na jednym końcu programu powoduje zepsucie się czegoś na drugim końcu
tworząc dobrze kod nie powinno to mieć miejsca, ale nikt nie jest idealny i trzeba mieć to na uwadze
jak masz już napisane testy, to przed commitem odpalasz i wiesz czy na pewno wszystko działa
(ewentualnie continous integration, ale jak możesz testować lokalnie to testuj lokalnie, lepiej żeby ci wyżej widzieli dużo zielonego w twojej pracy)

Answer 2

Stosuje się ale ma być systematyczna. Po napisaniu kilkudziesięciu tysięcy linii kodu w trybie "nieważne bo działa", biznesowo nie obronisz stanowiska "poświęcamy 2-3 msc. na poprawienie jakości kodu". Padnie pytanie co to da klientowi i kto za tę pracę zapłaci. Obowiązuje syndrom wybitego okna. Jak ktoś stłucze szybę w klatce schodowej, pojawią się menele, "sprajciarze-partacze" (przepraszam stret art'owcy), sikające pieski i inne tego typu .. zjawiska. Wybite szyby wstawia się natychmiast. Szczególnie w kodzie.

Comments

Tzn? Do czego porownaniem jest to okno? Bo nie bardzo rozumiem

---

Chodzi o to, że jedno "a zostaw, działa to nie ruszaj", generuje kolejne i kolejne, a po jakimś czasie masz pełno syfu w kodzie

---

@Alex.Ironside, Broken Windows

M.

---

A. Dzieki za wyjasnienie