Pieprzyć warstwy abstrakcji

Od jakiegoś czasu zbierałem się do napisania tego tekstu, ale nie bardzo mogłem się zebrać, myślałem, że to tylko moje widzimisię, może zmęczony jestem. Ostatnio jednak najpierw trafiłem na ten wpis: What’s Wrong With Object-Oriented Programming? następnie na ten Frameworks, libraries, languages and deconstructing bullshit i to mnie jakoś zmotywowało, poukładało co bym chciał napisać, tak aby inni mogli sobie z tym podyskutować. Tak więc, miłej lektury 🙂

Dawno, dawno temu

Nie wiem jak Wam, ale mnie dawno, dawno temu robienie aplikacji w php (stron, skryptów, bibliotek) dawało niezły „fun”. Nie był to idealny kod (kto wtedy taki robił…), ale pewien poziom trzymał, tj. kompromis między obowiązującą wtedy jakością, a wygodą. Królowała wtedy KohanaPHP, można było w niej sensowne rzeczy robić w miarę prosto i szybko. Poziom abstrakcji był niewielki. Jak ktoś wiedział co robi, to framework mu nie wchodził w paradę. Kod frameworka był ograniczony przez to jak był napisany, ale nasz kod i logika domenowa (o ile takowa była) mogą mieć bardziej skomplikowaną architekturę. Ale nic na siłę – potrzeba coś prostego, proszę bardzo. Aplikacja jest bardziej wymagająca, nie ma sprawy, możesz poszaleć trochę bardziej, byle tylko to co robisz rozwiązywało problem dla którego to programujesz i dawało się potem utrzymywać jeśli to konieczne.

Upadek Kohany

Oczywiście nie chodzi mi tu w sensie dosłownym o sam moment, ale symbol zmian w kodzie, koniec pewnego formatu. Bo gdzie jesteśmy teraz? Dla części społeczności PHP teraz już nie chodzi o kod, działanie, rozwiązywanie czegokolwiek. O nie, to nie ma aż takiego znaczenia. Teraz chodzi o warstwy abstrakcji. Masz fajną bibliotekę, ale nie masz do niej testów, pomimo, że ona nie jest jakaś strasznie skomplikowana – pfff, bez testów to się nie liczy, weź się ogarnij. Korzystasz z Laravela – nie ważne jaki jest Twój kod, sam Laravel ssie, więc lepiej głośno się tym nie chwal, że w nim robisz. Twoja biblioteka to 2 klasy, bo więcej nie potrzebujesz? Stary, na jakim świecie Ty żyjesz, powinieneś to rozdzielić na 5 warstw abstrakcji i gdzie masz interfejsy i DI jak bym chciał którąś warstwę podmienić? Zrobiłeś aplikację, która jest nieco bardziej skomplikowana, fajnie działa? OMG, jest 2016, w czym Ty to zrobiłeś, trzeba było użyć Symfony i Doctrine, jak Ty robisz formularze, czemu nie używasz Twiga…

Krajobraz po bitwie

Sporo osób tak to teraz widzi: pełna profeska, DDD, masa abstrakcji, Symfony i Doctrine zawsze i wszędzie. Nie ważne jaki jest Twój kod, ważne z jakiego narzędzia korzystasz. Jak ze złego (np. Laravel) to reszta nie ma już znaczenia. Framework to już nie tylko narzędzie, które pomaga robić aplikacje. To cały kombajn, który determinuje Ciebie, Twój kod, całą stworzoną aplikację. A przynajmniej takie jest częste spojrzenie na frameworki, „dajcie mi aplikację w Laravelu, a się pośmiejemy”, ale Symfony to wiecie, szacun i merytoryczne uwagi co można zrobić lepiej. Nikt nie patrzy na samą aplikację, że fajnie działa i pokrywa 100% zapotrzebowania na funkcjonalności – Laravel albo singleton i jesteś nikim, tworzysz śmieszny kod w pseudoframeworku. Jeśli stworzysz bibliotekę, a nie jest ona idealna jeśli chodzi o abstrakcję, wzorce projektowe, DI itd to lepiej zachowaj ją dla siebie.

Nie dajmy się zwariować

