Jak wygląda tworzenie strony w praktyce
Z zewnątrz tworzenie strony wygląda jak czarna skrzynka: akceptujesz projekt, czekasz kilka tygodni, pojawia się strona. Zrozumienie, co dzieje się w środku, pomaga zadawać właściwe pytania i wcześnie rozpoznawać sygnały ostrzegawcze.
Ten przewodnik wyjaśnia praktykę, z perspektywy zamawiającego, a nie programisty.
Środowiska: gdzie praca się odbywa#
Poważny projekt ma co najmniej dwa środowiska, często trzy. Jeśli jest tylko jedno, to samo w sobie jest sygnałem.
| Środowisko | Do czego służy | Kto ma dostęp |
|---|---|---|
| Lokalne | Komputer osoby programującej | Zespół |
| Testowe | Wspólna wersja do przeglądu | Zespół i klient |
| Przedprodukcyjne | Kopia identyczna z produkcją | Zespół, przed wdrożeniem |
| Produkcyjne | Publiczna strona | Wszyscy |
Zmiany wprowadzane bezpośrednio na produkcji to najczęstsze źródło niespodziewanych awarii. Jeśli usłyszysz, że nie ma środowiska testowego, zapytaj dlaczego.
Cykl pracy#
Większość zespołów pracuje w krótkich cyklach, z czymś do przejrzenia na końcu każdego.
- Praca jest dzielona na małe zadania, każde ze sprawdzalnym rezultatem.
- Każde zadanie rozwijane jest osobno, z kontrolą wersji.
- Ktoś inny przegląda kod przed scaleniem, jeśli zespół ma odpowiednią wielkość.
- Rezultat trafia na środowisko testowe, gdzie można go zobaczyć.
- Przeglądasz i dajesz konkretne uwagi, z adresem i zrzutem ekranu.
- Poprawki wchodzą w kolejnym cyklu, chyba że blokują pracę.
- Co tydzień lub dwa jest wersja do przejrzenia, a nie dopiero na końcu.
Projekt, w którym rezultat widzisz dopiero na końcu, to projekt ryzykowny. Poproś o dostęp do środowiska testowego od pierwszego tygodnia.
Testy przed wdrożeniem#
Co powinno być sprawdzone przed każdym wdrożeniem, niezależnie od wielkości projektu.
- Funkcjonalność: każdy formularz, każda ścieżka, każdy przycisk, który coś robi.
- Przeglądarki: te, których faktycznie używają twoi odwiedzający, według analityki.
- Urządzenia: realne telefony, w tym stary i wolny.
- Wydajność: zmierzona, nie oszacowana, na głównych szablonach.
- Dostępność: klawiatura, kontrast, etykiety, struktura nagłówków.
- Treść: bez tekstu zastępczego, bez linków do domeny testowej.
- Regresja: to, co działało, nadal działa.
- Bezpieczeństwo: walidacja danych wejściowych, uprawnienia, HTTPS.
Wdrożenie i wycofanie#
Wdrożenie powinno być rutynowe i nudne. Gdy jest napiętym wydarzeniem, to znak, że proces jest kruchy.
| Praktyka | Dlaczego się liczy |
|---|---|
| Zautomatyzowane wdrożenie | Eliminuje zapomniane kroki ręczne |
| Wycofanie w minutach | Zamienia poważny błąd w drobny incydent |
| Kopia zapasowa przed wdrożeniem | Siatka bezpieczeństwa dla bazy danych |
| Wersjonowane migracje danych | Powtarzalne zmiany w bazie |
| Weryfikacja po wdrożeniu | Wyłapuje to, co zawodzi tylko na produkcji |
| Wdrażanie w spokojnym momencie | Mniej dotkniętych użytkowników, więcej uwagi |
| Rejestr wdrożeń | Pozwala powiązać problem ze zmianą |
Zapytaj, ile trwa wycofanie zmian. Jeśli odpowiedź brzmi «to zależy» albo «nigdy nie musieliśmy», plan wycofania nie istnieje.
Najczęstsze pytania
Jak często powinienem widzieć postęp?
Co tydzień lub dwa, z czymś widocznym na środowisku testowym. Dłuższe cykle zwiększają ryzyko późnego odkrycia nieporozumienia. Bardzo krótkie cykle ze stałymi uwagami też mają koszt, bo przerywanie pracy w połowie jest nieefektywne. Rytm dwutygodniowy sprawdza się w większości projektów.
Co robić, gdy projekt się opóźnia?
Najpierw ustal przyczynę: brak treści, rozrośnięty zakres, czy optymistyczna wycena. Rozwiązuje się je inaczej, a pierwsza jest często po stronie klienta. Potem wybierz między cięciem zakresu a przesunięciem daty — dokładanie ludzi do opóźnionego projektu zwykle opóźnia go jeszcze bardziej.
Czy muszę znać się na kodzie, żeby to prowadzić?
Nie. Musisz wiedzieć, jakie pytania zadać: czy jest środowisko testowe, jak wygląda wdrożenie, ile trwa wycofanie, co jest przetestowane, kto ma dostęp do kodu. Odpowiedzi mówią wiele o solidności procesu bez czytania jednej linii kodu.
Czym jest kontrola wersji i dlaczego się liczy?
To system — niemal zawsze Git — który przechowuje historię wszystkich zmian w kodzie i pozwala cofnąć się wstecz. Liczy się z trzech powodów: umożliwia wycofanie błędu, pozwala wielu osobom pracować równolegle i jest dowodem, że kod jest twój i przenośny. Projekt bez kontroli wersji to projekt bez historii.
jak powstaje stronaśrodowisko testowekontrola wersjiwdrożenie stronyproces tworzenia stronyprowadzenie projektu web
