Zostań lepszym programistą front-endu – fakty i mity

Zastanawiałem się ostatnio, co tak naprawdę czyni nas dobrymi programistami front-endu. Abstrahując od tego, że cały czas uczę się i nigdy nie będę mógł powiedzieć o sobie, że jestem w czymś doskonały, postanowiłem zebrać do kupy kilka wskazówek, które wywarły ogromny wpływ na moją karierę.

Pokora to jedna z największych cnót

Szafowanie szeroką gamą branżowych terminów nie czyni z Ciebie specjalisty. Spotykałem osoby, które twierdziły, że wiedzą, co to dostępność, użyteczność i inne takie… No, zresztą, sami dobrze wiecie… Większość z nich, zapytana o szczegóły, rzucała jednak podstawowymi określeniami, które można bez trudu znaleźć po 30 sekundach wyszukiwania w sieci.

Bardzo często ktoś, coś tam słyszał, jednak nie przypomina sobie szczegółów. Nielsen, Don’t let me think. A! I o niepełnosprawnych coś było! Prawie jak na lekcji biologii… Problem w tym, że tak jak lekarz podczas operacji nie sięga po podręczniki, by dowiedzieć się, gdzie mieści się serce, tak programista front-end nie myśli dwie godziny nad tym, jak działa, dajmy na to, hierarchia nagłówków.

Dlatego też o wiele bardziej cenię ludzi pokornych, którzy owszem, w trakcie boomu na użyteczność słyszeli kilka podstawowych haseł, aczkolwiek otwarcie przyznają, że nie wiedzą zbyt wiele i chcieliby poszerzyć horyzonty.

Poza tym, gro osób spod znaku doskonała znajomość HTML, XHTML, CSS oraz standardów W3C, WAI tak naprawdę, co komiczne, ma w swoim portfolio strony, które przeczą współczesnym standardom. Co więcej, pewnikiem wszyscy zrobiliśmy kiedyś jakiegoś potworka. W związku z tym, sto razy bardziej docenię osobę, która jest świadoma tego faktu, niż tę, która stwierdzi, że wszystko jest w porządku, a jej kwalifikacjami powinna zająć się najlepiej komisja złożona ze Spolsky’ego, Meyer’a, Zeldmana i innych.

To nadal jest programowanie!

Jeśli chodzi o JavaScript, zważ, że to nie tylko jQuery. Wielu programistów uważa czysty JavaScript za zupełnie zbędny, kiedy jest to podejście pozbawione sensu. Chciałbym wiedzieć, ile do powiedzenia na temat optymalizacji, closures czy programowania obiektowego mają osoby, które w swoim portfolio oceniają JavaScript na „doskonały”. Sam łapałem się na tym wielokrotnie – udało mi się napisać to i owo, dlatego myślałem, że jestem w danej dziedzinie ekspertem. Nic bardziej mylnego, języki programowania to żywy twór, który z każdym dniem odsłania nowe obszary.

Kiedyś o eventach w JavaScript wiedziałem tylko tyle, że trzeba pobrać odnośnik do DOM i przypiąć stosowną funkcję. Dziś o ból głowy (z zachwytu nad rozwiązaniami) przyprawiają mnie problemy wycieków pamięci lub zdarzeń bąbelkowych.

A gdzie mi tu Panie do zaawansowanego użycia Canvas, w którym zrobiłem bardzo mało rzeczy, aczkolwiek mam świadomość, jak to działa i wiem, że gdybym poświęcił swój czas na konkretny projekt, na pewno bym go zrobił. O ile z czystym sumieniem mogę więc stwierdzić, że nie jestem specjalistą z tej dziedziny, tak wiele osób napisałoby na Goldenline czy gdziekolwiek indziej, że Canvas wciąga uchem, kiedy tak naprawdę używała jedynie jakiegoś widgetu z Ajaxian.com.