No właśnie, nie dajmy się zwariować. Z jednej strony coraz więcej aplikacji online ma rozbudowany backend i tam nie ma miejsca na kompromisy, bez odpowiedniej abstrakcji i dobrego frameworka można robić zakłady kiedy będzie konieczne przepisanie tego od nowa, bo na pewno będzie. Dobry framework, który wymusza pewne praktyki i umożliwia nadpisanie różnych funkcjonalności jest bezcenny i tu nie ma co dyskutować. Podział na Bundle plus Compiler Passes daje prawie duże możliwości. Ale jest też druga strona – cała masa aplikacji, które tego nie potrzebują, klient chciał, klient dostał, wszyscy zadowoleni. Nikogo nie obchodzi to, że następna wersja Laravela będzie miała jakieś niezapowiedziane BC, ważne, że to co chciałem, to zrobiłem szybko i sprawnie, a wszystko działa tak jak trzeba. To nie system do podtrzymywania akcji serca, tylko strona dla klienta, taki tam mini sklep. Pieprzyć zbędne warstwy abstrakcji, bo one tutaj nie są do niczego potrzebne. Tak samo w tych kilku małych bibliotekach, które dla potrzeby tego projektu zrobiłem, a pewno je wykorzystam w innych projektach również. A jak będzie potrzeba, to je rozbuduję. Nie dajmy się zwariować, wmówić sobie, że wszystko zawsze musi być SOLID, najlepiej z DDD, bo inaczej to nie jest nic warte. Ale nie przesadzajmy też w drugą stronę – robię byle jaki kod, bo działa, a klient się nie czepia. Nie o to chodzi. Chodzi o pewien umiar, złoty środek. SRP, KISS, DRY (plus DI/DIC) to podstawa, którą warto w sobie wypracować, reszta to pole do dyskusji odnośnie konkretnego projektu i sytuacji (deadline).

To tylko zabawki

Framework to nie święty grall, tylko zwykłe narzędzie. Oczywiście, jak ktoś zna tylko młotek, to wszędzie widzi gwoździe, Symfony jest najlepsze do wszystkiego itd. Ale prawda jest taka, że do jednych aplikacji lepiej jest użyć Laravela, do innych Symfony, a do jeszcze innych WordPress / Presta / Joomla. A czasami jakiś micro framework. Ale nie, dla wielu to nie do pomyślenia, robić aplikacje w Symfony i Laravelu, w zależności od potrzeb. To tylko narzędzia, a nie religia, jak wyznaję jedną, to się jej trzymam i nie interesują mnie inne. Tak samo jest z warstwami abstrakcji, nie zawsze są nam potrzebne w swojej idealnej postaci, zazwyczaj wystarczy pewien kompromis. A to jaki kompromis to już zależy – jeśli robimy własny duży projekt, który będzie wymagał długoterminowego wsparcia, to miejsca na kompromis jest raczej mało 😉

Konkluzja

Nie bądźmy zakładnikami perfekcjonizmu. Wszystko co robimy ma kontekst tego po co to jest robione i co z tym się będzie dalej działo – jak zostanie zaorane po zakończeniu kampanii reklamowej, to dużo rzeczy nie ma sensu. Programowanie obiektowe jest fajne, ale niech kolejne warstwy abstrakcji nie przesłonią nam samego kodu i tego co ma on zrobić. Można uprawiać sztukę dla sztuki, tylko po co? I tak nie przewidzimy wszystkiego, jak na przestrzeni lat będzie się zmieniać nasza aplikacja, jak będzie dalej wyglądał framework na którym ją oparliśmy, jakie BC będą w zewnętrznych bibliotekach z których korzystamy (a im więcej ich mamy, tym większe piekiełko nam się szykuje w skali długoterminowej). Framework to tylko narzędzie, jak mamy coś większego swojego, to bardzo możliwe, że nadal jesteśmy na Symfony 1.x, albo 2.4 bo za dużo by nas kosztowało przepisywanie swoich i cudzych bundli na 3.0 – takie życie. Często nie wiemy jak dalej będzie się rozwijała nasza aplikacja, jakie wymagania będą mieli klienci, co będziemy musieli zaimplementować, ile obecnych koncepcji będzie musiało ulec zmianie, bo nowe wymagania. Dajmy sobie trochę luzu, takie MVP w kwestii kodowania. Na prawdę, nie musimy wszystkiego mieć by-the-book od razu i dajmy takie samo prawo innym. Nie oceniajmy tylko „a bo nie ma testów, a bo to Laravel, a bo nie jest SOLID”. Ważny jest też kontekst konkretnej aplikacji, a nie sam kod oderwany od niej.

Na zakończenie, drodzy koledzy i koleżanki – pieprzyć warstwy abstrakcji: nie dajmy się zwariować, nie zapominajmy, w kiepskich frameworkach powstało wiele kiepskich aplikacji, które dziwnym trafem działały, działają, a klienci na nich zarabiają i są zadowoleni. Pszypadek? Nie sondzem… 😉

Freelancer, programista php, wiecznie niezadowolony ze swojego kodu. Toleruje frontend, kocha backend, miłośnik integracji :)

  • RRR

    „Dawno dawno temu” to nie było frameworków ani nawet OOP w PHP, a nie „Królowała wtedy Kohana” 😉

    Generalnie z resztą się zgadzam.

    https://github.com/Herzult/SimplePHPEasyPlus <- tak to zaczyna wyglądać 🙂

  • aPoCoMiLogin

    Cóż taka ludzka natura, że się utożsamiamy z narzędziami, aplikacjami, systemami, przedmiotami itp które wypełniają nasze życie, bo w pewien sposób opisują nas. Tyle że dla niektórych to jest zbyt dosłowne, przez co powstają wojny.

    Co do prostoty, osobiście mam wielką awersję do większych systemów szablonów, a rozpoczął to chyba smarty i potworki w tym tworzone. Kilka klas do stworzenia prostego formularza z paroma inputami ? Zawsze mnie to w SF dobijało.

    Całe szczęście, sporo rzeczy się zmienia i idzie w innym kierunku. Frontend to głównie JS’ie, a wszystko po stronie backendu serwuje głównie restowe endpointy. Chociaż w JS’ie też jest sporo takich potworków, ale jest też kilka projektów które swoją prostotą, która nie wpływa negatywnie na możliwości, przyciągają całkiem sporo ludzi.

  • Satyr

    Po prostu programiści php byli od zawsze traktowani jako podprogramisci (ten słynny najkrótszy dowcip swiata) więc teraz gdy język wspiera obiektowosc muszą sobie coś udowodnić.

  • Tomasz Szymanek

    Kolega widocznie nie rozumie dlaczego Laravel jest kiepskim pomysłem, a dlaczego hasło „Symfony” wcale nie oznacza korzystania z całego frameworka. Ja też poznałem ludzi takich jak autor. Co więcej przez całe lata za ciężkie pieniądze klienta, przy dźwiękach stłumionych przekleństw pod ich adresem, poprawiałem po nich kod, który kiedyś „nie musiał być modularny, nie musiał być SOLID, nie musiał mieć piątej warstwy abstrakcji”.

    Wbrew powszechnej opinii żeby pisać dobry kod wcale nie trzeba się narobić,
    za to trzeba dużo wiedzieć.

    • thejw23

      „Kolega widocznie nie rozumie dlaczego Laravel jest kiepskim pomysłem”. I właśnie to jest książkowy przykład o co mi chodzi 😉 Nie rozmawiamy o jakimś konkretnym przypadku aplikacji, ale Laravel jest kiepski i już, nie ma znaczenia co z jego pomocą chcemy zrobić, na pewno nie będzie to dobre. To tak jak by oceniać stronę po tym, że jest postawiona na WordPress, więc nie może być dobra, ładna, klient zadowolony i na pewno jej programista jest kiepski, bo to WordPress. A co do reszty komentarza – nie wiem czy zrozumiałeś o co mi chodziło w tym tekście. To nie jest tekst o tym, że należy pisać kiepski kod i twierdzić, że nie potrzebujemy lepszego. Że wzorce są przereklamowane, OOP to zło, a myślenie przy programowaniu boli, więc lepiej tego nie róbmy. To jest tekst o umiarze, złotym środku i wyrozumiałości dla innych. I w pełni się zgadzam, że trzeba dużo wiedzieć, bo tylko wtedy wiemy którymi skrótami warto iść, bo dzięki nim można zrobić za jakiś czas niewielki refaktoring i dodać kolejną warstwę abstrakcji jeśli będzie potrzebna, a inne skróty często wynikające z niewiedzy kończą się „przy dźwiękach stłumionych przekleństw”. Ale tak samo kończą się zmiany wynikające z tego, że są nowe requesty od klientów, których wcześniej nikt nie przewidział, że tak w ich dotychczasowym systemie to działa i nasze warstwy abstrakcji trzeba mocno przeorać, albo iść na skróty „ten jeden raz, przecież więcej takich zmian nie będzie”, a to duży klient, więc musimy naszą aplikację pod niego dostosować… 😉

      • aPoCoMiLogin

        Akurat wordpress jest bardzo złym przykładem, dlatego że to jest na prawdę kiepski kod. Większość „popularnych” cms’ów pokroju wordpressa to niestety rak.

        Jest różnica między tworzeniem na siłę rozwiązań (kilkunastoklasowe liby do wyświetlenia formularza), a rozwiązaniami zwyczajnie biednymi, stworzonymi dla niedzielnych programistów. Nie dajmy się zgłupieć powinno działać w obie strony..

        • thejw23

          WP jest tu dobrym przykładem. Nie ma znaczenia czy sam WP jest dobry czy zły to tylko narzędzie. Masa ludzi stawia na tym strony i jest ok. Klient chce, klient dostaje, nikt nie wnika w detale, nie wytyka „buahahah, na WP to postawił…” a przecież wiadomo, że Laravel jest poza skalą lepiej napisany niż WP. Wszyscy wiedzą, że to tylko taka tam stronka i jest ok. Ale jak zamiast na WP postawisz coś na Laravelu, to niewiedzieć czemu nagle nie ma znaczenia co postawiłeś, bo „Laravel jest kiepskim pomysłem”. Nagle to już nie tylko narzędzie, nikt nie pyta o aplikację, po co, na co, co z tym dalej itd, nie, to już nie ma znaczenia, załącza się metafizyka i koniec, nie pogadasz 😉 I nie ważne, że WP i Laravel to dokładnie takie same narzędzia w rękach programisty, paczki kodu z którym możesz coś zrobić 🙂

          • aPoCoMiLogin

            To że masa ludzi stawia na tym strony o niczym nie świadczy. Jedzmy gówno, przecież miliardy much nie mogą się mylić.

            Problem WP jest po prostu bardzo niska jakość kodu, już nie samego WP (chociaż tutaj jest bardzo dużo do zarzucenia), ale głównie wtyczek, czy szablonów. A jak już samemu masz pisać wszystkie wtyczki to lepiej skorzystać z frameworka, niż taplać się w tym badziewiu.

            WP i laravel to zupełnie innej klasy narzędzia. WP jest tworzone dla ludzi którzy są na bakier z wszelkiej maści standardami, dobrymi praktykami, o bezpieczeństwie nie wspominając. Więc nawet nie ma co porównywać w tej kwestii WP do LV.

          • thejw23

            „WP jest tworzone dla ludzi którzy są na bakier z wszelkiej maści standardami, dobrymi praktykami, o bezpieczeństwie nie wspominając. ” Nie. WP jest tworzone po to aby szybko postawić bloga jeśli spełnia on (WP) wszystkie wymagania projektu. I tyle. Nie ma znaczenia, że jest słabo napisany. A Jeśli nie spełnia w danym projekcie – proszę bardzo, albo wtyczkę piszemy i jest ok, albo inny skrypt, albo framework i robimy wersję specjalnie dla klienta – zależnie od potrzeb w danym konkretnym przypadku. I o to mi chodzi, to tylko narzędzia, nie powinno się ich oceniach bez kontekstu projektu, bo to nie ma sensu.

          • aPoCoMiLogin

            Nie. WP jest tworzone po to aby szybko postawić bloga jeśli spełnia on (WP) wszystkie wymagania projektu.

            Jeżeli masz brak wymagań, to na pewno spełnia je wszystkie..

            To co ja tutaj widzę to hiperbola. Mówisz o nie ogłupianiu się, ale uważasz wordpressa za coś dobrego, kiedy każdy jeden programista powinien krytykować potwory pokroju wordpressa. Jest różnica pomiędzy strzelaniem z armaty do komara (do prostego formularza użycie kilku bibliotek), a zwyczajnym podjechaniu szambowozem pod firmę i wylaniem całej jego zawartości do biura. To jak zachwalanie mega awaryjnego samochodu, bo spełnia swoje wymagania w większości przypadków, a że gdzieś tam czasami ulegnie awarii, to można przeboleć, bo przecież to tylko awaria..

            Sorry, ale nie ma żadnego argumentu za użyciem WP, a twierdzenie że nadaje się idealnie, zawsze jest do pierwszego włamu.

            mi się nigdy nikt nie włamał!

            mi do domu nikt się również jeszcze nie włamał, ale nie będę zostawiał otwartych drzwi wychodząc do pracy.

            Rozumiem że jesteś freelancerem, że zarabiasz na „instalowaniu” ludziom wordpresów, czy tworzeniem do tego jakichś dodatków. Ja takich ludzi niestety ale postrzegam jak mirków z komisu samochodowego, co wyklepali powypadkowe auto i sprzedają jako „nówkę”, „niemiec do granicy biegł i płakał”. Ale bądźmy poważni, bo przez takie potworki pokroju tych wszystkich CMS’ów ala wordpress czy joomla jest mega nagonka na php.

          • thejw23

            Dla mnie PHP to nie religia, nie przeszkadza mi nagonka – wystarczy, że język się rozwija, ma coraz większe możliwości. Mam narzędzia zarówno do prostych stronek, jak i do tych bardziej skomplikowanych aplikacji. Dla każdego coś się znajdzie. Nie przeszkadza mi, że ludzie stawiają strony na WP, robią rzeczy w Laravelu, instalują Joomlę (którą ja osobiście stawiam jakościowo znacznie niżej niż WP) itd. Ktoś inny postawi sobie backendowy serwis REST, a admina do tego zrobi na Angularze czy React plus kilka prostych stron statycznych na Slim/Silex zaciągających dane z tego samego webserwisu, albo bezpośrednio z bazy. Niech każdy się bawi tak jak lubi, to tylko narzędzia.

          • aPoCoMiLogin

            Jest spora różnica między „nie dajmy się zwariować” o którym piszesz, a wariactwem jakim jest proponowanie klientowi jednego z najbardziej rozpoznawalnych systemów blogowych, który jednocześnie jest bardzo sławny dzięki ilości podatności jakie w nim występowały czy występują.

            Nie dajmy się zwariować – nie bierzmy się za wbijanie gwoździa młotem pneumatycznym, ale również nie wbijajmy tego gwoździa kapciem kubota.

            Nie będę próbować cię przekonywać, bo za twoimi racjami przemawiają ludzie którzy płacą ci za „instalowanie” wordpressa. Więc EOT.

          • thejw23

            To nie tak, ja na WP postawiłem jedną stronę, w czasie kiedy był w wersji 2.6 czy 2.8, w każdym razie dawno i WP był wymaganiem klienta (już go miał i nie chciał zmieniać). Strona była mocno personalizowana, więc wiem jak to jest pisać pluginy do WP aby klient miał swój CRUD w adminie i inne cuda. Ostatnio znajoma potrzebowała galerii, poleciłem jej prosty skrypt, gotowiec (akurat nie WP). Inny znajomy chciał portfolio z galerią – sam zainstalował WP z pluginami, bez pomocy programistów. Strona firmowa, prosta – zainstalowali WP i są zadowoleni. Sami. Dużo osób dookoła mnie stawia strony na WP, samodzielnie i one działają, nikt im się nie włamuje, nie mają problemów. Kompletnie nie rozumiem dlaczego ci ludzie mieliby instalować coś innego, tylko dlatego, że WP jest słabo napisany? Dlaczego mam ich przekonywać, że „tak, to działa, jest fajne, ale wiecie, to jest _zuo_, postawcie strony na czymś innym”? Mam im coś sam zrobić, aby było bardziej PRO i zgarnąć za to kasę? W imię czego? Szanuję innych, ich pieniądze, swój czas – jeśli WP pokrywa czyjeś zapotrzebowania w 100% to nie widzę powodu dla którego miałbym robić coś swojego. Niech tylko aktualizują WP i pluginy.

            Nie dajmy się zwariować, nie każdy potrzebuje systemu dedykowanego. Idąc tym tokiem myślenia, to trzeba by klientom pisać blogi, fora, sklepy (przecież na Presta chyba nie postawisz…) i zgarniać ciężką kasę… Chociaż taka wizja ma swoje plusy, nie da się ukryć 🙂

      • Tomasz Szymanek
    • aPoCoMiLogin

      Dlaczego laravel jest kiepskim pomysłem? nie robię w PHP już od jakiegoś czasu, swoją przygodę z nim skończyłem na pierwszych wersjach symfony 2 i początkach laravela. Więc chętnie nawet z czystej ciekawości dowiem się co jest takiego kiepskiego w tym FW.

  • Tomasz Budzyński

    Albo jesteś frejmowcem albo programistą. Wybór należy do Ciebie.
    @tomasz_szymanek:disqus pamiętaj nie ma nic gorszego niż przedwczesna optymalizacja i modularność. Prawie jak faszyzm.

  • Aleksander Ciesiołkiewicz

    W kwestii apek robionych na 5 minut (kampanie reklamowe) to to może i ma sens.
    Gorzej jak robimy coś, co prawdopodobnie będzie żyć dłużej i od początku będzie chaos.

    O ile programiści są ogarnięci i nikt ich z nahajką nie popędza to zrobiwszy MVP będą oni inkrementalnie robić refactoring, poprawiać architekrutę, kawałek po kawałku rozbijać kodzik aplikacji na abstrakcje.

    Niestety często tak nie jest. Widziałem np. devów dość ogarniętych w PHP, którzy musieli dorabiać jakieś funkcjonalności na froncie. I tam już nie było niczego – architektury, standardów, testów jednostkowych (w js? phi!). Była za to kupa bugów powodowana głównie singletonowością całego rozwiązania, brak czytelności jakiejkolwiek (brak typowania, jsdoców, separacji odpowiedzialności, niczego) i duże niezadowolenie userów.

    Konkluzja.

    Prototypowanie i szybkie rozwiązania są spoko – o ile są na chwilę i przepiszesz ten prototyp jak tylko zacznie żyć. Inaczej brak dobrej architektury szybko się zemści i obróci przeciwko Tobie.

    P.S. Z każdym frameworkiem i każdym językiem można popełnić ch*jowy kod 😀

  • Aleksander Ciesiołkiewicz

    P.P.S.: „Na zakończenie, drodzy koledzy i koleżanki – pieprzyć warstwy abstrakcji: nie dajmy się zwariować, nie zapominajmy, w kiepskich frameworkach powstało wiele kiepskich aplikacji, które dziwnym trafem działały, działają, a klienci na nich zarabiają i są zadowoleni. Pszypadek? Nie sondzem… 😉”

    Wujek Bob w swojej słynnej książce przytaczał przypadek odwrotny ;]

  • Kamil Franckiewicz

    Dobry artykuł. Od siebie jeszcze dodam, że najważniejsze i najtrudniejsze to zdobyć wymagania od klientów. Właściwie to one decydują o wyborze odpowiedniego ‚narzędzia’ wspomagającego pracę. Czasami warto też poświęcić więcej czasu na prace związane z otoczką projektu niż na samo programowanie, aby później realizacja zagadnień była szybsza i dokładniejsza.

  • HoRacy Jurkiewicz

    @grrzes: Bardzo możliwe, że te same miernoty będą w pojedynkę (frontend, backend, serwery, wszystko!) ciągnąć swe projekty w gównoframeworku i nie będą się specjalnie spinać niczym, dopóki działa i zarabia duże pieniądze do klienta. Niestety tak wygląda rzeczywistość. Większość projektów, które gdzieś reanimowałem po np. 5-6 latach na rynku, były napisane bez frameworka, a cała aplikacja była bezpośrednio w widokach. Rak, koszmar. Ale przynosiły miliony przychodu i nie było konieczności ruszać tego nowotworu, bo jednak funkcjonował.
    Dla klienta nie liczył się refactoring (bo przecież działa), a implementacja nowych funkcji, które dadzą mu realną przewagę biznesową. Szybko, skutecznie i stosunkowo tanio.

    Zauważyłem też, że większość ambasadorów JEDYNEJ SŁUSZNEJ RELIGII FRAMEWORKOWEJ, komplikowania wszystkiego, używania pierdyliarda warstw abstrakcji do gównoczynności (prawie jak – https://github.com/Herzult/SimplePHPEasyPlus) żyją w totalnym oderwaniu od rzeczywistości rynkowej – zamknięci w swoich korpo z projektami z nieograniczonym budżetem finansowym, zasobami ludzkimi i marnotrawieniem czasu na korpospotkania i eskalowaniem czasowo każdego najmniejszego problemu do rangi tych największych. A największy to zwykle ten – czy produkt jest skuteczny i czy zarabia.

    A nie korpoprojekty, gównousługi, projektowane zwykle za publiczne pieniądze, fasady zaprojektowane by przeżreć jak największą ilość publicznych (lub korporacyjnych) pieniędzy, by potem spokojnie się zamknąć, bo idealnie napisany SAAS był po prostu głupi (choć marketingowo idealnie nadmuchany i zoptymalizowany, że ja pierdolę).

Send this to friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL