Warunki są miejscem, w którym przepływ przestaje być czytelny najszybciej. Kilka zasad temu zapobiega.
Warunek na początku
Odrzucenie przypadków nieobsługiwanych na samym starcie. Reszta przepływu zajmuje się wtedy jedną sytuacją. Filtr na wejściu ma jeszcze jedną zaletę: zdarzenia, które i tak nie zostaną obsłużone, nie zużywają kolejnych kroków.
Warto zapisać wprost, czego przepływ nie obsługuje. Zdanie „pomijamy zamówienia z płatnością przy odbiorze” w opisie przepływu oszczędza późniejszego śledztwa, dlaczego część spraw nigdzie nie trafiła.
Ścieżki zamiast zagnieżdżeń
Trzy równoległe ścieżki są czytelniejsze niż warunek w warunku w warunku. To główna zasada porządkująca. Ścieżkę da się przeczytać w całości, nie cofając się do poprzednich rozstrzygnięć, i da się ją sprawdzić osobno. Jeśli ścieżek robi się zbyt wiele, to sygnał, że przepływ obsługuje kilka różnych spraw i lepiej go podzielić — o czym mówi tekst o tym, kiedy przepływ staje się za duży.
Przypadek domyślny
Zawsze obecny. Zdarzenie niepasujące do żadnego warunku musi gdzieś trafić, a nie zniknąć. Najlepiej do kroku, który zapisuje sprawę i powiadamia człowieka. Cicha utrata zdarzeń jest groźniejsza od błędu, bo nie zostawia śladu — dane po prostu nie pojawiają się tam, gdzie powinny.
Warunki na danych, nie na tekście
Porównanie identyfikatora zamiast nazwy. Nazwy się zmieniają i przepływ przestaje działać bez żadnego sygnału. Ktoś poprawi literówkę w nazwie kategorii albo doda spację i cała ścieżka przestaje się wykonywać, mimo że nic nie zgłasza błędu.
Gdy porównania po tekście nie da się uniknąć, warto ujednolicić postać: usunąć spacje z początku i końca, sprowadzić do jednej wielkości liter. Polskie znaki bywają zapisywane różnie w różnych systemach.
Wartości puste
Pole niewypełnione zachowuje się inaczej niż pole z wartością zerową. To najczęstsza przyczyna nieoczekiwanych rozgałęzień. Warunek „kwota mniejsza niż próg” zadziała dla pola pustego inaczej, niż ktokolwiek zakładał, a przy porównaniach tekstowych puste pole bywa traktowane jako wartość pasująca. Postacie danych przekazywanych między krokami opisuje tekst o przekazywaniu danych między krokami.
Sprawdzenie wszystkich ścieżek
Każde rozgałęzienie wymaga osobnej próby. Ścieżka nieprzetestowana to ścieżka niedziałająca. Do sprawdzenia potrzebne są dane, które faktycznie wpadną w każdy warunek — łatwo przygotować przypadek typowy i pominąć ten rzadki, czyli dokładnie ten, który potem zaskoczy. Zakres prób opisuje tekst o testowaniu przepływów.
Kiedy warunki to zły pomysł
Gdy reguła zależy od wiedzy, której nie da się zapisać jako porównania — oceny sytuacji, znajomości klienta, wyjątku uzgodnionego telefonicznie. Wtedy lepszy jest przepływ, który przygotowuje dane i przekazuje decyzję człowiekowi.
Podobnie przy regułach, które zmieniają się często. Warunek wpisany na stałe w schemat trzeba poprawiać przy każdej zmianie, a każda poprawka to ryzyko. Jeśli reguła ma się zmieniać, lepiej trzymać ją poza przepływem — w tabeli albo w słowniku systemu — i tylko odczytywać w trakcie wykonania.
