Idealny świat tworzenia oprogramowania – moje spojrzenie na kilka aspektów wytwarzania oprogramowania

Jest taki idealny świat gdzie:

  • każda aplikacja ma pokrycie testami w 100%, przed napisaniem metody/funkcji wiadomo jest jak ją przetestować, co jest na wejściu i wyjściu elementu
  • wraz z rozwojem aplikacji testy są utrzymywane i aktualizowane na bieżąco
  • dokumentacja do projektu zawiera niezbędne rzeczy, nawet w najdrobniejszym szczególe, jest aktualizowana na bieżąco
  • przed napisaniem pierwszej linijki kodu metody wiemy co ona ma robić

Tylko, ja nie wiem gdzie ten świat jest …

Kilka słów o dokumentacji, prototypach, założeniach aplikacji, testowaniu

Testowanie:

  • testy aby były skuteczne powinny być jak najprostsze, są one najłatwiejsze do zrozumienia i utrzymania. Nie ma co robić skomplikowanych procedur testujących, bardzo inteligentnych ale trudnych w utrzymaniu i zrozumieniu co one robią
  • jeżeli mamy starą aplikację która nie jest objęta testami, a chcemy ją objąć to należy, przyjąć inną strategię tworzenia testów:
    • jak najwięcej testów akceptacyjnych (dużych testów, sprawdzających parę funkcji następujących po sobie)
    • testowanie przy pomocy standardowych mechanizmów testowanej aplikacji, emulowanie zachować użytkownika. Wykorzystanie narzędzi typy Selenium
    • testy jednostkowe dla metod które nie będą wymagać zmian i przeróbek, tak aby dało się podpiąć do nich testy jednostkowe
    • pokryć testami 20% funkcji aplikacji, które będzie zawierało najczęściej 80% używanych funkcji
  • w przypadku nowej aplikacji, założenia są inne:
    • jak najwięcej prostych testów jednostkowych, szybkich, prostych, łatwych do utrzymania
    • testy jednostkowe (małe testy testujące poszczególne funkcje) powinny stanowić 40-60% testów,
    • testy systemowe (średnie testy, testujące 2-3 metody) 20-40%,
    • testy akceptacyjne 10-20% (duże testy, sprawdzających parę funkcji następujących po sobie)
  • lepiej nie mieć jakiś testów, niż mieć testy które nie będą rozwijane ze zmianami w aplikacji, dlaczego? Mogą one generować fałszywe alarmy, które będą rozpraszały i lekko mówiąc wkurzały programistów, gdyż mają szukać błędu którego nie ma …

Dokumentacja:

Niektórzy lubią pisać rozległe tomy dokumentacji, która powinna być uaktualniana wraz z rozwojem aplikacji. Niestety tak się nie dzieje. Dlatego moim zdaniem dokumentacja powinna być zwięzła, treściwa i opowiadać na pytania:

Odbiorca:

  • Dla kogo tworzymy produkt
  • Kto jest idealnym odbiorcą produktu – nie robimy produktu dla wszystkich, trzeba określić cechy charakteru, ile czasu poświęci na produkt
  • Spojrzenie na aplikacje od strony odbiorcy- określenie jego działań, punktów styku z aplikacją

Cechy aplikacji – najprościej powiedzieć są to przymiotniki opisujące cechy naszej aplikacji. Pozwalają na porównanie naszej aplikacji z konkurencją, określenie „jak promować produkt”, itd.

  • Lista cech nie może być rozbudowana, powinna liczyć maksymalnie kilkanaście pozycji
  • Na początku i tak nie określimy wszystkich cech, podczas tworzenia appki wyjdą nowe cechy, a niektóre wylecą w kosmos

Elementy aplikacji – poszczególne klocki naszej aplikacji,

  • Bez przesady, nie za szczegółowo. Nie przedstawiamy tutaj każdej metody
  • Przedstawiamy elementy wpływające na cechy i możliwości aplikacji. Elementy które decydują o tym czym aplikacja jest.

Możliwości aplikacji – słowa opisujące możliwości wykonania działań przez naszą aplikację. Opis pewnych reakcji w aplikacji.

  • Ogólnie bez szczegółów technicznych
  • Mogą zawierać odwołania do elementów, cech aplikacji

Prototyp – ma realizować główne cechy:

  • Narzędzie do pokazania pomysłu – szkoda tracić czasu ma pomysł, a później klapa, idzie w piasek. Niestety mi zdarzyło się parę razy zakopać swoje apki na zaawansowanym etapie
  • Umożliwiać zebranie feedbacku – najlepiej na jak wcześniejszym etapie wytwarzania produktu
  • W przypadku prostych aplikacji wystarczy stworzenie wizualizacji w czym umiemy: wordzie, excelu, photoshopie, pancie – po prostu pokazać co gdzie ma być. W przypadku bardziej złożonych aplikacji, dobrze jest wykonać interaktywny prototyp – w formie prostego programu, witryny wykonanej np.: Axure, Justinmind czy innym narzędziu do mockapów

Profesjonalizm – coś co wydaje się dziwne, ale trzeba z niego niekiedy go zmniejszyć. Nie mówię tutaj o wypuszczaniu bubla, bo jakość aplikacji mają nam zapewnić wszystkie dobre praktyki wytwarzania kodu, ale o pewnej małej rzeczy.

  • Aplikację można dopracowywać i w końcu jej nie wypuścić bo za długo będzie wytwarzana. Z tą cechą będzie się wiązał ostatni punkt …

Mniej, ale lepszej jakości …

  • Dla przykładu: gra indie gdzie ma 3-4h fajnej zabawy, niż 40-50h ale kiepskiej. A jeszcze gorzej, aplikacja ma klika i to zupełnie zabugowanych funkcji …
  • Minimum viable product – funkcje aplikacji które są niezbędne do pierwszego odpalenia produktu, ale lepiej dopracowanych i pewnie działających
  • Zasada pareto ma tez zastosowanie w aplikacjach. Na ogół 20% funkcji aplikacji używamy w 80% przypadków

To tak po krotce moje spojrzenie na temat wytwarzania oprogramowania …