Poznawanie zagadnień od podstaw jest bardzo ważne. Prędzej czy później trafimy na problem, któremu nie będziemy mogli podołać przez nasze zaniedbania. Pierwszy przykład z brzegu – miałem swego czasu zoptymalizować system walidacji formularzy faktur. Pozycji było ponad 30, każda z nich miała po pięć sprawdzanych informacji. Pętli były dziesiątki (setki?) tysięcy, a czas wykonywania skryptu oscylował wokół 15 sekund. Wszystko oparte było o jQuery i jQuery Validation. Dla każdego walidowanego pola frywolnie używano selektorów jak poniżej:

$('input[name^=xxx][name$=xxx]');

Przyjmując, że jQuery musi sprytnie przefiltrować wszystkie inputy, dopasowując je do podanych dwóch wyrażeń regularnych, mamy 30*5*2*600 iteracji (w dokumencie było około 600 inputów). Ciekaw jestem, co powiedziałaby osoba bez jakiejkolwiek wiedzy analityczno-algorytmicznej (choćby jak działają selektory w jQuery). Że o podstawach JavaScript nie wspomnę.

Pomyśl też, co stałoby się, gdybyś musiał napisać coś w MooTools lub Prototype?

Staranność

Nie rób w kodzie bałaganu, pod żadnym pozorem. Nieważne, czy zaczynasz duży czy mały projekt. Nazywaj klasy i identyfikatory zgodnie z przyjętą przez Ciebie konwencją. Żadnych test3, somethingExampleHehe i innych potworków. Nie pisz skryptów na szybko, bez dobrego formatowania i logicznego nazewnictwa zmiennych. Utrzymuj porządek w sekcji head dokumentów, jak i w folderach z plikami źródłowymi. Przyjmij konwencje nazw katalogów, w których trzymasz pliki css, js i obrazki.

Otaczaj skrypty JS anonimowymi funkcjami, tak, by nikt nie nadpisał Twojego kodu:

(function() {
// Twoj kod...
})();

Niestety, programowanie stron niesie ze sobą wiele pułapek, a jedną z nich jest skłonność do powstawania bałaganu. Wielokrotnie widziałem zdublowany kod, puste deklaracje w CSSach i wiele innych niedoróbek. Znając życie, większość pochodzi z czystego pośpiechu. Osobiście, często robiłem coś na szybko, dodawałem style inline, by sprawdzić, jak coś się zachowa, mimo że miałem do dyspozycji debugger. CSS i JS są bardzo czułe na fuszerkę, dlatego unikaj kompromitacji, nawet, gdyby praca miała potrwać 10 minut dłużej.

Zdarza się również, że mozolnie szukamy rozwiązania, dajmy na to pod IE, dopisując coś i skreślając w kodzie, a także pisząc na szybko różne nazwy zmiennych, typu some, x, aaa itd. Gdy dochodzimy do celu, zapominamy o sprawie, skoro „jest zrobione„. W efekcie w kodzie pozostaje bubel, który będzie nielogiczny dla programistów edytujących kod w przyszłości. Zmusi ich to prawdopodobnie do kontynuowania złej konwencji i dalszego brudzenia, bo przecież nie będę się doczytywał, o co temu kolesiowi chodziło.. Nie zostawiaj po sobie kodu, którego sam nie zrozumiesz za miesiąc.

Debugger i dobre narzędzia wspomagające to świętość! Dowiedz się, co to Firebug, WebDeveloper, Live Headers, Pixel Perfect, IE Tab, HTML Validator, czy Firecookie. Przeglądaj często stronę z rozszerzeniami do Firefoxa. A nuż wyjdzie coś interesującego!

Frameworki CSS to nie do końca trafiony pomysł, jednak przydatny w pewnych okolicznościach. Przeanalizuj dokładnie wady i zalety takiego rozwiązania, zainteresuj się resetami CSS czy też projektami typu 960 grid system.

Typografia potrafi być ciekawa, a XHTML ma wady, więc bądź ostrożny.

Rozwój osobisty

Nikt nie jest alfą i omegą. Nie zniechęcaj się tym, że wielokrotnie podczas pracy używasz Google. Zapamiętywanie hacków, czy też bugów przeglądarek jest pomocne, lecz nie jest to najważniejsze. Wystarczy, że znasz i kojarzysz problem. Rozwiązanie to tylko kwestia doboru środków.

Czytaj książki. O sieci pisze się tyle ciekawych rzeczy! Nie przeczytasz ich na żadnej stronie internetowej. Luke Wroblewski, Joel Spolsky, Eric Meyer, Jakob Nielsen, Louis Rosenfeld, Dean Clarke to tylko czubek góry lodowej nazwisk, które szanujący się developer powinien znać. Czytanie zagranicznych pozycji to nie moda, lans czy cokolwiek innego – to polepszanie swoich kwalifikacji. Biorąc pod uwagę, że w sieci są prawdopodobnie tysiące koderów z szablonu (CSS, HTML, JS), zatrudniłbym kogoś, kto po prostu wie więcej.

Jeśli nie znasz z kolei jakiejś pozycji, przyznaj to otwarcie, zamiast szukać okrężnej drogi w swoich tłumaczeniach. Nie znać „X” czy „Y” to nie wstyd, acz argument do dalszej nauki i sztuki poznania. Osobę, która próbuje podjąć dyskusję na temat, o którym nie ma żadnego pojęcia, z reguły można rozpoznać po kilku sekundach. Pamiętaj o tym.

Staraj się czytać blogi, choć zważ na to, że nie jest to żaden wyznacznik Twojej wiedzy, o czym nieliczni próbują przekonywać. Jeśli blogi, to nie tylko polskie (tym bardziej, że bardzo mało jest tych wartościowych). O JavaScript absolutnie fantastyczne rzeczy tworzy John Resig (twórca jQuery), jest genialny Dean Edwards, Paul Bakaus, Valerio Proietti. To tylko kilka nazwisk, bo o JS i CSS piszą tysiące osób. Bardzo pomocne są też serwisy typu A List Apart czy też Ajaxian.com, gdzie zgromadzone są najnowsze wiadomości i projekty z branży.

Zauważ, że posiadanie sprzętu Apple lub pisanie Twittera/Blipa nie czyni Cię specjalistą. Wiedz, że na Macu nie zobaczysz 64-bitowej palety kolorów, a to że Zeldman twitteruje nie robi Cię jego kumplem od wódki. Jeśli mimo wszystko stawiasz powyższy fakt za swoje ewidentne zalety, powinieneś zaznajomić się ze znaczeniami ekshibicjonizmu i jego pochodnymi.

Ucz się języka obcego, najlepiej angielskiego. Większość ważnych rzeczy mówi się tutaj w języku Szekspira. W prestiżowych firmach komunikacja z klientem bardzo często odbywa się po angielsku. Z kolei, jeśli Twoje aspiracje sięgają naprawdę wysoko, raczej nie dosięgniesz nieba w Polsce. Niestety, pierwsza liga front-endu gra za granicą. Sam fakt, jak mało mają tam do powiedzenia Polacy, świadczy o tym, że możemy traktować nasz kraj jako branżowy zaścianek.

Bądź krytyczny i szczery w swoich osądach, nie bój się wyrażać własnych opinii. Jeśli projekt dyskutowany jest pod kątem dziedziny, w której jesteś ekspertem, narzuć swoje zdanie i przede wszystkim przedstaw stosowne argumenty. Broń swojej wiedzy! Kto ma wiedzieć cokolwiek o dostępności, jak nie specjalista front-end? Oczywiście, sugestie innych osób są cenne, jednak ostateczne zdanie powinno należeć do Ciebie.

Fajne rzeczy o rozwoju osobistym pisze Alex Barszczewski.

Użyteczność

Sądzę też przekornie, że użyteczność to jedna z największych pułapek, jakie wyprodukował webdevelopment w ostatnich latach. Podstawowe terminy użyteczności stron www są jak najbardziej zasadne, jednak im dalej w las, tym więcej drzew. Tak naprawdę, wiele aspektów użyteczności jest sprawą dyskusyjną i to, dlaczego, przyjmijmy umownie, link jest czerwony, a nie niebieski, w gruncie rzeczy determinuje kontekst, zamierzony cel i dziesięć innych czynników, których nie znajdziemy w szablonowych książkach o usability.

Jest to działka, w której najwięcej mają do powiedzenia krzykacze. Ubzdurało im się, że znają się na użyteczności, bo przeczytali kilka mądrych książek. Większość sporów o usability danego elementu na stronie można podważyć „pierwszą lepszą” publikacją książkową. Dlatego też najgorsze argumenty, jakie możesz użyć w dyskusji o usability, tyczą się fanatycznego powoływania na konkretnego autora i rzekomego specjalisty od użyteczności. Nikt jeszcze nie wymyślił złotego środka, a książki o usability wskazują jedynie na najpopularniejsze problemy!

Przede wszystkim radzę myśleć! Użyteczność to nie proste regułki. To nie wersety z książek, które często powielają banały lub które są po prostu słabe (vide publikacje Kasperskiego). Nie idź na łatwiznę. Dopatruj się kontekstu, przeprowadzaj testy z użytkownikami, dyskutuj z kolegami po fachu! Nie ma nic bardziej zbawiennego, niż solidna burza mózgów, poparta konkretnymi argumentami merytorycznymi. Wiele publikacji aspiruje do bycia tak uniwersalnym, jak tylko sie da. Nie daj się nabrać, tym bardziej, że jest to ostatnio niezwykle chwytliwy temat. Specjalistów od użyteczności przybywa niczym cinkciarzy pod Pewexem, dlatego powtórzę jeszcze raz – myśl!

Prototypowanie

Doceń prototypy i testy z użytkownikami. Muszę stwierdzić, że wcześniej rzadko korzystałem z papierowych bądź elektronicznych prototypów. Designy od początku do końca projektował dla mnie grafik, zgodnie ze słownymi wytycznymi. Jakież to amatorskie podejście! Profesjonalny projekt powstaje stopniowo. Najpierw pracuje się nad wymaganiami, potem wkracza front-endowiec, który ma za zadanie przedstawić prototyp funkcjonalności strony. Nie projektuje on designu, ale ustala layout, rozmieszczenie buttonów, warstw, menu i wszystkiego, co tyczy się www. Przy okazji projektuje on większość aspektów użyteczności strony. Prototyp ułatwia pracę wszystkim – klientowi, designerowi, back-endowi i Tobie oczywiście. To na etapie prototypu powinny być wyjaśniane wszystkie wątpliwości. Tutaj ustalany jest ostateczny, podkreślmy to, kształt aplikacji. Wszystko po to, by potem zająć się tylko i wyłącznie kodowaniem oraz testowaniem.

Profesjonalne prototypy można tworzyć np. w Axure.

Prawdopodobnie to nie wszystko, co można by napisać na ten temat. Uczymy się jednak na błędach, a kolejne akapity dopisze życie, z pewnością…

Komentarze

1

Brawo, jeden z najlepszych i konkretnych postów jaki ostatnio czytałem na polskich blogach webdev.
Możesz z ciekawości napisać, dlaczego uważasz framworki CSS za złe rozwiązania? Właśnie zastanawiam się nad włączeniem jednego do projektu nad którym pracuję.

Łukasz
2

Sama prawda. Odnośnie bałaganu w JS to sprawa ma się podobnie jak z innymi językami programowania tak więc pozycja Clean Code obowiązkowa.

pedro
3

Świetny wpis. Widzę, że po dłuższej przerwie forma wróciła.

