Javascript kiddies?

Odpowiedz Nowy wątek
2018-09-10 16:14
8

Czy Wy też macie takie wrażenie, że wielu programistów Javascript za bardzo nie ogarnia? Wielu których poznałem okazało się takimi script kiddies, którzy stosując strategię copy-paste from stackoverflow klepią jakieś stronki i nie potrafią nic poza tym wąskim wycinkiem programowania i Informatyki jako całości. Przypominają mi trochę takich 15-letnich koderów PHP sprzed 10 lat, którzy na swojej "stronie firmowej" pisali o sobie w liczbie mnogiej...


Wiedza to potęga
Oh, przypomniałeś mi ten klasyk w stopkach: Webmaster: Jan Kowalski ([email protected]) :D - roSzi 2018-09-11 13:17

Pozostało 580 znaków

2018-09-10 16:40
0

Mam podobne wrażenia. Spotkałem takich, którzy mieli etykietkę "JS expert developer" i nie byli w stanie uargumentować dlaczego nie chcą otrzymywać wartości w CSV (tylko jakieś brednie, że parsowanie takich stringów jest trudne), a na myśl o bardziej wyrafinowanych operacjach typu scal dwie struktury danych (np. klienci i uslugi_klientow używając id klienta jako klucza) to zupełnie nie ogarniali. Nie wiem, może nie miałem szczęścia spotkać ludzi, którzy faktycznie znają się na JS.

Pozostało 580 znaków

2018-09-10 19:29

I pewnie myślisz, że kiedyśc inaczej było?

Pokolenie BASIC kiddies.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2018-09-10 19:29
Panie ! Kiedyś to było , nie to co tera . - Kamil Pyrkosz 2018-09-10 23:23
Cobol senior kiddie - Marooned 2018-09-11 11:49

Pozostało 580 znaków

2018-09-10 19:44
4

Tak, to tragedia. Z rokiem na rok coraz gorzej.

Tylko, że kiedyś JavaScript kiddies ograniczali się do pisania prostych skryptów - znam PHP, a chcę zrobić efekt na stronie w JS - czyli ogólnie byli to tacy webmasterzy, którzy na jakimś momencie potrzebowali coś napisać w JS (a potem wiecznie te same pytania na forach "jak przesłać zmienną z PHP do JS"
https://www.google.pl/search?[...]4%87+zmienn%C4%85+z+PHP+do+JS ). I tacy JS kiddies używali zwykle VanillaJS, jQuery (wraz z wtyczkami), gotowych skryptów z netu czy innych low-endowych tooli.

Natomiast teraz sytuacja jest o tyle gorsza, że ci ludzie już nie piszą prostych skryptów, tylko uczą się całego arsenału - Reacta, Webpacka, Reduxa i masę innych rzeczy. Swoją drogą aż mnie zadziwiają czasem, bo ja się czasem uczę od nich, że istnieje jakaś biblioteka, tool, czy technika. Są czasem bardzo na czasie (bo mają czasem bardzo świeżą wiedzę, prosto z najnowszych tutoriali) . Jednak od wytrawnego programisty różni ich fakt, że nie bardzo wiedzą dlaczego czy po co (np. taki gość potrafi uczyć się jakiejś biblioteki, np. Reduxa, ale w zasadzie nie ma pojęcia dlaczego się uczy, jakiego rodzaju problemy Redux (albo inna popularna biblioteka) rozwiązuje, tylko uczy się, bo coś jest modne.

Podobnie ludzie mający background w C#/Java też od razu wchodzą w TypeScript zanim się nauczą podstaw JavaScriptu (nie mówię, żeby nie używać TypeScriptu, tylko raczej o tym, że tacy ludzie są potem niedoinformowani i nie wiedzą gdzie się kończy JavaScript, a gdzie zaczyna TypeScript. I mają skłonność do przeinżynierowania rozwiązań i pisania ich w TSowy sposób, nawet jeśli czysto JS-owe rozwiązanie byłoby właściwe (chociaż może źle się wyraziłem z tym TS, bo to nie zawsze muszą być rzeczy z TypeScript. Czasem ludzie używają nawet rzeczy, które są w czystym JavaScript (ES6+), jak klasy, dziedziczenie itp. - ale w taki sposób, jakby nie znali niczego innego, oprócz robienia klasy do każdej głupoty).

W sensie - JavaScript kiddies to tacy ludzie, którzy uczą się czegoś, używają jakiejś libki, ale nie wiedzą dlaczego to robią, nigdy nie próbowali pisać w inny sposób.

Przypominają mi trochę takich 15-letnich koderów PHP sprzed 10 lat, którzy na swojej "stronie firmowej" pisali o sobie w liczbie mnogiej...

Toż to kilka dni temu w wątku o swoim portfolio gość używał liczby mnogiej o sobie (co ciekawe tylko w dyskusji forumowej, a samo portfolio zrobił jako osobiste).


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 2x, ostatnio: LukeJL, 2018-09-10 19:58
Pokaż pozostałe 4 komentarze
nie trzeba, jest przecież window.fetch :) - LukeJL 2018-09-10 23:15
no wiem, że jest przeglądarkowe api, ale jak już piszesz pod daną libkę to fajnie byłoby utrzymać ten styl, a tutaj wpadasz w ten łańcuch zależności i na końcu więcej pobierasz niż klepiesz - czysteskarpety 2018-09-10 23:17
w czymkolwiek się pisze tego ajaxa i tak warto to wydzielić do osobnego modułu (w Vue nie pisze, ale wkurza mnie np. jak w projektach reactowych widzę walającego się fetcha czy axiosa w komponentach. Takie pisanie w stylu PHP, gdzie się miesza widok z pobieraniem danych). - LukeJL 2018-09-10 23:26
ale nie raz robię z ręki jakieś proste pierdoły to nie będę się wygłupiał z instalką 50000 rzeczy, wydzielaniu, tym bardziej jak nikt mi za to nie płaci, a utrzymania tego potem nie mam, tylko jednorazowy strzał - czysteskarpety 2018-09-10 23:33
@LukeJL: w kontekście js pisanie low end wygląda zabawnie :-) - Aryman1983 2018-09-11 12:05

Pozostało 580 znaków

2018-09-10 20:11
0

Nie powiedziałbym, że ogranicza się to tylko do JS'a. Z jednej strony problem widzę i rozumiem, bo mnie to na co dzień męczy jak czytam kod, którego wolałbym nie czytać. Z drugiej mam częściej wrażenie, że to przesadzanie w drugą stronę, bo niektórzy by chcieli, żeby implementować własną maszynę wirtualną pod każdy projekt.

Nie każdego interesuje programowanie w takim stopniu, żeby poznawać jego zakamarki. Niektórych nawet w ogóle nie interesuje. Jak widać popyt na "script kiddies" jest.

Pozostało 580 znaków

2018-09-10 23:25
0

Dużo osób się pcha bo nie wiedzą ile czasu zajmuje nauka .

edytowany 1x, ostatnio: Kamil Pyrkosz, 2018-09-11 19:20
Pokaż pozostałe 6 komentarzy
+1 dla @furious programming, generalnie jak chcesz zabłysnąć wymyślaniem czegoś nowego (nie zasad pisowni) to proponuje napisanie kolejnego frameworka js. Jak klepiesz kod w zespole to też tak wymyślasz swoje "reguły" i nie słuchasz opinii kolegów? - Młodszy Programista 2018-09-11 11:54
Jak już @furious programming i @yarel zaznaczyli, prywatne preferencje niewiele tu mają do gadania. To nie zwiększa czytelności i jest zwyczajnym błędem językowym. - Marooned 2018-09-11 11:55
nic mnie tak nie drażni jak cholerna spacja przez znakiem interpunkcyjnym, to jest jak kalectwo. - Aryman1983 2018-09-11 12:10
Burn the witch! - Marooned 2018-09-11 12:13
Czeski błąd sprawił, że przeczytałem "Wurn ... " :D - yarel 2018-09-11 12:48

Pozostało 580 znaków

2018-09-10 23:32
0

Jak dobrze, że era javascriptu dobiega końca :)

