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

2

Prowizorka jest najtrwalszą konstrukcją znaną człowiekowi.

Nie trzeba później prowizorki często zmieniać, dostosowywać, nadążać za nowymi wymaganiami otoczenia, to prowizorka, patrząc biznesowo, jest dobrym rozwiązaniem. Optymalnym pod względem kosztów, czasu racy, zaangażowania i wydatków na ewentualne przyszłe (niewielkie) poprawki.

4
LukeJL napisał(a):

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ść.

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.

Psychologicznie MOŻE być jak piszesz.
Wg mnie MOCNO się to łączy z "religią wzorcową", wtedy wzorce są narzucane (przez atmosferę w zespole), produkowane na ilość (pod CV) itd.

Ja ZAWSZE wracam do stwierdzenia, co to jest wzorzec: uznanie i nadanie nazwy na coś, co od dawna jest w branży,
NA PRZYKŁAD STOLARZE nazwali jeden ze sposobów połączenia desek "na pióro", i w ten sposób się szybko i skutecznie rozumieją.
Ale zarazem ci prości stolarze są (w odróżnieniu od programistów) nigdy nie użyją złącza "na pióro" gdy nie jest potrzebne / zbędne / głupie.
Żaden stolarz nie jest zmuszany do nauczenia się I UŻYWANIA wzorców, które ktoś inny wymyślił, aby napisać doktorat albo wydać książkę

3

IMO to trochę wina podejścia agilowego.
Robimy wymagania A i B towrzymy ładny kod i sprawdzający się w tamtych warunkach. Potem przychodzi wymagania C które strasznie miesza w A i B robi jakiś dziwny bypass itd. No ale okazuje się, że od strony użytkownika to tylko input i checkbox więc programisci estymuja jak dodanie inputu i checkboxa i troche zapasu i nie stracza czasu albo nie ma chęci u dewelopera zeby sie narobic i tamto przerobic. Bo co jeśli nie daj boże zrobi bład w starym kodzie. Potem mija troche czasu ludzie się zmieniają przychodzi wymaganie D i okazuje się, że już nie ma programistów którzy biznesowo rozumieja co się dzieje w kodzie i bojąc się, że coś zepsują dospawuja wymaganie D które pasuje jak pięść do oka w tamtym miejscu. Ba dum tss mamy gówniany kod.

2

@Afish: oczywiście, tyle że jaranie się czystym kodem pozwala na napisanie systemu który daje się utrzymać i rozwijać - to jest czysty zysk w przypadku kiedy firma pracuje przez kilka lat nad swoim produktem. Cel jest oczywiście jasny, ale jesteśmy nie tylko od tego żeby kodować jak zwierzęta a zrobić to w sposób nie urągający godności człowieka.

Wielokrotnie niestety spotykałem i wciąż spotykam się z sytuacją, kiedy takie pójście na skróty w przeszłości ma swoje konsekwencje w tym, że praca nad całkiem prostym zadaniem wymaga ogromnego nakładu czasu i pracy.
Jeśli w tym o czym piszesz zawarłeś również aspekty na pograniczu biznesu i technologii to się w pełni zgadzam, jeśli tylko biznesowe to nie.

1

Po co chirurg ma myć ręce przed operacją jak ma płacone za operację a nie za mycie rąk?
Jakość kodu jest ważna, przy czym należy zachować umiar. Ani zastanawianie się godzinamk nad nazwa jednej zmiennej ani konstruktor z 20 argumentami nie są sensowne. A Ty @Marcin Marcin pracowałeś kiedyś w utrzymaniu? Kojarzysz co to godziny SLA na przykład?

5

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

Jeśli piszesz coś co można "porzucić" to pewnie nie. Ale dług techniczny rośnie z czasem. Jak dziś zrobić coś "na szybko" to jutro kolejny ficzer będzie zbudowany na tym i nagle poprawka stanie się bardzo kosztowna. Co gorsza kilka ficzerów później może okazać się, że zrobienie czegoś prostego wymaga strasznie dużo pracy.
Widziałem takie projekty w stylu pole minowe - żaden developer nie chciał dotykać kodu, bo dowolna zmiana powodowała kaskasowe błędy w różnych miejscach.

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

Problem nie jest w tym, że ludzie od nowosci piszą zły kod tylko kod się zmienia w czasie. Zmieniające się wymagania, nowe funkcje, poprawki innych błędów itd. Może napisałeś funkcje X i było ładnie, ale teraz trzeba zrobić funkcje Y i może to wymagać zrefaktorowania X.

2

To jest w ogóle ciekawe w kontekście tego kiedy do firmy przychodzi junior, który trafia na smutnych, zmęczonych albo niedouczonych "seniorów" których jedyną metryką "seniority" jest ilość dupogodzin - młody zamiast uczyć się tego jak robić żeby było dobrze i mieć w przyszłości mniej pracy łyka najlepsze smaczki od bardziej doświadczonych kolegów. Jedyne czego się uczy to jak zrobić żeby działało i się nie narobić. A co najważniejsze - nigdy nie myśleć w perspektywie dalszej niż kilka dni.

0
var napisał(a):

@Afish: oczywiście, tyle że jaranie się czystym kodem pozwala na napisanie systemu który daje się utrzymać i rozwijać - to jest czysty zysk w przypadku kiedy firma pracuje przez kilka lat nad swoim produktem. Cel jest oczywiście jasny, ale jesteśmy nie tylko od tego żeby kodować jak zwierzęta a zrobić to w sposób nie urągający godności człowieka.

Z mojego doświadczenia więcej problemów powstaje ze zmieniających się wymagań i budowania złych rzeczy, niż ze zrobienia ich niepoprawnie. Mówisz, że to jest „czysty zysk” i masz rację, ale zysk trzeba maksymalizować, a często bardziej opłaca się zrobić więcej badziewia, niż polerować miej dobrych rozwiązań.

3
LukeJL napisał(a):

Zależy jak postrzegamy wzorzec.

Tu nie ma żadnego "zależy". Wzorce mają definicję: general, reusable solution to a commonly occurring problem within a given context. Nie ma nic o liczbie linijek kodu, ani o tym, że się trzeba napracować.

Jeżeli komuś implementacja wzorców sprawia wysiłek; jeżeli zamiast wiedząc, że np. jakieś dane mają być przetwarzane za pomocą różnych algorytmów w zależności od parametru woli walnąć wielką metodę z drabinką ifów zamiast kilka małych klas w strategii, to jest po prostu niesprawnym programistą.

Schadoow napisał(a):

IMO to trochę wina podejścia agilowego.
Robimy wymagania A i B towrzymy ładny kod i sprawdzający się w tamtych warunkach. Potem przychodzi wymagania C które strasznie miesza w A i B robi jakiś dziwny bypass itd. No ale okazuje się, że od strony użytkownika to tylko input i checkbox więc programisci estymuja jak dodanie inputu i checkboxa i troche zapasu i nie stracza czasu albo nie ma chęci u dewelopera zeby sie narobic i tamto przerobic. Bo co jeśli nie daj boże zrobi bład w starym kodzie. Potem mija troche czasu ludzie się zmieniają przychodzi wymaganie D i okazuje się, że już nie ma programistów którzy biznesowo rozumieja co się dzieje w kodzie i bojąc się, że coś zepsują dospawuja wymaganie D które pasuje jak pięść do oka w tamtym miejscu. Ba dum tss mamy gówniany kod.

Wydaje mi się, że jest na to w miarę proste rozwiązanie - nowe wymaganie, to nowy kod. Jeśli starego nie ruszamy, to nie mamy go jak zepsuć.
Niestety ludzie preferują "reużywanie" kodu przez dodawanie ifologii, i wtedy właśnie powstają pola minowe.

1

Kod ma być zamknięty na zmiany i otwarty na rozszerzenia

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