🚀 go-pugleaf

On 2018-03-03, Cezary Tomczyk <cezary.tomczyk@gmail.com> wrote:

[...]

>> Czyli umiesz się wylegitymować przypadkami, w których framework
>> defakto spowodował niemożność pracy w zespole, w stosunku do wersji
>> "bez"?
>
> Piszesz, że framework pomaga "efektywnie rozdzielać pracę w zespole". To 
> tylko częściowo prawda. Framework nie zaplanuje architektury aplikacji 
> czy też modeli, przykładowo.

Framework _pomaga_, a nie _odwala robotę za_.

>>>>> Trafiłem na projekt napisany w Angularze 1.x. W pewnym momencie
>>>>> doszli do ściany, bo aplikacja stała się niezarządzalna.
>>>> No i? Niczemu z tego co napisałem to nie przeczy.
>>> No i to, że żaden framework nie gwarantuje niczego.
>> A gdzie tu była mowa o gwarancjach?
> Ja twierdziłem, że frameworki nie gwarantują. Są tylko narzędziem, które 
> ułatwiają.

Czyli potwierdzasz moją tezę. Ułatwiają.

>>> Owszem, przecież nie pisałem, że tak nie jest. Jeno to, że jeszcze
>>> trzeba umieć z nich korzystać. Ale to już osobny temat.
>> 
>> Z wszystkiego trzeba umieć korzystać, więc niespecjalnie
>> rozumiem taki argument.
>
> ">>> I że możemy efektywniej rozdzielać pracę bo ktoś już nad tym
> >>> pomyślał i nie trzeba odkrywać koła na nowo."
>
> Ta? 

Ta.

> To weź do zespołu 10-ciu juniorów programistów. Zobaczymy, jak 
> gładko będzie szło.

Wezmę 10 juniorów, dam im dokumentację i wzorce (które ktoś opracował,
w przypadku takiego Angulara np. John Papa), dam im zadania, dam im stack
overlow, zaprzęgnę porządny code review i wymóg pisania testów i tych 10 
juniorów da radę.

A bez frameworka co im dasz? "Sami wymyśclie sobie strukturę, sami 
wymyślcie sobie Centralne Biuro Zarządzania Obiektami"?

>> Dzisiaj (2018) jest znacznie łatwiej napisać "to samo" co np. w 1998 r,
>> w dużo krótszym czasie. Tylko teraz wymagania są dużo większe, więc
>> i nie piszemy "tego samego".
>
> Ja nie napisałem, że pisze się to samo tylko, że pisanie oprogramowania 
> jest (i będzie) nadal skomplikowane. Po prostu ciężar tego 
> skomplikowania przeniósł się gdzie indziej.

Czyli dzięki większej warstwie abstrakcji jesteśmy w stanie albo dostarczyć
więcej, albo w krótszym czasie. W 2000 napisanie prostego CMSa zajmowało 
kilka miesięcy. Teraz jest to kilka godzin.

> Teraz już nie myślisz o pewnych rzeczach, które robiłeś 10 lat temu, ale 
> za to musisz robić rzeczy, których nie było 10 lat temu.

Innymi słowy możesz się skupić na dostarczaniu coraz bardziej wyszukanych
narzędzi, czyli wzrasta złożoność tworzonego kodu. Między innymi dlatego
używamy JS, a nie np. Asemblera.

>> Transpilacja to nie jest "wymysł frameworków".
> Autorów tych frameworków.

Absolutnie nie.

>> Nie zgodzę się też z zarzutem narzutu w ilości "kilku MB".
> No to sprawdź webpack bundle analyzer co siedzi w finalnych paczkach.

Kod ES5, a co ma siedzieć? Święty Mikołaj? Nadal, nie ma "narzutu kilka
MB". I ciągle nie rozumiem tego zarzutu o kilku MB. Rozumiem, że filmów
nie oglądasz, bo to kilkaset, kilka tysięcy MB i Ci się komputer 
przegrzeje?

>>> Ja nie pisałem o mikrooptymalizacjach, a o tym, że frameworki same z
>>> siebie dodają jeszcze masę syfu. Plus ludzie dodają np. całe Underscore
>>> by skorzystać z jednej metody, itp. I aplikacje mają po kilka(naście) MB.
>> I co z tego? Nie piszemy strony dla Atari.
> A co to ma do rzeczy?

Prosta optymalizacja. Dzień pracy programisty kosztuje często więcej
niż rok utrzymania przeciętnej strony/aplikacji, więc o ile nie piszesz
softu "ratującego życie", to nie ma potrzeby biznesowej by się ściskać
poniżej 1MB. Facebook zajmuje "megabajty", a nikt nie powie że działa
wolno lub niewydajnie.

Takie kryterium jakości jest po prostu nic nie warte.

Więcej optymalizacji da Ci w tym momencie admin który włączy kompresję 
gzip i cache niż stado programistów, którzy będą się głowić jak zejść 
o 10-100kb kodu.

Martwić się o megabajty trzeba jak to jest wąskie gardło, a nie "bo tak".

>> ES6 ma mnóstwo przydanych usprawnień, które nie dość że poprawiają
>> czytelność kodu, ale też powodują że łatwiej go utrzymać i łatwiej złapać
>> błędy. Dodaj do tego możliwość np. typowania (flow lub typescript) i masz
>
> Samo typowanie to za mało. Od łapania błędów to masz tslint 
> (TypeScript), eslint, porządnie napisane unit testy, integration testy, 
> generalnie cały process walidacji.

Który nota bene jest świetnie udokumentowany i wdrożony gdzie?
Ano w tych frameworkach. :)

> Uściślając, by nie kontynuować akademickiej dyskusji dalej: uważam, że 
> frameworki to dobre narzędzia, które do pewnego stopnia pozwalają na 
> organizację pracy.

Czyli jak widzisz się zgadzamy, bo takie były moje tezy początkowe. :)

> Niemniej jednak do tego dochodzi jeszcze m.in. 
> znajomość procesów jakości, bezpieczeństwa, mechanizmy cache i cache 
> policy, patternów, continuous deployment, continuous integration, itd.

Tak, nie przeczę że do tego by programować trzeba umieć programować
i korzystać z narzędzi. Tym niemniej lepiej że te narzędzia są, niż
jakby ich miało nie być.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com