W jego miejsce przyjdzie nowy PHP – tyle że do frontu. Ale było by zdziwko. - furious programming 2018-09-10 23:34
@furious programming: nie nie, już wszystko jest ogarnięte - będzie dobrze. - WeiXiao 2018-09-10 23:37
to samo mówili gdy zaczynałem się uczyć jakieś 6 lat temu ;> - adhed 2018-09-11 07:19
@WeiXiao: jeśli Ci chodzi o blazora to jeszcze poczekamy :-) - Aryman1983 2018-09-11 12:11

Pozostało 580 znaków

2018-09-11 01:24
0
WeiXiao napisał(a):

Jak dobrze, że era javascriptu dobiega końca :)

Ogólnie to era JSu dobiega końca od - jeśli wierzyć różnym ekspertom - około kilku ładnych lat. Czemu akurat teraz miałyby się te wróżby sprawdzić?

Pozostało 580 znaków

2018-09-11 01:41
1

Nie sądzę XD Nawet jeśli taki WebAssembly pozwoli na uruchamianie innych rzeczy (swoją drogą już od paru lat ludzie są w stanie to robić z Emscripten albo dedykowanymi transpilatorami - i jakoś dalej się pisze w JS), to nie sądzę, żeby zastapiło to JavaScript całkowicie. Co najwyżej uzupełnią.

Prędzej uwierzę w to, co już się dzieje - że ludzie będą pisać w TypeScripcie czy innym JSie z ulepszaczami.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 1x, ostatnio: LukeJL, 2018-09-11 01:42
da =/= że robi się to przyjemnie, szybko i jest enterprise ready :) - WeiXiao 2018-09-11 20:06

Pozostało 580 znaków

2018-09-11 09:47
1
WeiXiao napisał(a):

Jak dobrze, że era javascriptu dobiega końca :)

Ależ JavaScript nie ma tu nic do rzeczy. Tak akurat złożyło się, że frontend jest atrakcyjny z punktu widzenia wejścia na rynek. Zauważ, iż osoba, która nie jest inżynierem i nie wybrała sobie tego zawodu lata wcześniej w sposób świadomy dostaje szybki pogląd na to, co właśnie zakodowała. W innych językach tego nie ma, chyba że jara Cię output w konsoli (upraszczając), ale nie ukrywajmy, że większości ludzi to nie obchodzi. Jeśli JS kiedyś zostanie zastąpiony przez inny język to problem pozostanie, bo nie leży on totalnie w technologii, a ludzkim mindsecie. Dużo ludzi, która pcha się do frontu jest stosunkowo mało bystra, dlatego coś, co dla inżyniera jest trywialne, dla nich jest totalną ścianą. Sam prowadziłem rekrutację kilka lat temu i był problem ze zrozumieniem prostego reduce'a.
Teraz pracuję w firmie, w której w niektórych zespołach ludzie z prawie 10 lat exp nie potrafią pisać testów jednostkowych. To co produkują zwykle jest do usunięcia, bo są one albo fragile albo testują detale implementacyjne totalnie nie myśląc, co robią. I nie pracuję w jakiejś firmie z przypadku, a w software housie, gdzie jeden z naszych wiodących klientów jest tzw. unicornem. To nie są projekty do szuflady, a coś, czego ludzie używają na co dzień. Na szczęście mamy w każdym z biur z 2-3 osoby, które są naprawdę dobre, co pozwala na wyłapanie takich rzeczy, jak te wyżej wspomniane testy. A wystarczyłoby przeczytać clean codera ze zrozumieniem i podobne tego typu pozycje i po prostu stosować się do zastosowanych tam rad. Tak, uważam, że jest to tak proste, ale ignorancja nie zna granic i musimy żyć z tym co mamy. Albo założyć własną firmę i zatrudniać samych "debeściaków". ;)

edytowany 2x, ostatnio: Brunatny Szczur, 2018-09-11 09:48
No ale ktoś tych ludzi zatrudnił i nie zwalnia, więc chyba spełniają pokładane w nich nadzieje? - a_s_f 2018-09-11 14:25
Oczywiście, poniekąd. Są to osoby, które realizują zadania, dowożą sprinty, itd. Czy są to słabi programiści? Nie, są to programiści ze "słabościami". ;) Problem w tym, że w wielu projektach zaniża się oczekiwania, a potem w rezultacie dostaje się produkt, którego użytkownicy nie lubią. W sytuacji, gdy taki klient jest startupem, firma po prostu zwija się w momencie gdy skończy się kasa. Ja mam wysokie oczekiwania wobec ludzi z wieloletnim doświadczeniem, ale nadal bardzo mało pisze jakiekolwiek testy, nie wspominając o ich jakości. A to był jedynie przykład. :) - Brunatny Szczur 2018-09-11 16:02
I w sytuacji, gdy faktycznie takie osoby nie są dostatecznie wydajne, czy w jakiś sposób szkodzą produktowy wyraźnie, to wtedy tak - zostają zwalniane. Mam o tyle komfort, że firma, w której pracuję potrafi podziękować programiście. A widziałem niekiedy zespoły, gdzie ludzie ze sobą męczyli się wzajemnie, a nikt nie chciał nic z tym zrobić. - Brunatny Szczur 2018-09-11 16:04

Pozostało 580 znaków

2018-09-11 13:06
0

To co produkują zwykle jest do usunięcia, bo są one albo fragile
albo testują detale implementacyjne totalnie nie myśląc, co robią.

Przydałoby się Wujka Boba na nich napuścić. Swoją drogą testowanie detali implementacyjnych to albo brak doświadczenia (chcę testować, ale nie wiem jak, więc testuję jak umiem) albo głupota (jeśli ktoś będąc doświadczonym programistą dalej testuje detale implementacyjne*, mimo że widział już ileś razy, że to się rozwali przy pierwszym refaktorze - to raczej nie jest to człowiek, który poddaje refleksji to, co robi).

A myślę, że wiele by się znalazło ludzi, którzy niby początkującymi nie są, mają jakieś doświadczenie, ale dalej piszą testy na zasadzie odzwierciedlania 1:1 implementacji. Czyli test g**no testuje, w zasadzie tylko to, czy się coś zmieniło, bo jak się cokolwiek zmieni, to test nie przejdzie (czyli robią taki snapshot test, tyle, że ręcznie, zamiast z automatu).

*Chociaż z drugiej strony testowanie implementacji czasem może być przydatne, ale trzeba wiedzieć kiedy i wiedzieć, że to są testy "na jeden strzał" i że to one pierwsze pójdą się j... przy refaktorze, dlatego nie można na nich zbytnio polegać i należałoby je traktować jako dodatkowe testy, a nie główne


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 2x, ostatnio: LukeJL, 2018-09-11 13:23
Kiedy testowanie samej implementacji wg Ciebie ma sens? Po co Ci testy, które dają false positive'y, szczególnie przy refactorze? Lepszy brak testów niż testy, które szkodzą. - Brunatny Szczur 2018-09-11 16:07
ułatwiają debuggowanie. Jak się robi coś, co zawiera skomplikowaną wewnętrzną logikę, ale co z wierzchu ma bardzo proste działanie (input -> mielenie -> output). I teraz tak - powiedzmy, że testujemy to na zasadzie black boxa (sprawdzamy czy dany input daje odpowiedni output). I coś tam zmieniamy w środku i powstaje bug. Nie wiadomo, w którym miejscu, bo testy mówią tylko, że output jest inny dla danego case'a. Więc musimy debugować. Natomiast, jeśli poszlibyśmy trochę głębiej, to testy by nam mogły zdradzić więcej warunków i powiedzieć co w środku nie działa. - LukeJL 2018-09-11 16:34
czyli testy jako taki automatyczny debugger. Natomiast raczej traktowałbym to tylko jako dodatkowe testy (które tylko by uzupełniały główne testy), które należy traktować jako pomoc/z przymrużeniem oka/i które byłyby juz na wstępie przeznaczone do tego, że się je najwyżej zmieni albo po prostu skasuje. - LukeJL 2018-09-11 16:35
swoją drogą czasem implementacja jest po prostu ważna/złożona. Np. jeśli coś używa specyficznego algorytmu. Warto moim zdaniem mieć czasem większy wgląd w to, czy dana implementacja robi po kolei to, co powinna robić. Chociaż patologią jest dla mnie to, że ludzie tylko takie testy piszą (czyli jak implementacja/algorytm się zmieni, to zostają totalnie bez testów). Ale jako dodatek, w pewnych sytuacjach, czemu nie, jeśli akurat sytuacja tego wymaga. - LukeJL 2018-09-11 16:38

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0