Post by Maciej SobczakPost by Roman TyczkaJest 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.
Post by Roman TyczkaGoł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ć.
Post by Maciej SobczakPost by Roman TyczkaWymyś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.
Post by Roman Tyczkaz 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% ;-)
Post by Maciej SobczakPost by Roman TyczkaZatrudnij 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.
Post by Maciej SobczakPost by Roman TyczkaDodatkowo musisz pisać dokumentację.
Od kiedy pisanie dokumentacji jest złe? :-)
Kto twierdzi, że złe? Jest kosztowne.
Post by Maciej SobczakPost by Roman TyczkaUż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.
Post by Maciej SobczakPost by Roman TyczkaDodatkowo, 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?
Post by Maciej SobczakPost by Roman TyczkaPonadto 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ć.
Post by Maciej SobczakAlbo 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.
Post by Maciej SobczakPost by Roman TyczkaMasz 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.
Post by Maciej SobczakPost by Roman TyczkaOraz 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.
Post by Maciej SobczakTo jak w końcu? Co jest tańsze?
Czy ktoś ma podobne obserwacje?
No właśnie, ktoś coś?
--
pozdrawiam
Roman Tyczka