pio
4

Fajny wpis. Pozwól, że wetknę swoje 3 grosze i zamiast wspomnianego Axure polecę Tobie nasz projekt – http://justproto.com

Myślę, że aplikacja online do prototypowania może być ciekawsza od aplikacji desktopowych, ale ocenę projektu pozostawiam klientom.

Ps. Jeśli byłbyś zainteresowany naszą aplikacją to myślę, że mogę zdobyć kod na 60-dniowego triala :)

5

Mysle, ze JustProto jest bardzo ubogie w stosunku do Axure, ktorego zdaje sie pewnie w ogole nie uzywales. Fajna zabawka, ale gdybym mial placic, wybralbym Axure.

6

Ferrante: przyznam się, że nie używałem. Od wielu osób słyszałem jednak, że dla nich Axure to przerost formy nad treścią.

My na początek nie chcieliśmy zawalać użytkowników masą zbędnych gażdżetów. Swoją drogą to czekamy na feedback. Jesteśmy otwarci na propozycje i chętnie wdrożymy ciekawe pomysły.

7

Wiedziałem, że warto będzie poczekać na Twoje nowe teksty!

Sam, jako osoba ucząca się korzystam z większości wspomnianych przez Ciebie stron i źródeł wiedzy, jednak kilka nazwisk jest dla mnie nowością i mam nadzieję, że jak najszybciej (ale również skutecznie) nadrobię zaległości :)

Jeszcze raz dziękuję!

8

Ciekawy tekst zawierający kilka interesujących linków, które bedę musiał odwiedzic :)

furas
9

Ciekawy artykuł, jeżeli chodzi o siatkę css to chyba najlepszą zaletą nie jest szybkie tworzenie stron a proporcjonalny podział strony, ustawienia marginesów itd, w końcu w poligrafii się to stosuje dlaczego by nie można zastosować do stron. Dobrym uzupełnieniem o typografii jest książka Robert Bringhurst: Elementarz stylu w typografii.

tomek
10

Raz, ze ciekawy artykuł, a dwa – po podstawieniu odpowiednich wyrazów w miejsce JavaScript, CSS, HTML możnaby uznać tekst za uniwersalny, niezależnie od platformy i dziedziny programowania.

11

Artykuł ciekawy bardzo. Zdroworozsądkowy taki :)
Ja niedawno sam się na ziemię trochę sprowadziłem z samo uwielbienia, więc wiem o co mniej więcej chodzi :P Ważne to po prostu pracować z takimi ludźmi, by czuć do nich respekt. Wtedy jest ok.

12

Oby jak najwięcej takich artykułów.

13

Bardzo mądrze napisany artykuł. Dawno nie przeczytałem tak konkretnie traktującego wpisu o tematyce front-endu na polskich blogach.

zioło
14

Dzięki za ten wpis! Daje do myślenia. Sam tworzę strony i ciągle się uczę :).

Bron
15

Kompromitacji należy unikać, niezależnie od tego czy praca ma potrwać 10 minut dłużej, czy trzy miesiące dłużej. Ale pewnie chodziło o kompromisy ;) Poza tym ciekawie napisane, dzięki.

czepialski
16

Fajny artykuł – powoduje odśrodkową siłę zmuszającą do rozwoju, ale też bolesne przemknięcie przed oczami wszystkich fuszerek jakie się odwaliło :)
Sam w sumie nie uważam się za specjalistę od standardów, PHP, albo JS… Programować stronki zacząłem jak po studiach przyszedłem do pewnej firmy, która szukała Informatyka. Okazało się że mam robić stronki, więc z pomocą google+sporej części czasu wolnego działałem… Po jakimś czasie miałem za zadanie przyjąć kolejnego informatyka i zobaczyłem, że ludzie, którzy piszą, że znają doskonale rzeczy (o których ja coś tam wiedziałem, albo słyszałem, ale nie powiedział bym że znam) mają problemy ze zrobieniem tabelki w HTMLu… Nie przeszkadza im to w napisaniu w CV „Bardzo dobra znajomość XHTML i CSS”.
Później pisząc jakieś rzeczy na zlecenie przeglądałem cenniki różnych firm, żeby wycenić swoją pracę – tam to dopiero jest megalomania – jak na prostej stronie www można wstawić newsa z CMSa to jest to już właściwie „portal internetowy”…
Najzabawniejsza sytuacja przydarzyła mi się ostatnio jak znajomi koleżanki (graficzki) poprosili ją o zmiany na stronie, bo „specjalista” chciał za to sporo pieniędzy. Zrobiłem te zmiany (ze wsparciem graficznym koleżanki), ale niestety okazało się że nie spełniają one standardów „specjalisty” i nie mogą być wprowadzone ponieważ wpłyną negatywnie na pozycjonowanie strony, którym również zajmował się ów „specjalista”. Następnie „specjalista” zlecił te zmiany firmie, która zleciła je mi – oczywiście teraz spełniają najwyższe standardy, tylko trochę więcej kosztują, bo jest 2óch pośredników :)

Biorąc pod uwagę powyższe mimo pełnej świadomości – że nie jestem alfą i omegą, a właściwie znam pewne podstawy, które w połączeniu z google + jakimiś tam umiejętnościami analitycznymi i ewentualnie zarwaną nocą pozwalają poradzić sobie z umiarkowanie skomplikowanymi problemami – nie mam żadnych oporów przed pisaniem o sobie specjalista doskonale znający to co trzeba, bo ma to znaczenie marketingowe…

17

Dziękuję za ciepłe słowa pod adresem mojego serwisu :-)
Jeżeli piszesz o czytaniu książek, do tego po angielsku, to warto zwrócić uwagę, że właśnie dla takich ludzi, którzy chcą się dalej rozwijać otworzyłem Biblioteczkę w której już jest prawie 200 wartościowych pozycji z różnych dziedzin rozwoju i zarządzania. Każdy może je wypożyczyć, koszt to tylko 6-8 zł za odesłanie jej z powrotem poleconym.
Zapraszam http://biblioteczka.alexba.eu/index.php
Pozdrawiam i życzę sukcesów
Alex

Alex
18

Co do prototypów bardzo proste narzędzie pozwalające nakreślić o co chodzi to addon do firefox pencil. Axure jak dla mnie jest to przerost formy nad treścią.

Pozdrawiam

canis
19

bardzo fajny mądry artykuł,
zastanawiam się tylko nad 64-bitową paletą kolorów, oko człowieka nie jest chyba w stanie tylu kolorów rozróżnić a max. to 16,7 miliona ?

20

tak sobie poczytałem ten artykuł i dałeś mi troche do myślenia :) tak swoją drogą patrzymy wszyscy razem na jquery, mootools proto etc prawie jak na inne języki programowania … to tylko biblioteki i ktoś sie narobił zeby je napisac w js chwała im za to na wiele lat w przyszłość, standardy ?? muszą istnieć żebyśmy nei popełniali jeszcze więcej błędów i leniwych zagrań … ;) życzę powodzenia dzięki za motywację !!!

21

[…] do tego dojść. Bez najmniejszych wątpliwości mogę polecić wpis na ferrante.pl pod tytułem: Zostań lepszym programistą front-endu – fakty i mity. Wpis ten spełnia wszystkie opisane […]

22

[…] Zostań lepszym programistą front-endu […]

23

Powiem tylko: świetny wpis. Bardzo dobre podsumowanie, charakterystyka frontendowca.

24

[…] wpis na stronie ferrante.pl na temat jak zostać dobrym programistą w JS. Tam jest adres do witryny z oprogramowanie  do […]

Dodaj komentarz

Dozwolone tagi: <blockquote>, <code>, <strong>