@CHUJOZORD jak miałem pięcioraczki to tak robiły

@nikko-audu xDDDDDDDDDDDDDDDDDDDDDD

@CHUJOZORD nie zgadzam się z zamieszczoną tutaj ryciną

@Dosgrjs najbardziej męska rzecz to seks pomiędzy dwoma facetami

@DonkeyKong nie wszyscy tak mają. Popatrz sobie na open source, jest tam masa przykładów świetnie napisanego oprogramowania utrzymywanego latami w dobrym stanie i dobrej jakości. Ja sam pracowałem w kilku miejscach, w których dbano o wysoką jakość kodu, to nie zawsze oznacza że cały kod jest wysokiej jakości, ale zawsze oznacza, że tę jakość się stale podnosi, a nie pogarsza.

Dobra architektura rzeczywiście często wymaga dodatkowej pracy, ale brak architektury powoduje tendencję do powstawania tzw. Big Ball of Mud i w konsekwencji nie tylko olbrzymiego wydłużenia czasu realizacji zadań, ale także masy błędów w środowisku produkcyjnym.

Nie ma też znaczenia ile lat siedzisz w tej branży, znałem programistę z dziesięcioletnim doświadczeniem, który był na poziomie juniora, bo spędził 10 lat w jednej firmie i dłubał w kodzie aplikacji opartych o Wordpressa. To, co mówisz o jakości i architekturze sugeruje, że nie pracujesz w otoczeniu sprzyjającym rozwojowi.

Architektura oprogramowania to nie jest prosta dziedzina i nauczenie się tych zagadnień nie jest takie łatwe jak nauczenie się programowania ogólnie. To powoduje, że w środowisku funkcjonuje bardzo dużo błędnych przekonań i dużo "wannabe" architektów, którzy rzeczywiście powodują to, co mówisz. Zrozumienie czemu ludzie tacy, jak Eric Evans, Martin Fowler czy Robert Martin mówią to, co mówią, wymaga poświęcenia wielu lat na zrozumienie. Stąd właśnie takie problemy, o jakich wspomniałeś, ale to, że Ty nie trafiłeś na dobre środowisko pracy, w którym dba się o jakość nie pogarszając jednocześnie produktywności nie oznacza, że takie środowisko nie może istnieć. Z mojego doświadczenia wynika, że to właśnie zaniedbanie architektury i jakości zabija produktywność, tylko robi to po jakimś czasie, stąd systemy pisane w stylu "czas napierdalania" mają zwykle krótki cykl życia, bo prędzej czy później zespół decyduje, że to gówno trzeba przepisać od zera. Problem tylko w tym, że robi to ten sam zespół, więc ten przepisany od zera system po dwóch latach znowu będzie musiał zostać przepisany od zera. I jest to dużo bardziej kosztowne od poświęcenia dodatkowego czasu na napisanie testów albo skonstruowanie przemyślanej architektury.

@PanPaweuDrugi zaskoczę cię, ale aktualnie jestem w projekcie w którym całkiem sporo rzeczy jest refaktorowanych lub przepisywanych i generalnie się nas do tego zachęca. Problem w tym że zawsze wiąże się to z ryzykiem że obecne testy niekoniecznie pokrywają całą funkcjonalność, a wypuszczenie czegoś co właściwie nie zmienia funkcjonalności i jest tylko przerobieniem istniejących rzeczy to ryzyko którego biznes nie lubi podejmować bo im wszystko działa i bez tego. Ja także takiego ryzyka nie lubię bo jak coś się spierdoli to ja jestem za to odpowiedzialny i to ja to muszę naprawiać.

Takie ryzyko trzeba jakoś uargumentować i zazwyczaj argumentem jest tu nowa technologia dzięki której można cośtam szybciej lepiej fajniej. Otwiera to zupełnie nową puszkę pandory i robi dodatkowe problemy bo nawet po jakimśtam szkoleniu wszyscy znają tą nową technologię co najwyżej powierzchownie i jak pojawia się jakiś bardziej skomplikowany problem to człowiek ma ochotę to wszystko rzucić i nigdy więcej nie dotknąć komputera w swoim życiu. Im dłużej mam styczność z takimi tworami tym bardziej jestem otwarty na tzw. legacy code i grzebanie w starym systemie zamiast wprowadzania nowych rzeczy bo tak jest po prostu łatwiej a i biznes jest zadowolony bo dalej mogą robić swoje biznesowe rzeczy.

Liznąłem już w swojej karierze sporo projektów w różnych firmach i moje zdanie jest takie że przepisywanie czegoś przez nowy zespół to zazwyczaj masakra, bo nie ma już nikogo kto zna projekt więc nie ma kontekstu dla istniejącego kodu. Kończy się to więc długotrwałym reverse engineeringiem i odkrywaniem różnorakich niespodzianek pozostawionych przez poprzedników. Rezultat jest taki że powstaje produkt którego funkcjonalność jest właściwie identyczna jak poprzedniego produktu, tylko przy okazji ma nowe bugi. Bugi które ktoś taki jak ja musi naprawiać mając przeświadczenie że w sumie to istnieje już program który robi identyczne rzeczy i działa bez zarzutu tylko z jakiegoś powodu stwierdziliśmy że jest do dupy bo ktoś napisał jakiś kawałek kodu w sposób który nam się nie podobał. I zdarza się że takie fixy dzieją się po godzinach mojej pracy, czyli w momenie w którym z chęcią robiłbym coś innego. Męczy mnie już taka masturbacja kodem bo niejednokrotnie już się okazało że nowe rozwiązanie niekoniecznie jest lepsze od starego i tylko robi nam pod górę.

O Fowlerze mam negatywne zdanie i ten artykuł wyjaśnia dlaczego nie warto go polecać: https://qntm.org/clean

Staram się być jak najlepszy w tym co robię i stosować się do dobrych praktyk, ale nauczyłem się że czasem warto pójść na kompromis i zaakceptować kod który może i nie jest napisany najlepiej ale spełnia wymagania i robi to co ma robić. Ostatecznym celem pisania programów komputerowych jest pomaganie innym zrobić coś łatwiej i szybciej, a nie piękny kod i dążenie do perfekcji w tym zakresie wydaje mi się syzyfową pracą.

Takie ryzyko trzeba jakoś uargumentować i zazwyczaj argumentem jest tu nowa technologia dzięki której można cośtam szybciej lepiej fajniej.

@DonkeyKong jest to beznadziejny argument, system nie powinien być przepisywany bo programiści chcą się pobawić nowymi zabawkami, a ja w kwestii dbania o jakość mówię o takim podejściu, które pozwoli na jak najdłuższy rozwój bez przepisywania.

Poprawne argumenty do przepisania systemu to:

1. Stan kodu jest tak zły, że proste zadania zajmują masę czasu i powodują powstawanie dużej ilości błędów.
   

2. Obecna platforma lub architektura nie pozwala na implementację nowych wymagań biznesu i nie da się ich wdrożyć.
   

3. Obecna platforma przestała być wspierana przez producenta i nie ma nikogo, kto by łatał krytyczne luki bezpieczeństwa.
   

I jeżeli punkt pierwszy jest powodem przepisywania, to trzeba zadać sobie kluczowe pytanie: jak do tego doszło? No i tutaj właśnie wchodzi kwestia dbania o jakość, bo jeśli stan techniczny systemu jest tak zły, że koszt jego dalszego rozwoju zaczyna przekraczać koszt jego przepisania, to znaczy że nikt o tę jakość nie dbał.

Wydaje mi się, że nie dotarła do Ciebie istota tego, co mówię: dbanie o jakość to kwestia pragmatyzmu, którego celem jest obniżenie kosztów utrzymania i rozwoju systemu, a nie jakiś "hype driven development". Architektura powinna być dobrana do zastosowania, nie twierdzę, że monolityczny CRUD napisany w MVC dookoła schematu bazy na formularzach wygenerowanych przez framework to zła architektura. Ona może być zła, jeśli ktoś zastosował ją dla systemu obsługującego wiele firm, który ma bardzo złożoną dziedzinę biznesową, bo to pociąga za sobą dużą ilość logiki biznesowej, dla której nie ma miejsca w tej architekturze, a jak ktoś zaczyna ją tam pakować, to kończy się właśnie tak, jak piszę: ktoś w końcu sfrustrowany czterdziestym bugiem w prostym zadaniu walnie pięścią w blat i stwierdzi, że to trzeba przepisać.

Poczytaj sobie np. o takim DDD, ono jest zorientowane wokół biznesu i nastawione na maksymalną izolację tego, co istotne od bibliotek i frameworków, ta architektura zastosowana w przypadku wspomnianego przeze mnie systemu zapewni dużo dłuższy czas utrzymania przy relatywnie niewielkim nakładzie pracy. Natomiast próba wdrożenia jej w scenariuszu dla CRUDa wydłuży czas realizacji czegokolwiek wielokrotnie, po pierwsze ze względu na spory boilerplate przy anemicznej logice biznesowej, a po drugie dlatego, że programista zamiast kodować, będzie się drapał po głowie myśląc o tym, co tu właściwie napisać, bo mi mówili, że agregat jest rdzeniem aplikacji, a u niego to jest pusta klasa z dwudziestoma własnościami i jedną metodą.

Liznąłem już w swojej karierze sporo projektów w różnych firmach i moje zdanie jest takie że przepisywanie czegoś przez nowy zespół to zazwyczaj masakra, bo nie ma już nikogo kto zna projekt więc nie ma kontekstu dla istniejącego kodu. Kończy się to więc długotrwałym reverse engineeringiem i odkrywaniem różnorakich niespodzianek pozostawionych przez poprzedników

Amen! Mam takie same doświadczenia i to właśnie one doprowadziły mnie do refleksji, że o wysoką jakość należy dbać stale, a nie pracować z podejściem "wszystko co wypchnięte do repo staje się legacy".

Męczy mnie już taka masturbacja kodem bo niejednokrotnie już się okazało że nowe rozwiązanie niekoniecznie jest lepsze od starego i tylko robi nam pod górę.

Masz w takim razie zadatki na dobrego architekta, bo jesteś pragmatyczny, a to jest niezbędna cecha u osoby odpowiedzialnej za projektowanie systemu. Ale dopóki będziesz się trzymał stwierdzenia, że dbanie o jakość to bullshit dla studentów, niestety lepiej się za robotę projektową nie brać.

O Fowlerze mam negatywne zdanie i ten artykuł wyjaśnia dlaczego nie warto go polecać: https://qntm.org/clean

O Martine, Czysty Kod nie jest Fowlera. Ale to bez znaczenia, po pierwsze podałem go jako przykład, a po drugie każdy czasem się myli, a wiele twierdzeń, które zostały napisane w książkach, po latach jest obalanych.

Staram się być jak najlepszy w tym co robię i stosować się do dobrych praktyk, ale nauczyłem się że czasem warto pójść na kompromis i zaakceptować kod który może i nie jest napisany najlepiej ale spełnia wymagania i robi to co ma robić.

Kompromis jest nieodłącznym elementem tworzenia softu, a jednym z zadań dobrego projektu jest odizolowanie tego kompromisu tak, aby nie wpłynął negatywnie na inne części aplikacji.

Ostatecznym celem pisania programów komputerowych jest pomaganie innym zrobić coś łatwiej i szybciej, a nie piękny kod i dążenie do perfekcji w tym zakresie wydaje mi się syzyfową pracą.

I to są bardzo prawdziwe słowa, nie ma idealnego kodu, próbując go stworzyć będziemy w nieskończoność refactorować ten sam kod, a aplikacja nie powstanie nigdy. Ale nie mam pojęcia w jaki sposób miałoby to sprawić, że dobra architektura jest bezużyteczna i kontrproduktywna.

pisanie dobrego kodu w frameworku jest równie ważne co i bez niego, to wciąż powód do dumy Zwłaszcza gdy nie piszesz dla siebie, a dla klienta, gdzie kod musi byc napisany jak najmniejszym kosztem, ma działać i jednocześnie być prosty do refactoringu

Jak się nie dziali zadania na mniejsze i nie pracuje etapami to tak jest.