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 …
Możliwość komentowania jest wyłączona.