pojawia się w początkowym procesie tworzenia projektu i podjęcie złej
decyzji (albo jej brak i zaufanie do intuicji) ciąży już na całym projekcie.
Funkcjonalność to coś, co aplikacja potrafi zrobić. W prostym
przykładzie bloga to możliwość dodania wpisu, edycji, dodania
komentarza, usunięcie ich etc.
Pod pojęciem "bajery" kryje się to co widać: ładne ikonki, dobra
organizacja elementów na stronie (menu, przyciski, linki), AJAX (tak, wg
mnie to bajer wizualny, ale o tym później), web 2.0-owe pregress bars i
indicators ;)
(Ten post jest kontynuacją http://webbricks.blogspot.com/2008/04/czego-tak-na-prawd-ode-mnie-chcesz.html)
W czym tak na prawdę tkwi problem: w zatraceniu się w pierdołach. Ty
budując aplikację (szczególnie od zera, gdy jest BARDZO niedojrzała)
musisz skupić się na funkcjonalnościach, które ma wypełniać. Jednak
bardzo łatwo ulec pokusie zbyt wczesnego upiększania aplikacji.
Nie podoba Ci się jak domyślnie wygląda tabelka, zamiast linka edytuj
fajnie by było mieć ikonkę, a treści mogłyby się dodawać bez
przeładowania strony... i zaczynasz tworzyć style tylko dla tej tabelki,
umieszczasz ikonki w niepełnym layoucie, implementujesz Ajaxa nie
wiedząc co jeszcze będzie w tym widoku. Efekt jest taki, że robisz
rzeczy na tym etapie niepotrzebne, które są pracochłonne i nie przynoszą
satysfakcji.
Do tego odrywasz się od głównego problemu, który brzmi "zbuduj
DZIAŁAJĄCĄ aplikację", który jest święty i nadrzędny. Bez osiągnięcia
tego celu, upiększenia na które straciłeś tyle czasu i energii, są
niepotrzebne. Poza tym, gdy nie masz doświadczenia i intuicji kogoś kto
ma pięcioletnie doświadczenie w budowaniu aplikacji, bardzo łatwo coś
popsuć (szczególne za pomocą wszędobylskiego Ajaxa <o tym poniżej>).
Nie jestem przeciwnikiem Ajaxa, uważam ten trick (bo przecież nie
technologię) za coś fantastycznego, jednak użyty w niewłaściwym momencie
może wiele popsuć. Jest jak czosnek, który poprawia smak smażonych
potraw, ale dodany za wcześnie jest gorzki i obrzydliwy. Tak samo zbyt
wczesna implementacja rozwiązań w Ajaxie sprawi, że projekt stanie się
trudny w trawieniu.
Dużo lepszym, IMHO, podejściem jest stworzenie aplikacji, która będzie
działać w "czystym" html-u. Łatwiej ją przetestować, a tym bardziej
debugować. Pozbyć się w tym czasie poważnych błędów, zaprojektować
interfejs i dopiero wtedy skupić się na tym, żeby aplikacja była miła
dla oka. Twierdzę, że w tym momencie nie będziesz implementował w
funkcjonalności nic ponad proste, wspomagające funkcje współpracujące z
requestami ajaxowymi. Jestem niemal pewny, że większość tych requestów
będzie mogła działać na standardowych funkcjach, które już
zaimplementowałeś (ew. po drobnej przeróbce).
Podejście od przeciwnej strony owocuje powstaniem osobnych,
specyficznych funkcji dla Ajaxa, obok standardowych. Poza tym
wykrywanie, namierzanie i usuwanie błędów jest trudniejsze.
Nie wiem czy Cię, drogi czytelniku, przekonałem? Jeśli nie, to nie
szkodzi. Jeśli jesteś programistą, to sam pewnie stwierdzisz, że przy
"przeajaxowaniu" projektu w początkowej fazie tylko Ci przeszkadza.
Jeśli jesteś menadżerem, to nie Ty się będziesz z tym problemem użerał
bezpośrednio (jeśli jednak zauważysz, że projekty jakoś dziwnie grzęzną
przy pewnym etapie produkcji, to zastanów się, czy to nie jest problemem).
I tu otarliśmy się o drugą stronę medalu - odbiorcę. Może nim być
klient, gdy masz własne zlecenie, albo szef/menadżer projektu, którzy
nie mają inżynierskich podstaw i inżynierskiego spojrzenia na świat (*).
Postępują oni wtedy jak typowy użytkownik: oceniają aplikację
emocjonalnie - czy się podoba, czy nie. Swoją drogą ja też tak robię,
zanim przekonam się do aplikacji, którą zaczynam używać. Uważam, że nic
w tym złego, jeśli to jest produkt finalny. Jednak na etapie budowy
aplikacji trzeba przedstawić im argumenty, dlaczego nie powinni się na
razie skupiać na wyglądzie.
Powiedz odbiorcy: "słuchaj, to jest wersja beta 1 systemu, który
zamawiałeś. Wiem, że wygląda topornie, ale nie skupiaj sie teraz na tym,
ani na pomysłach, że jakiś przycisk powinien być gdzie indziej. Skup się
proszę na rzeczach, które można za pomocą tego systemu wykonać i pomyśl,
czy to jest to czego chciałeś podając swoje wymagania."
Tu już ocieramy się o AgileDevelopment, więc doczytaj sobie o tym w
wikipedii.
Cały sens tego artykułu można zredagować tak: rdzeniem Twojej aplikacji
jest funkcjonalność. Ty jesteś specem, który nie pozwala sobie na
narzucenie sposobu myślenia klienta- dla jego własnego dobra. Klient nie
ma (bo po co miałby ją wypracowywać?) dyscypliny odpowiedniego patrzenia
na projekt. To Ty musisz mu ją narzucić. Jeśli stanie się na odwrót Ty
zaplączesz się w niuansach i komplikacjach, ktoś z Was dwóch za to
zapłaci, a oboje rozstaniecie się niezadowoleni.
Niedługo coś, bez czego duży projekt obyć się nie może - baza danych i
dlaczego nie może być "nienormalna".
*- nie twierdzę, że muszą mieć. Jest mnóstwo menadżerów, którzy są z
nimi z zawodu i nie znają technologii - wszystko jest ok, jeśli uważnie
słuchają pracowników liniowych.
Brak komentarzy:
Prześlij komentarz