Prototypowanie inaczej – część 1 Wstęp

Zarządzanie projektem zgodnie z różnymi metodykami można streścić w kilku punktach

  • Zbieranie pomysłów
  • Przygotowanie projektu teoretycznego
  • Przygotowanie interfejsów i modeli
  • Przygotowanie testów
  • Kodowanie i ciągłe testowanie
  • Oddanie kolejnej wersji/prototypu i przejście do pkt. 1

Obecnie pracuję nad narzędziem do robienia testów. Takich szkolnych, a nie JUnitowych. Postanowiłem jednak sprawdzić tu pewną metodykę. W pierwotnych zamierzeniach jest to pewna odmiana prototypowania lecz nie opiera się ona o klasyczne założenia.

Mój prototyp jest…

Ciężko powiedzieć na pierwszy rzut oka czym jest ten prototyp. Nie prototypuję tu funkcjonalności aplikacji lecz funkcjonalność kodu. Na czym to polega? W pierwszym kroku przygotowuję model, czyli obiekty biznesowe. Tylko za ich pomocą staram się napisać prostą konsolową aplikację, która będzie realizowała podstawowe cele głównego projektu.
W kolejnym kroku wybieram z mojej aplikacji wszystkie te elementy, które wiem, że będą wspólne dla różnych rodzajów aplikacji. Tak rodzą się interfejsy modelu. Są to specyficzne twory, które wiadomo, że są potrzebne w końcowym produkcie, ale różnią się implementacją na całej linii.
W następnym kroku poprawiam moją aplikację tak by wprowadzić nowe interfejsy.
Kolejnym krokiem jest wyciągnięcie z mojej aplikacji zmian w modelu. Zazwyczaj w tym miejscu pojawiają się potrzeby związane z przyjaznym tworzeniem kodu. Dodawane są nowe konstruktory, zmieniane sygnatury metod.
W kolejnym kroku staram się wyciągnąć pewne interfejsy odpowiedzialne za obsługę działań – kontrolery.
Kontrolery są już zazwyczaj zależne od tego jaką aplikację tworzymy (web, swing, konsola). Jednak na tym etapie pojawiają się też pewne niezależne elementy, które pozwalają na kontrolowanie działań biznesowych. Na przykład dodawanie pytań i odpowiedzi.
Kolejny krok to obiekty odpowiedzialne za transmisję danych. Różne technologie przekazują dane w różny sposób, ale można na tym etapie postarać się prowadzić pewne kontenery danych, one też należą do modelu.
Ostatnim krokiem jest przygotowanie walidatorów. Są one narzędziami niezależnymi od technologii i można je wyciągnąć do osobnej paczki.
Na tym kończę tworzenie pierwszego prototypu.

Co mam

  • Wyklarowany model biznesowy.
  • Najprostsze narzędzia – walidatory
  • Najpotrzebniejsze interfejsy biznesowe
  • Mogę skupić się na poprawianiu kodu

To podejście pozwala na estymację obiektów dziedziny biznesowej w momencie gdy nie mamy projektu lub jest on zbyt ogólny.

W kolejnej części pokarzę jak to jest realizowane w praktyce.

3 myśli na temat “Prototypowanie inaczej – część 1 Wstęp

  1. To można inaczej? Oczywiście wychodząc z założenia, że sami jesteśmy analitykiem, projektantem i programistą.
    Przy projekcie, który teraz pisze zauważyłem, że dużo lepiej jest poświęcić czas potrzebny na napisanie obsługi konsolowej na napisanie testów, które w zasadzie spełniają bardzo podobne zadanie.

  2. Przedstawiony przypadek, co się okaże w kolejnej części, jest dość specyficzny. Mamy model wiemy opisowo co ma robić, ale nie ma projektu w ścisłym znaczeniu. Jest to taki przypadek jak napisałeś. Jesteś naraz analitykiem, projektantem i programistą. Jednocześnie zależy ci na ułatwieniu sobie pracy.
    Testy można pisać w oparciu o jakieś przynajmniej szczątkowe informacje o strukturze programu. Tu tej struktury nie ma, a prezentowane rozwiązanie pozwala na wypracowanie jej przyjaznej wersji już w pierwszej iteracji.

  3. Już uściślam
    Piszesz:
    „[obiekty biznesowe] Tylko za ich pomocą staram się napisać prostą konsolową aplikację, która będzie realizowała podstawowe cele głównego projektu.”
    „Testy można pisać w oparciu o jakieś przynajmniej szczątkowe informacje o strukturze programu. Tu tej struktury nie ma”

    Czyli jednak struktura jakaś jest, choćby jej zarys w postaci pierwszej wersji obiektów modelu.
    Chodzi mi o to, że testami jednostkowymi można niejako zastąpić pisanie takiego prostego CLI. W trakcie ich pisania i tak trzeba spojrzeć na kod od strony „jak go będe używać”, sprawdzając czy efekt tego użycia jest poprawny. Czyli to samo co miałby robić ów lekki klient konsolowy.
    Niejako przy okazji pisanie testów (przynajmniej w moim wypadku) powstrzymują mnie od dodawania metod, których „może nie potrzebuje już teraz ale przydadzą się w przyszłości”.

Napisz odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax