🚀 go-pugleaf

On Wed, 20 May 2020 11:46:05 -0700 (PDT), Maciej Sobczak wrote:

>> Jest wiele powodów by nie robić tego w ten sposób.
> 
> A jednak pobawię się w adwokata diabła i spróbuję znaleźć kontr-argumenty.
> 
>> Goły HTML, JS i CSS
>> oznacza, że trzeba narąbać tony (istniejącego już) kodu, który załata wiele
>> braków i niedoróbek tej golizny.
> 
> Np. jakich braków i niedoróbek? Myślałem, że kolejne standardy tychże były opracowywane właśnie z myślą o usprawnieniach. Rozumiem, że 20 lat temu czegoś mogło tam nie być, ale czego tam nie ma w 2020 roku?

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

Podobnie np. z HTML i CSS, szybciej i wygodniej buduje się stronę na
Bootstrapie, niż w gołym kodzie - choć to ostatnio jest już prawie
niepotrzebne.
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ć.
 
>> Wymyślając te swoje ficzery tworzysz de
>> facto kolejnego frameworka,
> 
> Tak. Prawdę mówiąc każdy projekt, jeśli jest właściwie i na bieżąco refaktoryzowany, wyłania coś, co ma szensę istnieć odrębnie. To może być jedna funkcja pomocnicza, a może być framework. Albo cokolwiek pomiędzy.
> 
>> z tym, że nikt poza Tobą i Twoim zespołem go
>> nie zna.
> 
> Ale za to ja i mój zespół znamy go w 100%.

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% ;-)
 
>> Zatrudnij teraz do zespołu nowego developera i każ mu to
>> zrozumieć, rzeźnia.
> 
> Z moich doświadczeń wynika, że nowy developer najwięcej problemów ma ze zrozumieniem dziedziny problemu, czyli przedmiotu realizowanego projektu. Ogarnięcie się w samym kodzie i rozwiązywanie kolejnych wyzwań przez analogię z istniejącym kodem jest najmniejszym problemem.

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.
 
>> Dodatkowo musisz pisać dokumentację.
> 
> Od kiedy pisanie dokumentacji jest złe? :-)

Kto twierdzi, że złe? Jest kosztowne.
 
>> Używając
>> frameworka open source masz produkt rozwijany za darmolca przez
>> setki/tysiące developerów,
> 
> 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.
 
>> Dodatkowo, gdy potrzebujesz zmienić kogoś w zespole lub nawet cały
>> zespół to szukasz developerów znających X, Y lub Z i masz niemal od strzału
>> gotowego programistę,
> 
> I tu mam przeciwne spotrzeżenie. Ilość dostępnych frameworków oznacza, że ten ekosystem jest niesamowicie sfragmentowany, więc pula "talentów" jest mniejsza, niż mogłaby być, gdybyśmy celowani w bardziej podstawowe rozwiązania. Konkretnie: jak byś nie liczył, ilość developerów znających jakiś wybrany framework do JSa jest mniejsza, niż ilość developerów znających JSa.
> A to oznacza, że developer znający framework X sam siebie uzna za bardziej wyjątkowego (i słusznie), przez co będzie droższy. Czyli developer od frameworka X będzie droższy, niż developer od JSa.
> I teraz mam zatrudnić cały zespół takich jednorożców?
> 
> To samo dotyczy wymiany zawodnika na innego.
> 
> Jeszcze gorzej, jak się nam projekt zestarzeje, po tym jak wszystkich zaskoczył i niestety odniósł sukces. Wtedy okaże się, że poszukiwanie developera znającego jakiś niemodny już framework będzie podobne do szukania programisty np. COBOLa.
> 
> Jeśli mówimy o kosztach, to właśnie teraz o nich mówimy.

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?
 
>> Ponadto popularne frameworki mają masę dodatkowych narzędzi wspomagających
>> typu pluginy do edytorów,
> 
> Których nie potrzebuję jeśli nie używam frameworków? Czyli frameworki rozwiązują problemy, których nie mam, jeśli ich nie używam? :-)

To czy potrzebujesz to Twój wybór, osobisty. Ja mówię o tym, że są
narzędzia bardzo przyspieszające i organizujące pracę w danym frameworku,
bo ku temu zostały stworzone. Nie mam na myśli narzędzi, które utrudniają
pracę czy bez których nie da się frameworka używać.

> Albo i nie rozwiązują. Co jeśli mój ulubiony edytor nie jest ulubionym edytorem młodzieży pasjonującej się jakimś "nowoczesnym" frameworkiem?

Wtedy nie masz takich narzędzi, czyli dokładnie tak jak z autorskim
frameworkiem.
 
>> Masz też często literaturę na ich tenat.
> 
> Znowu - nie potrzebuję jej, jeśli tych frameworków nie używam.

Z kolei używając swojego nawet jeśli jej potrzebujesz to nie masz.
 
>> 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.
 
> To jak w końcu? Co jest tańsze?
> 
> Czy ktoś ma podobne obserwacje?

No właśnie, ktoś coś?

-- 
pozdrawiam
Roman Tyczka