Wpis z mikrobloga

@SoftBull: z moich doświadczeń wynika że praca w legacy po prostu jest latjowa, często są to projekty w których jest się samemu lub w jakimś małym zespole bez sprecyzowanego procesu, pracujesz sobie swoim tempem a #!$%@? zawsze możesz zwalić na dług technologiczny
  • Odpowiedz
@mirasKo-Kalwario: > w legacy bardziej się rozwijasz
Chyba nie widziałeś na oczy prawdziwego legacy, pisanego 5 lat temu przez hindusów bez zachowania jakichkolwiek konwencji i zasad. Logika biznesowa nieuporządkowana, napisana bez funkcji XD, zaokrąglanie raz w góre raz w dół.
Poprawianie bugów w czymś takim to strata czasu, bo niczego z takiego kodu się nie nauczysz tylko #!$%@?.
  • Odpowiedz
@SoftBull: O niedawno dłubałem w zapomnianych przez Boga i ludzi mikroserwisach czyli legacy pełną gębą. Zespół liczył parę osób, robota trafiła się tylko mi. Systemy do przepisania na nowe miały być proste, małe i przyjemne a skoro trafiło się to jednemu to pewnie i miało to zająć mało czasu. Stwierdziłem, że dam radę. Przewaliłem pół roku pracy, nie skończyłem, robota poszła na półkę. Obiecałem sobie, że jak mnie znowu wrzucą w
  • Odpowiedz
@echelon_ Ciekawe, Domyślam się że był to pewnie rozproszony monolit gdzie każdy gadał z każdym na potęge bo ktoś dał nieźle ciała z ustaleniem granic tych serwisów? Co było dla Ciebie największym problemem, brak wiedzy biznesowej jak to ma działać, czy bardziej problemy techniczne? Rozumiem że jako rewrite stawiałeś te serwisy od nowa czy poprostu starałeś się ogarnąć bajzel w nich bez ponownego podziału?
  • Odpowiedz
@WhatElseToSay: Przepływ informacji między serwisami był dosyć prosty, komunikacja pomiędzy nimi minimalna. Problem był w samych mikroserwisach:
Hinduska myśl techniczna w kodzie, ORM napisany z palca przez hindusów (plus procedury storowane) zamiast np. wykorzystać Hibernate, skomplikowana logika biznesowa.
Serwisy które podmieniałem nie działały chyba i nie stawiałem ich. Kod momentami był tak zagmatwany i tak niejasny, że kopiowałem większe bloki kodu żeby czegoś nie pomieszać.
Potem jak już kod zaczął przypominać
  • Odpowiedz
@echelon_ o tak logika w procedurach, ostatnio na rozmowie usłyszałem że część logiki mają w db, pytam się dlaczego, a no dlatego że bazodanowcy nie mieli nic do roboty :D Kolejna rzecz to właśnie jakieś inhouse frameworki, typu zróbmy własny ORM, jak ja tego niecierpie. Też się spotkałem z sytuacjami gdzie pytalem jak coś docelowo ma działać, tj jaka powinna być logika a w odpowiedzi dostawałem : "
No gdzieś tam many
  • Odpowiedz
@WhatElseToSay: Testy były ale jednostkowe, chyba jakiś integracyjny. Strasznie brakowało czegoś end-to-end i wsparcia QA bo to często oni wiedzą jak coś ma działać. W tej robocie ani razu nie spotkałem się z QA.
  • Odpowiedz
@echelon_ No i tutaj też pojawia się pytanie czy te testy jednostkowe testowały funkcjonalność, czy raczej były na bardzo niskim poziomie przez co tylko betonowaly kod i utrudniały refaktor a wszystko było spięte mockami :)
  • Odpowiedz
@wetorek2: trzeba tak poprawiać żeby używać najnowszych trendów i wzorców a nie na #!$%@? ale to trzeba mieć ogarnięty biznes i przełożonych albo nie bać się im powiedzieć że tak trzeba zrobić i mieć nadzieje że zrozumieją
  • Odpowiedz
@SoftBull: Bo taki soft zarabia pieniądze, ma klientów i nie zniknie z dnia na dzień.
Poza tym są eksperci domenowi, wiadomo jak naprawdę to ma działać.
W takim projekcie wymienia się frameworki już bez wsparcia, wchodzi parę ficzerów i czas sobie leci.

A w greenfield tysiące pomysłów, mnóstwo spotkań, spajków, co pull request to rewolucja w pakietach.
Albo wymagania biznesowe zmieniane o 180 stopni. Nie mam już do tego chęci.
  • Odpowiedz