eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingWeb development › Re: Web development
  • X-Received: by 2002:ac8:c0d:: with SMTP id k13mr12368094qti.136.1590087790192; Thu,
    21 May 2020 12:03:10 -0700 (PDT)
    X-Received: by 2002:ac8:c0d:: with SMTP id k13mr12368094qti.136.1590087790192; Thu,
    21 May 2020 12:03:10 -0700 (PDT)
    Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!2.eu.feeder.erj
    e.net!feeder.erje.net!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenete
    xpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.gigan
    ews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.g
    ooglegroups.com!not-for-mail
    Newsgroups: pl.comp.programming
    Date: Thu, 21 May 2020 12:03:09 -0700 (PDT)
    In-Reply-To: <1...@t...com>
    Complaints-To: g...@g...com
    Injection-Info: google-groups.googlegroups.com; posting-host=213.108.152.51;
    posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
    NNTP-Posting-Host: 213.108.152.51
    References: <2...@g...com>
    <20200519113017.4d559ff4@mateusz>
    <3...@g...com>
    <1...@t...com>
    <3...@g...com>
    <1...@t...com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <e...@g...com>
    Subject: Re: Web development
    From: Maciej Sobczak <s...@g...com>
    Injection-Date: Thu, 21 May 2020 19:03:10 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    Lines: 134
    Xref: news-archive.icm.edu.pl pl.comp.programming:214935
    [ ukryj nagłówki ]

    > Owszem, jest tych braków coraz mniej, ale są, a po drugie nie w każdej
    > przeglądarce wszystko dsziała identycznie, dlatego stosuje się tzw.
    > polyfille i biblioteki ujednolicające interfejs, podam dwa przykłady:
    > https://underscorejs.org/
    > https://github.com/axios/axios

    Pojedyncze biblioteki są bezpieczniejszym rozwiązaniem, niż framework, który z natury
    narzuca więcej. Ja nie mam problemu z bibliotekami.

    > Niemniej, gdy znasz np. Bootstrapa to czytając HTMLa z użytymi klasami BS
    > od razu wiesz jak to się zachowa, a gdy masz zamknięte wynalazki to musisz
    > szukać źródeł i ryć.

    Ale ja nie chcę mieć zamkniętych wynalazków, skoro ustaliliśmy, że ostatnio (i z
    biegiem czasu) wszystko co potrzeba, jest w standardzie.

    > No... albo tak albo nie... a na końcu okazuje się, że pod presją czasu,
    > product managera lub czegokolwiek ten wasz framework to potworek o dwunastu
    > głowach i sześciu ogonach, którego tak naprawdę nikt już nie ogarnia. A
    > dokumentacja? ...eee... no nie pisaliśmy, bo każdy znał na 100% ;-)

    Jest takie ryzyko. Ale ja widzę, że to samo dzieje się z zewnętrznymi frameworkami.
    Gdy autorzy już ich nie ogarniają, to powstaje nowy framework. Jeszcze fajniejszy. I
    pozbawiony wad poprzedniego frameworka!

    To nie jest tak, że zewnętrzne rozwiązania się nigdy nie degradują. Degradują się a
    nawet z tego powodu wychodzą z użycia. ActiveX? Applety? Flash? To są oczywiste
    archaizmy, ale świat frameworków niebezpiecznie przyśpieszył i do tej grupy dołączają
    frameworki, które jeszcze niedawno były cool.

    > Zależy o jakim poziomie mówisz, bo ten z samego dołu developer to klepacz
    > kodu, nie zna i nie musi znać dziedziny, on ma zadanka w tablicy agilowej i
    > koduje.

    Ja pracowałem w miejscach, gdzie jednak "ten z samego dołu" musiał wiedzieć, co
    koduje. Bo by bez tej wiedzy po prostu nie zakodował. I ta wiedza jest zwykle
    trudniejsza, niż znajomość frameworka.

    > > Od kiedy pisanie dokumentacji jest złe? :-)
    >
    > Kto twierdzi, że złe? Jest kosztowne.

    Policzmy. Nie za bardzo mam na czym liczyć poza moim projektem YAMI4, ale skoro go
    mam, to policzmy. Lubię pisać "prozę" i nigdy nie słyszałem zarzutu, że moja
    dokumentacja ma jakieś braki, więc uważam, że to właściwy przykład. Otóż w tym
    projekcie dokumentację robi Doxygen z odpowiednich komentarzy w kodzie, których
    jest... 5%, jeśli liczyć ilość linii. To jest wartość obiektywna, którą potrafię
    zmierzyć - ale jest jeszcze odczucie subiektywne, że ta część dokumentacyjna się
    zmienia najrzadziej (np. tam się nie robi optymalizacji, nie poprawia algorytmów, nie
    debuguje, itd.), więc wysiłek w relacji do całości jest pewnie rząd, jeśli nie dwa,
    wielkości mniejszy.

    I to jest ten "koszt". Czyli żaden koszt.
    Prawdziwym kosztem jest ten właściwy kod a nie dokumentacja. I tylko ten właściwy kod
    może być motywacją do tego, żeby go nie pisać i postawić na istniejący framework.

    > > Z pierdylionem rzeczy, których nie potrzebuję, ale które muszę zintegrować, i
    zapłacić za nie pamięcią, pasmem, itp.
    >
    > Jeśli wybierzesz nieodpowiedni framework to tak.

    Słusznie. A skąd mam wiedzieć, czy jest odpowiedni?
    Zwykle wygląda to tak, że tworząc zespół do kodu, którego jeszcze nie ma, zatrudniam
    pierwszego jednorożca, który wybiera framework. Potem on odchodzi z zespołu (albo
    awansuje - na jedno wychodzi) a reszta się męczy z konsekwencjami jego wyborów z
    wczesnego etapu projektu.

    Więc skąd mam wiedzieć, że mój pierwszy zatrudniony jednorożec wybierze odpowiedni
    framework?

    > To powiedz mi czym się różni znalezienie programisty do dobrego,
    > udokumentowanego i przetestowanego frameworka, który dziś już nie jest w
    > pierwszej piątce od znalezienia programisty do autorskiego, zamkniętego i
    > dużo mniej dopracowanego frameworka pisanego w firmie?

    Tym, że w drugim przypadku zatrudniam programistę do standardowego stacku, bo z jego
    punktu widzenia właśnie to zobaczy w firmie. A to, że część kodu w projekcie zostanie
    wydzielona przez refaktoryzację do osobnego bytu (i czy w ogóle to nastąpi), to jest
    szczegół, który w ogóle nie musi przeszkadzać w rekrutacji.

    Natomiast w pierwszym przypadku muszę napisać w ofercie pracy, że szukam programisty
    do frameworka X. I tym ogłoszeniem od razu zniechęcam tych, którzy tego frameworka
    nie znają. Czyli ograniczam target, a przez to zwiększam koszt.

    > >> Oraz olbrzymią bazę społecznościową,
    > >
    > > Ale sfragmentowaną bardziej (a przez to mniej dostępną), niż bazę społecznościową
    bardziej podstawowego stosu.
    > > I przy bardziej podstawowym stosie mogę tej bazy społecznościowej potrzebować
    mniej.
    >
    > Nawet mocno pofragmentowana jest o kilka rzędów większa niż Twój zespół i
    > wszyscy znajomi programiści.

    Nie, bo moja docelowa społeczność to standardowy stack. Ta społeczność jest zawsze
    największa. Ja nigdy nie zapytam na grupie dyskusyjnej, czy ktoś wie, jak się coś
    robi w moim własnym frameworku. Natomiast w przypadku cudzego frameworku już bym może
    musiał pytać.

    Czyli dalej nie wiemy, co się bardziej opłaca.

    --
    Maciej Sobczak * http://www.inspirel.com

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: