Pracuje z niechlujami

1

Pracuję w pewnej firmie (nie jest to janusz soft), mam niecały rok doświadczenia zawodowego (własne projekty w innych technologiach klepie do szuflady od 10 lat, więc nie jest to dla mnie temat obcy) i mam nieprzyjemność na co dzień pracować z ludźmi o których powiedzieć, że piszą słaby kod to jak powiedzieć komplement. Zanim zacząłem kodować za pieniądze byłem pewien, że opowieści o słabych developerach z 2+ lat doświadczenia to mit. No to miałem okazję się przekonać, nie żebym pozjadał wszystkie rozumy, ale nikt mi nie wmówi, że stworzenie klasy, która jednocześnie jest encją, serwisem i repozytorium, stworzenie z niej beana, a następnie tworzenie jej przez new jest normalne. Podobnych sytuacji jest miliard, jak widzę, że ktoś taki bierze task na estymowany na 3 dni to ja się boję w repo zaglądać. I nie są to goście po bootcampie, zaznaczam. Pytanie brzmi: co robić ? Jak sobie radzić w takiej sytuacji ? Odejść ? To na bank, ale jeszcze nie teraz, potrzebuję niestety nadal zdobywać doświadczenie komercyjne, nie jestem jeszcze na etapie przebierania w ofertach.

9

Przecież 2 lata to ledwie junior. Czego się spodziewałeś? Tempo pracy w większości większych frim jest tak wolne, że przez te dwa lata niewiele większość ludzi się de facto uczy, jeśli nic nie robi poza godzinami pracy. A w wielu wypadkach tego nie robią, bo 8h dziennie to wystarczający czas by większość z nich miała na widok kodu odruch wymiotny po skończeniu dnia w robocie.

2

Po prostu rób swoje i ulepszaj kod małymi krokami, tam gdzie to możliwe. Spróbuj wprowadzić do zespołu code review. Albo po prostu wiej już teraz, na tym etapie szczególnie potrzebujesz choć jednego gościa w zespole, od którego możesz się uczyć. Generalnie z jakością kodu w większości miejsc jest problem, zwłaszcza gdy ten kod ma kilka lub co gorsza kilkanaście lat. Nie ma się co napalać na idealnie napisane projekty. Trzeba sprzątać po kawałku co sie da i tyle. Ważne, żeby samemu nie ulec pokusie robienia na odwal skoro cały projekt i tak jest zrypany.

3

Nie rozumiem sensu takiego pytania.

Opcje są chyba jasne. Możesz:
-odejść,
-zostać i próbować zmienić standardy w firmie,
-zostać i mieć w dupie standardy w firmie i klepać po swojemu,
-zostać i dostosować się do standardów w firmie.
Zakładam, że jesteś w stanie określić potencjalne konsekwencje każdej z nich.

A może jakiś anonim z forum ma Ci powiedzieć, jaką decyzję wybrać?
Twoje życie, Twoje uwarunkowania, Twoje decyzje.
Witamy w dorosłym świecie.

2

Często się z tym spotykam ;) Zawsze mnie bawią problemy naszej branży (słabi deweloperzy, słabe zarządzanie projektami, beznadziejne projekty albo czasami brak pracy w projektach itd itd) mając świadomość jak duże pieniądze tu się obracają. Naczyta się człowiek clean code'a, software craftman i inne takie, zmienia firmę wierząc że teraz trafi do tego wymarzonego teamu a tu znowu zonk. Prawda jest taka że hajs ma się zgadzać po stronie biznesu przez co bierze się beznadziejnych ludzi którzy są tańsi, utrzymuje beznadziejne projekty i pracuje się w beznadziejny sposób i jak dotąd mimo że już kilka razy zmieniałem firme to nie trafiłem jeszcze do żadnego projektu który faktycznie mógłby pochwalić się fajną współpracą i dobrym clean codem (choć wierze że mi się kiedyś uda :D )

1

masz 17 lat że takie pytania zadajesz? (hi Spyze XD)
rzucasz wypowiedzenie idziesz pracować ze specjalistami, chyba że cię nigdzie indziej nie chcieli czyli jesteś we właściwym miejscu :)

2

Dobra, jeszcze dopiszę tak - jak klepiesz kod od 10 lat bez ciśnienia i dbając o jakieś tam standardy i przemyślałeś już swoje na temat różnych aspektów technicznych, to siłą rzeczy będziesz bił na głowę kogoś z 2 letnim "doświadczeniem polowym", który na serio zaczął programować dopiero w robocie, a wcześniej tylko coś tam czaił z podstaw języka i jako tako nawigował we własnym kodzie/potrafił połączyć się z bazą danych i wysłać zapytanie SQL. Bo większość roboty "programisty" (a raczej małpy do kodowania) w obecnych czasach mniej więcej wokół baz danych się kręci tym czy innym sposobem, nawet jeśli nie pracujesz w tym słynnym webdevie. Chyba, że obrałeś ścieżkę bardziej niszową jak embedded, czy programowanie systemowe.

0

Abstrahując od tego konkretnego przypadku, to klepanie do szuflady może mieć zerową wartość. Na projektach zespołowych @studbaza wyszło, że większość z nas klepało sobie cośtam na własną rękę, myślała, że tworzony kod jest jasny, czysty, ocierający się o genialne pomysły. A w konfrontacji z innymi okazywał się być nieutrzymywalnym gniotem.

Więc możliwe, że człowiek, który koduje 2 lata w zespole w korpo będzie pisał lepszy kod, niż świeżak z 10 letnim niekomercyjnym doświadczeniem, któremu się wydaje, że pisze dobrze.

0
eL napisał(a):

Często się z tym spotykam ;) Zawsze mnie bawią problemy naszej branży (słabi deweloperzy, słabe zarządzanie projektami, beznadziejne projekty albo czasami brak pracy w projektach itd itd) mając świadomość jak duże pieniądze tu się obracają. Naczyta się człowiek clean code'a, software craftman i inne takie, zmienia firmę wierząc że teraz trafi do tego wymarzonego teamu a tu znowu zonk.

Jakbym czytał opis swoich pierwszych doświadczeń w branży xD

Prawda jest taka że hajs ma się zgadzać po stronie biznesu przez co bierze się beznadziejnych ludzi którzy są tańsi, utrzymuje beznadziejne projekty i pracuje się w beznadziejny sposób i jak dotąd mimo że już kilka razy zmieniałem firme to nie trafiłem jeszcze do żadnego projektu który faktycznie mógłby pochwalić się fajną współpracą i dobrym clean codem (choć wierze że mi się kiedyś uda :D )

Zgadza się, ludzie którzy coś ogarniają po prostu nie wytrzymują psychicznie dłużej, chyba że są porządnie zakompleksieni co do swoich możliwości realnych i godzą się na pracę bo się boją, że mogą być "za słabi" do pracy gdzie indziej i trzymają się tego co już mają kurczowo. No ale w końcu może nadejść ten czas gdy przejrzą na oczy i postawią pracodawcy żądanie podwyżki do poziomu ich realnych umiejętności, a w morzu bylejakości jakość trochę kosztuje.Więc bardziej opłacalne jest nie przyjmować tych lepszych ("wystarczająco dobre jest wrogiem lepszego" jak głosi maksyma), lub pozbyć się ich w miarę szybko zanim dojdzie do ich "przebudzenia".

Biznes oznacza maksymalizację zysku, nie maksymalizację jakości. Pracowałem dla polskiego podwykonawcy systemów, które są stosowane przez gigantów z Doliny Krzemowej na naprawdę newralgicznych poziomach i wierz mi, że zachodziłem w głowę jak taki szit, który ta firma produkowała raz że był przez klienta akceptowany, dwa że jako tako działał, bo sami programiści weterani otwarcie przyznawali, że takim trybem pracy, jaki szliśmy produkowaliśmy kod wyglądający jak szajs, ale tempo prac ładnie prezentowało się w tabelkach dla managementu klienta. Ludzie, którzy z tym mieli problem po prostu odchodzili z firmy, więc szef zaczął robić odsiew ludzi, których jakość w ogóle obchodziła przy rekrutacji.

2

Nie spotkałem ŻADNEJ firmy, która robi porządny soft.

Im lepszą firmę spotykałem (pod względem hajsu) to ludziom po prostu mniej zależy na tym by bardziej się zaangażować i robić rzeczy z głową.

Myślę, że to wynika z tego, że:

  • to tylko praca, i po prostu zdrowiej jest mieć duuuży dystans do roboty, a w lepszych firmach jest więcej starszych ludzi, a Ci z kolei mają rodziny, zwierzęta, zainteresowania niezwiązane z komputerem, no i ciężej jest wtedy znaleźć chęci do pomysłowego działania w robocie
  • praca w grupie jest przereklamowana i bez zaangażowania oraz poświęcenia trudno o efekty, osoba musi wtedy czuć, że zapłacą jej proporcjonalnie do efektu; natomiast w pracy na etat płacą za dupogodziny, a nie za efekty

PS1, sam czuje, że mógłbym wszystkie moje zadania ze sprinta trzasnąć w 1-2 dni w dwutygodniowym sprincie, ale po co? Skoro już mnie chwalą :D

Jeśli czujesz, że masz w sobie moc (ja tak czuję :-) ) to rozwijaj się po pracy, rób własne projekty, chódź na konferencje, podróżuj po świecie, zbuduj wymarzona sylwetka i takie tam.

PS2, ale gdybym spotkał firmę, która ma zajebistych ludzi, i która robi zajebisty kod i oczywiście zechce mnie zwerbować (szarego szaraka) to rzuciłbym wszystko :-D

2
Zakręcony Szewc napisał(a):

Abstrahując od tego konkretnego przypadku, to klepanie do szuflady może mieć zerową wartość. Na projektach zespołowych @studbaza wyszło, że większość z nas klepało sobie cośtam na własną rękę, myślała, że tworzony kod jest jasny, czysty, ocierający się o genialne pomysły. A w konfrontacji z innymi okazywał się być nieutrzymywalnym gniotem.

Więc możliwe, że człowiek, który koduje 2 lata w zespole w korpo będzie pisał lepszy kod, niż świeżak z 10 letnim niekomercyjnym doświadczeniem, któremu się wydaje, że pisze dobrze.

Może tak być. Mogło też być odwrotnie. Jeśli człowiek przez ten czas brał pod uwagę takie aspekty jak wydajność, przejrzystość, modularność, skalowalność i analizował wykorzystywany realnie kod (wiele projektów FLOSS rozwijanych komercyjnie jest wszak dostępna na githubie, sourceforge itp.), to jedynym brakiem mogło być niedostosowanie tempa tworzenia kodu do "realnych warunków polowych", gdzie "cokolwiek byle działało" jest tańsze i wystarczająco dobre by ktoś dawał jebanie o jakość tego.

Gdyby Torvalds nie zjebywał na listach dyskusyjnych g**no kodu g**no sterowników i modułów, które próbują wypychać różne firmy i korpo, to by projekt zginął już dawno śmiercią tragiczną. Obecny kod nie jest najpiękniejszy, to prawda. Ale wierz mi, że wielu klientów posiada na swych serwerach o wiele gorszej jakości customowe porty i modyfikacje, które nigdy nie ujrzą światła dziennego poza serwerownią. Po prostu trzeba je było pisać jak najszybciej, żeby wyrobić się przed deadlinem, managementu jakość tego kodu nie obchodziła. Tak, ten kod jest właśnie nieutrzymywalnym gniotem, którego szybciej się przepisze na nowo, niż zmodyfikuje. Ale hula na serwerach firm wartych grube miliardy dolarów.

0

Mógłbym nawet mocno zejść z ceny :D Zna ktoś coś? :-D - nohtyp dziś, 09:47

@nohtyp research & developement AT&T robił kiedyś dość przyzwoity kod, ale mieli wtedy m.in. Pike'a na liście pracowników. Obecnie ich największe gwiazdy albo już odeszły do krainy Wiecznych Łowów, albo są na liście płac Googla, głównie przy golangu. Fundacje dbające o rozwój komercyjnych produktów Wolnego Oprogramowania mogą być kolejnymi potencjalnymi zainteresowanymi.

0

Spoko, przecież to Java. Tam wszystko jest o parę lat spóźnione. Za 2-3 lata, jak już będzie mniej wolnych miejsc dla studentów to i przyjdzie Clean Code.

0

Ludzie zacznijcie wreszcie robić pieniądze zamiast czystego kodu

0
Czarny Kowal napisał(a):

Ludzie zacznijcie wreszcie robić pieniądze zamiast czystego kodu

Jakbym chciał robić hajs to bym został szołmenem albo spawaczem. Albo alfonsem. Leśniczy jakiegoś tam szczebla też w sumie nieźle trzepie kasiorę.

2

title

1

tak jest w każdym zawodzie. Popatrz na ten przykład na lekarzy ile wśród nich jest konowałów, których wiedza zatrzymała się na 5 roku studiów, z czego połowy już nie pamiętajo. Przykład, brałem antybiotyk, babka przepisuje mi nystatynę i mi mówi żebym brał do tego enterol, co jest idiotyzmem, bo po pierwsze prebiotyki są zabijane przez nystatynę a po drugie nie kolonizują jelit. Enterol stosuje się tylko podczas antybiotykoterapii antybakteryjnej jeśli jest źle tolerowana.
Albo mówię zakaźnikowi, że brałem tarivid (ofloxacyna, generacja chinolinow) a lekarka sie dziwi "co? to jest taki antybiotyk?" i poszła sprawdzić do książki... "no faktycznie..." Zakaźnik!
Albo z opowieści na siłce, ktoś coś miał z nogą, jeden chirurg chciał mu ją amputować. Poszedł do drugiego, odratowali i dzisiaj ma stopę.

Alko polo, disko chłosta - tu jest Polska.
Jak już coś robić to byle jak 
0
Julian_ napisał(a):

tak jest w każdym zawodzie. Popatrz na ten przykład na lekarzy ile wśród nich jest konowałów, których wiedza zatrzymała się na 5 roku studiów, z czego połowy już nie pamiętajo. Przykład, brałem antybiotyk, babka przepisuje mi nystatynę i mi mówi żebym brał do tego enterol, co jest idiotyzmem, bo po pierwsze prebiotyki są zabijane przez nystatynę a po drugie nie kolonizują jelit. Enterol stosuje się tylko podczas antybiotykoterapii antybakteryjnej jeśli jest źle tolerowana.
Albo mówię zakaźnikowi, że brałem tarivid (ofloxacyna, generacja chinolinow) a lekarka sie dziwi "co? to jest taki antybiotyk?" i poszła sprawdzić do książki... "no faktycznie..." Zakaźnik!
Albo z opowieści na siłce, ktoś coś miał z nogą, jeden chirurg chciał mu ją amputować. Poszedł do drugiego, odratowali i dzisiaj ma stopę.

Alko polo, disko chłosta - tu jest Polska.
Jak już coś robić to byle jak 

Jesteś po bootcampie na lekarza czy wtf XD
Pozwól że zacytuję klasyka, ja też zaufałem jednej kobiecie, nawet dałbym sobie za nią rękę uciąć i wiesz co? Teraz bym k***wa nie miał ręki.

1
Zakręcony Szewc napisał(a):

Na projektach zespołowych @studbaza wyszło, że większość z nas klepało sobie cośtam na własną rękę,
myślała, że tworzony kod jest jasny, czysty, ocierający się o genialne pomysły. A w konfrontacji z innymi okazywał się być nieutrzymywalnym gniotem.

To czy dany kod jest utrzymywalny, czy nie, to wychodzi w praniu. Czy da się go utrzymywać w dłuższej perspektywie. Tego można się nauczyć pracując w zespole, ale również robiąc większe projekty samemu.

Chociaż praca w zespole jednak jest cenną nauką, bo grzebiąc w cudzym kodzie najwięcej wszelakiej maści patologii można ujrzeć i antyprzykładów ("jak nie pisać"), a praca komercyjna jako taka (wszystko jedno czy w zespole czy dla kogoś na freelance) to test wytrzymałości ("czy kod wytrzyma kaprysy klienta i zmieniające się co chwila wymagania biznesowe").

I to jest prawdziwy powód, dla którego pisanie do szuflady nie jest wystarczające (pisząc do szuflady, piszesz w warunkach laboratoryjnych, i jesteś w zdanie pisać sterylnie czysty kod), w pracy komercyjnej ten kod naturalnie będzie mniej lub bardziej brudny. Bo taki właśnie ma być. "Done Is Better Than Perfect". Nikt nie ma czasu na to, żeby poświęcać miesiące na szlifowanie jednego modułu.

Więc możliwe, że człowiek, który koduje 2 lata w zespole w korpo będzie pisał lepszy kod, niż świeżak z 10 letnim niekomercyjnym doświadczeniem, któremu się wydaje, że pisze dobrze.

A nie jest często odwrotnie? Praca w (słabym) zespole, w projekcie, gdzie wszyscy kładą lachę, sprawia, że człowiek też zaczyna pisać po łebkach, bo ciężko pisać dopieszczony kod, jak jest super presja czasowa na klepanie, albo jeśli kod po prostu nie może być dopieszczony, bo cały projekt to setki różnych haków, i łatwiej dodać kolejny hak, niż robić masowy refaktor.

A pisząc samemu, bez zespołu i bez presji czasowej, można na spokojnie szlifować swoje kody. Dlatego projekty open source są często lepiej dopieszczone niż te komercyjne, robione szybcikiem, żeby działało.

0

generalnie to jak bym chyba zrobil jakies stopnie spaprania kodu, bo o ile mozna sie bandzlowac i narzekac na slaby kod, ze tam nie przez intefejsy, ze mutowalnosc, ze publiki, ze slabe do testow. To wszystko ok ale jak juz ktos jedzie po bandzie ze zeminnymi jakby tablice mendelejewa kodzil -> fe fs ta ty1 badz wydzielanie method , przeklejaknie tego samoego kodu w x miejsc to juz qrwa sie gotuje

0

A nie jest często odwrotnie? Praca w (słabym) zespole, w projekcie, gdzie wszyscy kładą lachę, sprawia, że człowiek też zaczyna pisać po łebkach, bo ciężko pisać dopieszczony kod, jak jest super presja czasowa na klepanie, albo jeśli kod po prostu nie może być dopieszczony, bo cały projekt to setki różnych haków, i łatwiej dodać kolejny hak, niż robić masowy refaktor.

A pisząc samemu, bez zespołu i bez presji czasowej, można na spokojnie szlifować swoje kody. Dlatego projekty open source są często lepiej dopieszczone niż te komercyjne, robione szybcikiem, żeby działało.

@LukeJL coś w tym jest. Kiedyś bardzo mi zależało na jakości kodu w pracy, i tłumaczyłem, produkowałem się że np. dziedziczenie na ogół to syf i żeby nie nadużywac go, że np. immutabily jest fajna, żeby wprowadzać SOLID ale później stwierdziłem że to nie ma sensu. Jak coś jest nie tak to warto próbowac przekonać innych, a jak się nie da to "dostosować się do innych" a w mięczyczasie szukać nowej pracy ewentualnie. Zreszta to tez jest powód dla którego zmieniłem sposób poszukiwania potencjalnego pracodawcy ;]
Zdecydowanie nie warto za bardzo sie tym przejmować, bo nieuków albo ignorantów nie przekonasz...

0

Jak nie lubisz kodu innych trzeba było wybrać startupy, piszesz sam, raz w takim Ruby i porzucasz.

0

@Pijany Krawiec: Wydaje mi się że Twoja pogarda z SOLIDem a w szczególności O może być związana jest z niskim poczuciem pragmatyzmu w zespole. Open / close może z łatwością prowadzić do przekombinowanego kodu. Uogólnijmy to, dodajmy nowy interfejs, kolejną warstwę - kiedyś przecież się przyda!

Żeby nie być gołosłownym: W moim aktualnym projekcie kiedyś ekhm sam miałem pomysł żeby uogólnić tworzenie ~Dialogów (ekranów z informacją dla użytkownika). W niedalekiej przeszłości wróciłem do "starego" rozwiązania.

Dlaczego wróciłem?

  1. Biznesowa rola naszej aplikacji to nie jest tworzenie dialogów. Dialog był tylko małym trybikiem / częścią całości więc zysk dla całości aplikacji był tutaj marginalny.
  2. Konwencja: we wszystkich innych miejscach w projekcie podejście do zarządzania xmlami ( stąd pochodził szkielet dla widoku) był trochę inny. Jestem ogromnym zwolennikiem konwencji więc tutaj mnie to mierziło że np dla aktywności xml robi tak a dla dialogów stosujemy inne podejście.
  3. Złożoność kognitywna: Po uogólnieniu widoków mieliśmy trzy interfejsy ~Top, Middle, Bottom, dla każdego było kilka implementacji. Zamiast po prostu utworzyć jeden xml dla jednego dialogu musieliśmy tworzyć jeden xml dla dialogu w którym były referencję do innych modułów, jeśli jakiegoś modułu nie było trzeba było go też utworzyć. Oczywiście czasami było tak że dany moduł w miejscu A robił "a" ale w miejscu B już miał robić "abc" więc tę logikę też trzeba było gdzieś umieścić :) Summa summarum to trwało dłużej niż podejście "łopatologiczne".
  4. Uogólnienie tak naprawdę... nie było uogólnieniem: około 80% dialogów było identycznych jednak ilośc kodu była większa z powodu m.in. ze złej architektury.
  5. Na deser: po zmianach w projekcie i usunięciu kilka widoków liczba dialogów zmalała z ~8 do .. 2 które były takie same tylko z różną liczbą przycisków.
0
LukeJL napisał(a):

A pisząc samemu, bez zespołu i bez presji czasowej, można na spokojnie szlifować swoje kody. Dlatego projekty open source są często lepiej dopieszczone niż te komercyjne, robione szybcikiem, żeby działało.

WIększość istotnych projektów "open source" to projekty rozwijane komercyjnie. Radzę pozaglądać do najistotniejszych i zobaczysz Copyrighty multimiliardowych korporacji. To, że na tym forum FLOSS i komercyjne to dla was przeciwne modele jest istnym kuriozum.

0
Pijany Krawiec napisał(a):

Każdy ma trochę inne wyobrażenie, co to jest ładny kod. Ja na przykład gardzę SOLID. W szczególności „O” prowadzi do przekombinowanego kodu, a programiści bojący się refaktorować i usuwać zaszłości są wg mnie słabi.

Scibi92, jak sobie wyobrażasz „wprowadzenie” SOLID w firmie?

Coś w tym jest. Sama modyfikacja istniejących modułów to łamanie O i próbując zachować za wszelką cenę O, raz napisanego modułu nie można byłoby już po prostu ruszyć, a przynajmniej nie w sposób, który by zmieniał coś w istniejącej implementacji i łamał kompatybilność wsteczną.

Tylko, że to trochę utopia. Mało kto pisze idealny kod za pierwszym razem. Dlatego warto wiedzieć, kiedy warto łamać tę zasadę. (ale to jak dla mnie nie świadczy wcale, że Open-Closed nie ma sensu, tylko raczej, że nie ma sensu podążać dogmatycznie za zasadami).

Tak samo Single Responsibility Principle. Czasem lepiej jest zrobić mały moduł, który będzie łamał SRP, ale będzie robił to w prosty sposób, niż napaćkać 10 mikromodułów, które będą się ze sobą łączyć w bardzo przeinżynierowany sposób tylko po to, żeby ktoś mógł cieszyć banana, że zachował SRP dla samego zachowania.

Ale mim wszystko SRP to bardzo pożyteczna zasada, bo umiejętnie zastosowana pozwala uniknąć bajzlu.

Tak samo D - to, że ludzie robią sobie krzywdę przez wstrzykiwanie zależności bez umiaru, wszędzie gdzie to możliwe, nie oznacza to, że Dependency inversion jest złe.

1
Pijany Krawiec napisał(a):

Każdy ma trochę inne wyobrażenie, co to jest ładny kod. Ja na przykład gardzę SOLID. W szczególności „O” prowadzi do przekombinowanego kodu, a programiści bojący się refaktorować i usuwać zaszłości są wg mnie słabi.

Przekombinowany kod tworzą właśnie słaby programiści, a stosowanie Open/Closed Principle nie oznacza lęku przed refaktoryzacją. Jeśli ktoś tak uważa, to nie wie o czym mówi, więc gardzi co najwyżej swoimi perwersyjnymi wyobrażeniami. I słusznie!

2

Już się tłumaczę, dlaczego fetysz SOLID mnie triggeruje.

Uncle Bob o O/C:

Think about that very carefully. If the behaviors of all the modules in your system could be extended, without modifying them, then you could add new features to that system without modifying any old code. The features would be added solely by writing new code.

What’s more, since none of the old code had changed, it would not need to be recompiled, and therefore it would not need to be redeployed. Adding a new feature would involve leaving the old code in place and only deploying the new code, perhaps in a new jar or dll or gem.

Wg mnie, problemy z utrzymaniem, jakich Uncle Bob chce uniknąć, są dzisiaj rzadkością w kodzie jednego lub kilku zespółów. Nie dostarczamy już softu na dyskietkach. Jakoś mnie nie boli konieczność przekompilowania, a nawet zredeployowania aplikacji spring bootowej, skoro i tak mam dodać nowe zachowanie. Wszystko pakuję w fat jara i dostarczam razem z systemem operacyjnym w kontenerze. Kto by się przejmował pojedynczymi jarami. Tak samo, wszystkie SPA sprowadzają się do całkowitego redeploy w przeglądarce.

O/C sugerująca architekturę pluginową jest w pewnym sensie przeciwieństwem YAGNI. Trzeba mieć naprawdę dobry powód, aby oferować extensions w swoim kodzie, a w mojej opini większość programistów przegina w stronę over engineeringu.

1
Pijany Krawiec napisał(a):

Już się tłumaczę, dlaczego fetysz SOLID mnie triggeruje.

Piszesz niby o SOLID, a skupiasz się tylko na jednej zasadzie.

Wg mnie, problemy z utrzymaniem, jakich Uncle Bob chce uniknąć, są dzisiaj rzadkością w kodzie jednego lub kilku zespółów. Nie dostarczamy już softu na dyskietkach. Jakoś mnie nie boli konieczność przekompilowania, a nawet zredeployowania aplikacji spring bootowej, skoro i tak mam dodać nowe zachowanie. Wszystko pakuję w fat jara i dostarczam razem z systemem operacyjnym w kontenerze. Kto by się przejmował pojedynczymi jarami. Tak samo, wszystkie SPA sprowadzają się do całkowitego redeploy w przeglądarce.

No dobrze, tylko refaktoryzacja niepokrytego testami spaghetti kodu może prowadzić do wprowadzenia nowych, trudnych do znalezienia błędów. I o ile to jest problem w monolitach, to "dzisiaj", w epoce mikroserwsiów, może być łatwiej po prostu zrobić nową wersję zamiast naprawiać starą.

Ale mniejsza z tym - OCP nie dotyczy wyłącznie skali modułów, to jest zasada odnosząca się do kodu źródłowego, w szczególności klas. Ktoś, kto gardzi OCP nie używa takich podstawowych wzorców jak strategia, metoda szablonowa, dekorator czy łańcuch odpowiedzialności. W efekcie czego napieprza drabinki pełne ifów, czyli przekombinowany kod, który później trudno rozwijać, więc trzeba refaktoryzować. Czyli najpierw gardząc OCP piszemy słaby kod, który później z pogardy do OCP trzeba naprawiać. (Nie do końca tylko rozumiem jak, nie wprowadzając przy tym OCP przypadkiem w życie.) A jakby tak nie gardzić, tylko od razu robić dobrze?

O/C sugerująca architekturę pluginową jest w pewnym sensie przeciwieństwem YAGNI. Trzeba mieć naprawdę dobry powód, aby oferować extensions w swoim kodzie, a w mojej opini większość programistów przegina w stronę over engineeringu.

Zgadzam się. Tylko nie widziałem jeszcze nikogo, kto próbowałby tak działać.

0

Przecież w OPC nie chodzi o to, żeby nie zmieniać kodu istniejącego.
W OPC chodzi o to żeby nie trzeba było zmieniać kodu istniejącego kodu.
A może nawet żeby nie trzeba było aby ktoś inny musiał ** zmieniać kod po "rozszerzeniu" funkcjonalności.
W sensie, że Pijany Krawiec sobie coś zmieni, inni muszą zapiep
ać, ale jakby co to Pijany Krawiec im powie że są słabi.

2

masz klocek lego A. Wczepiasz go w klocek B.
Złamanie zasady OC przez modyfikację klocka (np. podmiana tych kubików na górze - z okrągłych na kwadratowe) może spowodować to, że nagle klocek A przestanie pasować do klocka B. Dlatego tego nie robimy i dlatego "closed for modification". Możemy natomiast rozszerzyć "działanie" klocka poprzez dodanie kolejnego klocka C (open for extension).

I tym sposobem będziemy mieć klocki A, B, C, które zawsze będą do siebie pasować i nie rozwalą się.

Pijany Krawiec napisał(a):

O/C sugerująca architekturę pluginową jest w pewnym sensie przeciwieństwem YAGNI.
Trzeba mieć naprawdę dobry powód, aby oferować extensions w swoim kodzie,
a w mojej opini większość programistów przegina w stronę over engineeringu.

No nie. Klocki lego zachowują zasadę OC oraz mają architekturę pluginową (gdzie każdy klocek to jak plugin), a nie są przeinżynierowane - mają dość prostą budowę (przynajmniej te zwykłe prostokątne klocki). Nie łamią też zasady YAGNI - wszystko jest po coś, np. te okrągłe kubiki są po to, żeby można było wciskać w nie inne klocki.

Tak samo w idealnym świecie można by tworzyć zupełnie niezależne moduły/klasy, które pasowałyby jak klocki lego do siebie (niestety zrobienie tego na dużą skalę jest trudne. To nie jest tak, że OCP jest zła, tylko, że czasem bywa ciężka do osiągnięcia).

co do przeinżynierowania natomiast to powracając do klocków -
powiedzmy, że ktoś by zrobił "konfigurowalnego klocka lego", który by miał konfigurowalne kubiki (domyślne okrągłe, ale także np. trójkątne, albo o kształcie kota, czy czegokolwiek). Wtedy byłby to overengineering.

Tak samo niektórzy przesadzają i dają w klasach hooki/back doory do tego, żeby modyfikować rzeczy, których pewnie nigdy nie będzie potrzeba modyfikować.

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