Po co refaktoryzować? Nie można od razu napisać dobrze? Czy słaby kod to zawsze zły kod?

0

Naszła mnie taka refleksja gdy przeglądam swój dobry (bu bu) słaby kod którego nie skończyłem.
Zrobiłem prototyp aby jakoś działało. Zostawiłem. Brak dokumentacji. Brak testów.

Naszło mnie takie przemyślenie
Skoro kod działa i na siebie zarabia to jeżeli nie ma testów, nie jest super czysty tylko był zrobiony na szybko aby jakoś działało to może testy, wzorce projektowe itd. których jestem takim zwolennikiem nie są takie super? Czy nie doprowadzanie do momentu gdy mamy tz. big ball of mud jest faktycznie takie ważne?

Oczywiście coś co mi się podoba i gadanie managerów:
ten projekt się przepisze, teraz to tylko szybko załatamy
Tylko że nigdy się tego nie przepisze bo nigdy nie będzie na to pieniędzy

Po co refaktoryzować jak można od razu pisać dobry kod?

27

Taki autentyk - kiedyś (daaaawno temu), w pierwszym januszsofcie jakim pracowałem, nie radziliśmy sobie z zarządzaniem błędami.
Zgłoszenia od testerów i klientów szły telefonicznie, mailem i na gębę - nie dało się w tym połapać, czasem naprawa jakiegoś błędu konfliktowała z innym zgłoszeniem (bo specyfikacja też była przekazywana ustnie, pokątnymi mailami z excelami w środku i wymyślana na poczekaniu).
Ogólnie, profesjonalizm pełną gębą.
Poszedłem do menadżera projektu - wytłumaczyłem na czym polega problem, dlaczego ciągle zapominamy o naprawach bugów i zaproponowałem, żeby wprowadzić Bugzillę (to było tak dawno temu). (Dla współczesnych - Bugzilla to taka jira, youtrack czy coś tam dla ogarniania zgłoszeń - można tym straszyć dzieci).

Na pytanie menadżera: "ile mi to instalowanie i wprowadzanie Bugzilli zajmie" odpowiedziałem, że 4 godziny...
Menadżer prawie zapowietrzył się z wściekłości, 4 godziny to czas, w którym w januszsofcie, zgodnie z typowym planem dnia, miałem napisać CMS, wdrożyć system intranetowy u klienta i jeszcze klepnąć stronę wizytówke dla dwóch innych.

Zamiast tego wydał zarządzenie:

  • Od teraz zakaz robienia błedów - pod groźbą kary finansowej

No i już nigdy więcej błędów nie było.
Elegancko.

1

Ach Jarek i jego opowieści których tak chętnie słucham. Już wiem czym jest problem dużego biustu.

No i już nigdy więcej błędów nie było.

My mamy dobrych programistów.
Po co pisać testy przecież nasi programiści piszą dobry kod.

2
Marcin Marcin napisał(a):

Po co refaktoryzować jak można od razu pisać dobry kod?

No ja też jestem za. Niestety masa ludzi uważa, że najpierw trzeba napisać spaghetti, potem dodać wzorce projektowe, a na końcu testy, czyli zasadniczo zupełnie odwrotnie niż należy.

8
Marcin Marcin napisał(a):

Skoro kod działa i na siebie zarabia to jeżeli nie ma testów, nie jest super czysty tylko był zrobiony na szybko aby jakoś działało to może testy, wzorce projektowe itd. których jestem takim zwolennikiem nie są takie super? Czy nie doprowadzanie do momentu gdy mamy tz. big ball of mud jest faktycznie takie ważne?

Chyba każdy inżynier w pewnym momencie uświadamia sobie, że jaranie się czystym kodem i innymi technicznymi rzeczami nie ma takiego znaczenia, jak zarabianie kasy przez produkt. Wzorce, dobre praktyki, konferencyjne gadki i reszta mają pomóc w rozwiązywaniu problemów biznesowych, a nie w pisaniu czystego kodu jako sztuka dla sztuki.

Tylko że nigdy się tego nie przepisze bo nigdy nie będzie na to pieniędzy

Kasa się znajdzie, jeżeli pokażesz wyliczenia, że przepisanie przyniesie zysk. Bo po co płacić masę kasy, jeżeli potem to się nie zwróci?

Po co refaktoryzować jak można od razu pisać dobry kod?

Pisanie dobrego kodu jest najprostszą częścią inżynierii oprogramowania. Trudne jest ustalanie, które problemy rozwiązywać i w jaki sposób. Złożone projekty są kijowe niekoniecznie dlatego, że zostały napisane syfiasto, często jest to połączenie wielu czynników, jak bardzo krótki termin na wdrożenie (czyli na produkcję leci prototyp), architektura wspierająca rozwiązania, które ostatecznie nie są potrzebne (i nikt ich nie używa), rotacje w projekcie (bo każdy ma inną wizję czystości kodu, więc jak pierwotny autor odchodzi, to następny chce przerabiać na swoją modłę i robi niespójnie), zmiana wymagań na każdym kroku, haki wynikające z niedojrzałości platformy czy tam bibliotek i wiele innych rzeczy. Programowanie jest proste, inżyniera oprogramowania jest trudna, a najtrudniejsze (i najbardziej wartościowe) jest dostarczenie rozwiązania, które działa i spełnia potrzebę biznesową, ale w ogóle nie wymaga programowania.

