#chujozord

@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 d⁎⁎y 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ą.

pisanie dobrego kodu w frameworku jest równie ważne co i bez niego, to wciąż powód do dumy :grinning: 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.

Powiedział bym: no teraz to wysram się za wszystkie czasy. Dziękuję synek.

Nic nie mowie. Ide SRAĆ!

I cake jest dwa razy otwarty zamiast zamknięcia

@r00tku bo to porzadny kod czyli z bledami