Wpis z mikrobloga

Uważamy DDD, CQRS, mikroserwisy i wszystkie inne sugestie wywodzące się z szeroko rozumianej “czystej architektury” za nasz cel. Wszystko, co piszemy, niezależnie od okoliczności, musi być idealne.


@kirek: w sumie to sorry, jednak napisal w imieniu swojego teamu. Ale tak to juz jest jak juniorzy "awansuja" na seniorow czy architektow a pozniej wylewaja swoje "madrosci" w internetach.

Gdy przyszło do oceny kodu przez jego kolegów okazało się, że dołożył kolejne abstrakcje,
via Wykop Mobilny (Android)
  • 1
@bacteria: Refaktoryzacja tylko po to żeby usunąć nieładny kod nie ma sensu.

Zgadzam się

"Refaktoryzacja" to wlasnie czynnosc wykonywana w celu pozbycia sie nieladnego kodu.

@bacteria:
Tak ale celem nadrzędnym nie jest żeby kod był ładniejszy tylko żeby wydajniej dodawać kolejne rzeczy
@bacteria ale przecież Ty się w ogóle nie odniosles do tego co przekazuję autor ;o komnetujesz szczegóły zamiast odnieść się do zasadniczego tematu a na sam koniec obrażasz autora pisząc "wysryw". Czy tak powinna wyglądać dyskusja? Brzmisz jak zwykły hejt
@kirek: napisalem przeciez ze to wpis jest gowniany a nie poruszany temat. Trzeba mierzyc sily na zamiary a tutaj ewidentnie autor sie przeliczyl podejmujac dosc skomplikowany temat poslugujac sie nietrafionymi przykladami co demonstruje brak zrozumienia tematu.
Nie chcesz? Działa? Nie ruszaj! Nie rób refaktoryzacji na siłę.

Refaktoryzacja tylko po to żeby usunąć nieładny kod nie ma sensu.

@kirek: @bacteria: @zibizz1: A potem "nieładny" kod narasta i za rok nikt nawet go nie chce kijem tknąć ( ͡° ͜ʖ ͡°) Autor artykułu ma chyba doświadczenia tylko i wyłącznie z projektami trwającymi kilka miesięcy i pisanymi zawsze od zera. Jak się ma codebase
@bacteria nigdzie nie odniosles się do ogólnego przekazu a obrażasz autora, nie wchodzisz w dyskusję na temat tego przekazu ale bez problemu poprawisz słówka. Twój komentarz nie niesie chęci merytorycznego poprawienia horyzontow autora a pokazania mu ze jest gownem - czy serio tak chcemy rozmawiać?
a co sądzisz o całym artykułe?

@kirek: autor wie, gdzie dzwoni, ale nie do końca, w którym kościele. I bazuje tylko na swoim wąskim doświadczeniu z jednego typu projektów - a przynajmniej takie mam wrażenie.

Nie zawsze "projekt" to pisanie czegoś od zera i jak umowa się skończy, to zapominamy o temacie. Nie zawsze klient dokładnie wie, czego chce. Moje doświadczenia są trochę inne niż autora, ale ja zawsze pracowałem na
via Wykop Mobilny (Android)
  • 0
@Strus: zasada jest prosta. Jeśli nie masz potrzeby edycji pliku tylko np zaglasz to nie ruszasz. Jeśli musisz coś zmienić to warto się zastanowić czy nie lepiej najpierw coś poprawić.

Traktujesz jak zaschnięte gówno. Jak nie leży na środku salonu tylko gdzieś w szafce w kącie to możesz całe lata chodzić wokół niego i nie będzie śmierdziało, ale jeśli miałbyś coś do niego wsadzić to już lepiej wziąć się do roboty
@Strus: Autor pracuje przy projekcie rozwijanym przez lata z tym że ma na myśli trochę inną sytuacje niż Ty piszesz - czyli jeśli mamy np. miesiąc na wprowadzenie nowej funkcji na rynek i po tym miesiącu wprowadzi go konkurencja to wprowadzając testy i całą otoczkę związaną z "czystą architekturą" dostaniemy przerost formy nad treścią - spóźnimy się z releasem a cała organizacja poniesie ogromną stratę. Artykuł mówi o tym żeby dostosować
Jeśli nie masz potrzeby edycji pliku tylko np zaglasz to nie ruszasz

@zibizz1: Nie traktowałbym tego jako "świętej" zasady, bo jeśli na "zaglądanie" straciłeś X godzin czasu w celu analizy, i nic z tym nie zrobisz, to następna osoba znowu straci X godzin czasu na tę samą analizę. Wiadomo, że jak coś jest słabo napisane 10 lat temu, ale zaglądasz tam na chwilę i czytasz trzy linijki to nie ma sensu
@Strus: a co jeśli zostawienie tego tak i zabranie się od razu za nową funkcję da lepszy efekt organizacji? Pracujemy dla lepszego kodu czy dla większego zysku? Czy jeśli wybierzemy w takiej sytuacji kod to czy to nie będzie dosłownie przerost formy nad treścią? Ja wiem że rozwijanie w taki sposób będzie powodować wyceny nowych rzeczy liczone tylko w dwucyfrowych MD i że zapał programistów będzie ulatywać niczym dym z papierosa,
Pracujemy dla lepszego kodu czy dla większego zysku?

@kirek: Lepszy kod zawsze daje większy zysk długofalowo. Im większy dług zaciągasz tym większe problemy masz w przyszłości. Chyba, że Twój codebase jest malutki i nie ma to większego znaczenia.
@kirek: Jak będziesz klepał gówniany kod "aby szybciej" to w końcu i tak Cię wyprzedzą. Istota problemu jest gdzie indziej - skoro nie możesz nadążać w wyścigu bez nieustannego zaciągania długu technologicznego, to prawdopodobnie masz problem z ludźmi. Może jest ich zbyt mało, może są za słabi technicznie, może kuleje proces rozwoju oprogramowania etc.
@Strus: Zapominamy że to nadal jest biznes i dlatego to jest właśnie pułapka:P paranoiczna chęć pisania ładnego kodu zabiera nam efektywność pracy wtedy kiedy jej najbardziej potrzebujemy :<
Jak będziesz klepał gówniany kod "aby szybciej" to w końcu i tak Cię wyprzedzą.


@Strus: ale właśnie w tym sęk że nie :D to że jestes na rynku dłużej buduje świadomość marki i nawet jeśli w 10% przypadków użycia Twoja apka nie działa i w tych 10% konkurencja jest lepsza to pół roku różnicy pomiędzy Twoim wejściem na rynek a konkurencji sprawia że i tak Twoje rozwiązanie, mimo że nie idealne,