Dług specyfikacji nie znika, gdy go naprawiasz. On migruje.

Naprawienie problemu nie zawsze go eliminuje. Czasami po prostu przenosisz go w inne miejsce.

Niedawno przeprowadziłem audyt projektu w celu znalezienia długu specyfikacji. Są to luki w instrukcjach, które prowadzą do błędów lub nieprawidłowego zachowania AI. Naprawiłem siedem konkretnych elementów. Po poprawkach testy przeszły pomyślnie. Wszystko świeciło się na zielono.

Ale dług nie zniknął. Przeniósł się z plików feature do definicji kroków (step definitions).

Oto czego nauczyłem się podczas naprawiania tych elementów:

  • Precyzja ma znaczenie. Zamiast mówić „odpowiedź jest szybka”, powiedz „odpowiedź zostaje zwrócona w ciągu 12 sekund od złożenia zamówienia”. To osadza czas w konkretnych ramach.
  • Unikaj niejednoznaczności. „Ponowiono 2 razy” jest niejasne. Czy oznacza to 2 próby łącznie, czy 3? Użyj „maksymalnie 2 żądania płatności łącznie”, aby mieć pewność.
  • Nazwij mechanizm. Stwierdzenie „zapas zostaje zwolniony” jest ogólnikowe. Określ, że „usługa zapasów (inventory service) otrzymuje żądanie zwolnienia dla elementu X”.
  • Usuwaj fałszywe gwarancje. Jeśli krok przechodzi, ponieważ dana funkcja jeszcze nie istnieje, usuń ten krok. Test przechodzący dla nieistniejącego przepływu to kłamstwo.
  • Zdefiniuj, co oznacza „poprawny”. Nigdy nie używaj słów takich jak „poprawny” czy „właściwy” bez podania konkretnych wartości. Użyj „zawiera order_id 123” zamiast „zawiera właściwy identyfikator”.

Zbudowałem framework, aby wykrywać te problemy. Zadawaj te pięć pytań dla każdego scenariusza:

  • Kto jest właścicielem tego scenariusza?
  • Jakie decyzje pozostają tu otwarte?
  • Czy wszystkie terminy są tutaj zdefiniowane?
  • Czy to opisuje zachowanie, czy implementację?
  • Czego brakuje w tym opisie?

Największą pułapką jest luka między tekstem a kodem. Możesz napisać idealną, precyzyjną instrukcję w swojej specyfikacji. Ale jeśli Twój kod pod spodem używa drogi na skróty, aby zaliczyć ten test, nadal masz dług.

Specyfikacja mówi: „utwórz zamówienie poprzez API”. Kod w rzeczywistości po prostu wstrzykuje zamówienie bezpośrednio do bazy danych, aby zaoszczędzić czas. Test przechodzi, ale dług przeniósł się z wymagań do implementacji.

Nie próbuj pisać idealnych specyfikacji za pierwszym razem. Napisz je, przeprowadź audyt i popraw je.

Źródło: https://dev.to/diyaburman/spec-debt-doesnt-disappear-when-you-fix-it-it-migrates-d25

Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi