Każdy kto brał udział w tworzeniu serwisu internetowego, sklepu, czy programu komputerowego wie o dwóch rzeczach. Jakość jest bardzo ważna. Uzyskać satysfakcjonującą jakość jest bardzo trudno.

Można myśleć o testach jednostkowych, behawioralnych, automatycznej integracji. Nawet trzeba, bo to wszystko jest bardzo potrzebne. Z mojego doświadczenia przy projektach IT wynika jednak, że najlepsze narzędzia zapewnienia jakości – nie zadziałają same w sobie, jeśli nie będziemy ich odpowiednio używać. Jeśli nie umiejscowimy ich w pewnego rodzaju procesie.

Proces wytwarzania nie brzmi zbyt zachęcająco, zwłaszcza jeśli jest się startupem lub małą – bardzo zmotywowaną firmą. Też tak uważam, jestem przeciwnikiem wszystkich narzutów które zmniejszają wydajność zespołu.

Dlatego w Divante wymyśliliśmy na samym początku prosty sposób, który sprawdza się – po odpowiednim rozbudowaniu i adaptacji do dzisiaj.

Checklisty zapewnienia jakości – bo o nich mowa –  w Divante nazywamy  DQAS – Divante Quality Standard Assurance :-) Nazwa brzmi dumnie, a została wymyślona na początku naszej firmy – jako ładny i elegancki akronim używany do podsumowywania aplikacji na stanowiska programistów. Zawsze podczas rekrutacji analizuję kod kandydata, jeśli nie był wystarczająco dobry, czy bezpieczny – wystarczało napisać: „Pański kod nie jest zgodny z praktykami DQAS stosowanymi w naszej firmie.” :-)

Ale wróćmy do tematu. Listy o których mówię  dotyczą u nas różnych aspektów tworzenia projektu:

  • aspektów związanych z pisaniem kodu,
  • aspektów związanych z użytecznością,
  • aspektów związanych z SEO,
  • aspektów związanych z zarzadzaniem projektami i obsługą klienta.
Checklisty mogą mieć prostą formę dokumentów tworzonych na Google Docs – do których dostęp ma cały zespół. U nas checklisty mają nieformalną postać, są często zabawne – a co najważniejsze – tworzone przez cały zespół. W ten sposób listy gromadzą wiedzę całego, interdyscyplinarnego zespołu.
Lista zapewnienia jakości nie zastępuje wiedzy eksperckiej i samych ekspertów 😉 Jest to totalne minimum, które zawsze musi być spełnione abyśmy mogli myśleć o przejściu z projektem na następny etap, pokazaniu klientowi produktu czy wreszcie wypuszczeniu go „na produkcję”.
Zauważyłem, że takie listy – jeśli nie są zbyt długie – pełnią też świetną funkcję dydaktyczną dla nowych pracowników. Ktoś kto przychodzi do zespołu od razu wie, jakie są standardy czego musi się trzymać. Jako, że listy są tworzone przez zespół i każdy może coś dopisać – każdy czuje się współodpowiedzialny za dotrzymywanie jakości.
Taka przykładowa lista dla programistów u nas wygląda tak (tylko fragment):
  • Nie używać komunikatu „Brak danych.” To jak cios w twarz użytkownika. Należy nawiązać kontakt z użytkownikiem i wpisać np. „Aktualnie nie mamy produktów których szukasz. Nie czekaj i sprawdź nasze promocje, może tam znajdziesz cios dla Ciebie!”
  • Nie mieszać w kodzie nazw polskich i angielskich
  • Commitować do SVN kod po każdej zmianie, która nie niszczy wersji testowej.
  • Przed pokazywaniem do testów sprawdzić czy wszędzie są równe marginesy (przyciski, obrazki, logo …)
  • Jeśli HTML nie jest fajny pod SEO, to nie jest fajny. Struktura nagłówków, semantyka, alty, divy zamiast tabelek, tagi meta, dobre linki
  • Wzorce projektowe są dla ludzi. Kto ich nie wykorzystuje na 99% pisze słaby kod obiektowy. „
  • Kto nie stosuje reguły DRY nie potrafi programować :-)
  • Cache też jest dla ludzi, kto nie cacheuje niech się nie tłumaczy, że oprogramowanie wolno działa. Ma działać szybko.
  • Szybsze jest lepsze niż wolne. Dużo lepsze.
  • Brak favicony serwisu świadczy o bałaganiarstwie.
  • Jeśli znienacka atakują cię wyjątki, to wiedz, że coś się dzieje… Loguj wszystkie wyjątki do pliku lub dziennika PHP razem z tracem aby można było zdebugować kod. Checklisty checklistami, raczej mówią jak prowadzić projekt. Dekalog DQAS to kwestia honoru dla programisty.
  • Wyświetlanie wyjątków na produkcyjnym serwerze jest jak publikowanie gołych fotek na fotka.tv
  • „Nie używać echo ‚dupa’ lub jakichś innych dziwnych słów – mogą tam zostać
  • Programuj koszernie. ( http://pear.php.net/manual/en/standards.php )
  • „Zawsze eskejpuj wejście, żebyś nie ucierpiał na iniekcje kodu!
Jak widać, mało tu formalizów :) Jasne, że oprócz list używamy masy innych narzędzi – systemu ticketowego, kontroli wersji, testów jednostkowych, testów wydajnościowych, testów bezpieczeństwa, generalnie – mnóstwa testów.
Ostatnio podczas spotkania z jednym z klientów branży modowej klient zauważył „U państwa nawet programiści mówią o monetyzacji” – odnosząc się do tego, że nasz programista przedstawił kilka pomysłów na zwiększenie sprzedaży w serwisie – m.in. przez użycie rekomendacji i optymalizację ścieżki zakupowej.
Cieszą mnie takie komentarze i wkręcam sobie, że dowodzą iż DQAS ma sens :-) Każdy z pracowników powinien myśleć o ostatecznym celu w jakim realizujemy produkt – sprzedaży, oglądalności, ….
Co myślicie o takim pomyśle? Jakie stosujecie metody zapewnienia jakości u siebie?