0

Chyba każdy inżynier w pewnym momencie uświadamia sobie, że jaranie się czystym kodem i innymi technicznymi rzeczami nie ma takiego znaczenia, jak zarabianie kasy przez produkt. Wzorce, dobre praktyki, konferencyjne gadki i reszta mają pomóc w rozwiązywaniu problemów biznesowych, a nie w pisaniu czystego kodu jako sztuka dla sztuki.

Celem pracy jest zysk

9
Marcin Marcin napisał(a):

Po co refaktoryzować jak można od razu pisać dobry kod?

Pytanie trochę w stylu: "Po co chybiać strzelając, skoro można zawszę trafiać w 10?"

4

wzorce projektowe itd.

Wzorce projektowe to zwykle po prostu obejścia ograniczeń języka. Czyli im więcej trzeba wzorców projektowych napakować, tym gorszy język (a przynajmniej mniej ekspresywny), bo zamiast pisać to, co chcesz, żeby komputer zrobił, to musisz pisać dużo kodu, który nic nie robi, a jest "wzorcem".

Po co refaktoryzować jak można od razu pisać dobry kod?

Jak umiesz, to pisz.

Skoro kod działa i na siebie zarabia to jeżeli nie ma testów, nie jest super czysty tylko był zrobiony na szybko aby jakoś działało to może testy, wzorce projektowe itd. których jestem takim zwolennikiem nie są takie super?

Jak coś jest małego, co nie wiadomo jak działa, ale działa, coś, czego nigdy już nie ruszysz - to niech sobie będzie nawet ze słabym kodem. Co innego, jak będziesz musiał to utrzymywać.

Czy nie doprowadzanie do momentu gdy mamy tz. big ball of mud jest faktycznie takie ważne?

Big ball of mud czy kod spaghetti spowalnia programistów. Bo trzeba bardziej myśleć nad tym, co jakiś kawałek kodu robi. Też ciężko dodać nowe ficzery, bo się okazuje, że dana architektura nie pozwala na łatwe zmiany itp. Wrzucając śmieciowy kod do projektu zaciąga się dług techniczny, który kiedyś trzeba będzie spłacić. Nawet jak nic nie zrobisz z tym kodem, to i tak potem będzie cię spowalniał, więc i tak trzeba będzie spłacić ten dług, czyli albo zrobić od czasu do czasu refaktoring albo przyjąć na klatę postępujący spadek produktywności.

3
LukeJL napisał(a):

wzorce projektowe itd.

Wzorce projektowe to zwykle po prostu obejścia ograniczeń języka. Czyli im więcej trzeba wzorców projektowych napakować, tym gorszy język (a przynajmniej mniej ekspresywny), bo zamiast pisać to, co chcesz, żeby komputer zrobił, to musisz pisać dużo kodu, który nic nie robi, a jest "wzorcem".

Nie za bardzo.
Wzorce nie (zawsze/rzadko) zastępują słabości języka, ale są na innym poziomie abstrakcji. Olbrzymia większośc wzorców jest cięciem w zakresie odpowiedzialności (separacją) i język niewiele ma do tego.

Oczywiście, stosując wzorce w C tzreba się opisac więcej linii itd niż w języku wyższego poziomu, ale to inna opowieść.

3

Oczywiście, stosując wzorce w C tzreba się opisac więcej linii itd niż w języku wyższego poziomu, ale to inna opowieść.

Zależy jak postrzegamy wzorzec. Jeśli uznamy, że to pewna koncepcja programistyczna, rodzaj abstrakcji, to nawet jeśli jesteśmy w stanie zaimplementować w kilku linijkach dany wzorzec (albo czasem wręcz w jednej), wtedy faktycznie możemy uznać, że język nie ma nic do tego. Abstrakcja jest abstrakcją, niezależnie czy się namęczyliśmy przy jej implementacji, czy nie.

Ale jeśli uznamy wzorzec tak, jak często się to przedstawia, czyli coś, co wymaga naprodukowania dużej ilości kodu i stworzenia iluś klas, żeby zaimplementować banalne zachowanie, to może to wskazywać na to, że piszemy w języku małoekspresyjnym, że do implementacji prostych zachowań trzeba się nakodzić. A wtedy wzorce jawią się jako coś kosztownego w implementacji, co aż należy podkreślić, że się ich używa (mimo, że w innym języku implementacja danego wzorca to będzie tylko kilka linijek zamiast kilkudziesięciu).

Może też ludzie gdzie indziej kładą nacisk, niż trzeba. Zamiast stosować ogólne zasady typu SOLID, to szukają gotowych recept typu "magiczne wzorce, które poprawią jakość kodu". A potem wychodzi overengineering.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0