Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.fr7!futter-mich.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!unt-spo-a-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail Newsgroups: pl.comp.lang.javascript From: Wojciech Bancer Subject: Re: Argument funkcji References: <5a8d1d93$0$674$65785112@news.neostrada.pl> <1qn3p672u6yl5.1585lwp0arhbr.dlg@40tude.net> <1b368637-7199-4b74-85d2-5a359e6666e0@googlegroups.com> <15dvc5ead1h2c.cg8ko59kdlzt$.dlg@40tude.net> <246a73c9-8dc7-4ee0-946e-885933c13103@googlegroups.com> <27t8tt1m96wu.11hqw4vglcdjq.dlg@40tude.net> <11hsdnx36lvz3.sjxote5c1628.dlg@40tude.net> <2762d7f6-99fd-4697-b267-dc1ce7a9fe24@googlegroups.com> <18glwbnoogv4i$.ob1q7xeh9yly$.dlg@40tude.net> <3c1ede4e-1fb8-4574-9e6a-429e512643db@googlegroups.com> <99f5fc14-8443-4e78-b5ca-9bcdd1c9af59@googlegroups.com> Organization: None Date: Sat, 3 Mar 2018 22:32:38 +0100 User-Agent: slrn/1.0.3 (Darwin) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Message-ID: Lines: 128 NNTP-Posting-Host: 37.47.160.93 X-Trace: 1520112758 unt-rea-b-01.news.neostrada.pl 31353 37.47.160.93:12415 X-Complaints-To: abuse@news.neostrada.pl X-Received-Bytes: 6830 X-Received-Body-CRC: 2831278662 Xref: csiph.com pl.comp.lang.javascript:3456 On 2018-03-03, Cezary Tomczyk 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