Proces tworzenia frontendu

Proces:

  1. Ustalamy wspólnie kto jest kim w projekcie – kto jest leadem designu, kto jest leadem front-endu
  2. Dostajemy design (XD links) i front-end developerzy wstępnie zapoznają się z projektem (tj. szybki przegląd designu – tylko w celach zapoznawczych, szybko).
  3. Jeżeli w projekcie będzie wielu front-end developerów, front-end developerzy zgłaszają leadowi części projektu, którymi szczególnie chcieliby się zająć (np. ktoś jest szczególnie zafascynowany budowaniem jakieś wykresu, a inna osoba formularzem —> po to, aby front-end developerzy robili to, co szczególnie lubią lub chcieliby zrobić)
  4. Dzielimy development na taski (mniejsze partie) —> lead powinien to zrobić; tworząc taski przydzielamy taski odpowiednim developerom odpowiedzialnym za odpowiednie części (podział pracy); początkiem zawsze powinien być theme, następnie górna nawigacja i footer
  5. Front-end developerzy przechodzą przez wszystkie elementy i zapisują pytania do designu; dyskutują między sobą budowę jeżeli dany element jest jasny – estymują czasowo (w postaci komentarza do taska)
  6. Lead projektu powinien zgromadzić wszystkie pytania w formie listy (agenda) i wysłać designerom przed callem (na który trzeba się odpowiednio wcześniej umówić, najlepiej tuż po spełnieniu punktu 1 na tej liście)
  7. CALL z designerami, by odpowiedzieć na pytania odnośnie designu; podczas CALLa ustalamy priorytety odnośnie budowanych elementów (kolejność)
  8. Front-end developerzy przechodzą przez wszystko raz jeszcze i estymują czas potrzebny do wykonania poszczególnych ticketów, których nie byli pewni wcześniej z racji nagromadzonych pytań
  9. Front-end developerzy rozpoczynają pracę nad elementami strony, bazując na kolejności ticketów w Backlogu na Clickupie
  10. Front-end developerzy tworzą 1 wspólny branch (np. o nazwie frontend). Z tego brancha tworzą odgałęzienia dotyczące danego elementu strony (np. frontend_about-us, frontend_footer, frontend_nav, frontend_blog itd.).

    Front-end developerzy NIEBĘDĄCY leadem, powinni po zakończeniu budowy danej funkcjonalności, stworzyć Pull Request z prośbą o zmerge’owanie do głównego brancha (frontend). Powinni wtedy przenieść ticket odpowiadający danemu zbudowanemu elementowi do kolumny „Code Review” w Clickupie (w komentarzu w tickecie należy dodać link do stworzonego uprzednio PR). PRZED WYSŁANIEM DO SPRAWDZENIA W FORMIE PR, FRONT-END DEVELOPER POWINIEN PRZETESTOWAĆ SWOJĄ PRACĘ (upewnić się, że działa i zachowuje się dobrze na różnych przeglądarkach i urządzeniach).

    Lead projektu jest odpowiedzialny za wykonywanie Code Review innym (preferencyjnie zawsze rano, przed rozpoczęciem swojej pracy). Lead przekazuje uwagi po wykonaniu Code Review. Po zakończeniu procesu sprawdzania gdy wszystko jest OK – lead merguje dany branch do głównego brancha (np. Frontend).

    Lead może poprosić o Code Review dla swoich elementów innemu developerowi lub leaderowi zespołu.

Oczekiwania względem front-end developera i wykonywanej pracy

Zanim oddasz swoją pracę i poinformujesz, że skończyłe(a)ś, upewnij się, że wszystkie punkty z poniższej checklisty zostały spełnione. Jest to lista, którą ZAWSZE powinno się brać pod uwagę, tworząc front-end w naszej firmie.

Oczekujemy od front-end developerów, by oddana praca była na możliwe najwyższym poziomie i spełniała poniższe warunki:

  • Dołożyłem wszelkich starań, aby dopytać odpowiednich osób o kwestie, które mam do przedyskutowania w kontekście realizacji zadania
  • Upewniłem się, że funkcjonalność działa z założeniami / specyfikacją
  • Przetestowałem funkcjonalność i działa prawidłowo na każdej rozdzielczości (zwróciłem uwagę jak się „składa” na każdej rozdzielczości począwszy od mobilnych rozdzielczości po duże desktopy (4k))
  • Przetestowałem funkcjonalność na różnych urządzeniach (komputer stacjonarny, laptop) oraz przynajmniej jednym urządzeniu dotykowym (np. smartfon [idealnie nieemulowany wirtualnie] lub tablet)
  • Odwzorowałem design na gotowy front-end tak mocno, jak to możliwe (pixel-perfect), uczyniłem funkcjonalność zgodną z webowymi standardami (np. :hover state na linkach/przyciskach)
  • Stworzyłem kod HTML, który jest semantyczny i prawidłowy strukturalnie (zwróciłem uwagę na zastosowane znaczniki, nagłówki, elementy z odpowiednim przeznaczeniem, linki jako <a>, przyciski jako <button> itd.)
  • Zwróciłem uwagę na optymalizację wydajności (np. responsywne obrazki dla podpięcia IMGIX, lazy loading, kolejność ładowanych zasobów); przetestowałem stronę pod kątem wydajności, korzystając z narzędzi Pagespeed Insights i WebPageTest, nanosząc odpowiednie poprawki w razie potrzeby
  • Wszystko obrazki osadzone jako <img> otrzymały atrybuty width i height
  • Stworzyłem kod CSS zgodnie z metodologią BEM (starałem się unikać zagnieżdżeń, nazwy klas są opisowe względem funkcjonalności/roli a nie treści w tych elementach zawartych)
  • Kod CSS napisałem z użyciem SCSS, tworząc osobny plik _some-component.scss dla klasy CSS .some-component (podejście komponentowe)
  • Kod JS jest modułowy
  • Zwróciłem uwagę na dostępność (Accessibility) – możliwość nawigowania na stronie przy użyciu klawiatury, czytnika ekranowego (nagłówki jako punkty nawigacyjne dla technologii asystujących; odpowiednia struktura nagłówków [jeden <h1>]) Sprawdziłem, czy nie ma błędów w konsoli (DevTools —> zakładka Console)
  • Usunąłem niepotrzebny/zakomentowany kod HTML/CSS/JS