Czas w projekcie jest zasobem. Kluczowym zasobem, który ma jedną bardzo interesującą cechę. Czym bliżej końca tym jego relatywna długość się skraca, a wartość drastycznie wzrasta.
Końcowa faza projektu to okres najbardziej intensywnej pracy z błędami, rozumianymi szeroko – zarówno jako rzeczywiste błędy, zmiany, czy też doprecyzowania.
W projekcie, który ostatnio się zakończył pojawiło się kilka interesujących przypadków błędów. Chcę tutaj przedstawić trzy z nich. Nie były one krytyczne i nie mogły zaważyć na powodzeniu projektu. Samo ich wystąpienie nie było również niczym złym, błąd to integralna część każdego projektu.
Te konkretne przypadki są o tyle interesujące, że nie zostały wykryte podczas testów deweloperskich, czy testerskich. Ważne jest również to, że nie zostały zgłoszone przez klienta. Zlokalizowano je podczas zaplanowanego wcześniej czasu na stabilizację rozwiązania.
Klika słów wprowadzających w sam projekt. Jego głównym celem było stworzenie złożonych raportów SSRS. Do osiągnięcia celu wymagane były trzy rzeczy: poprawne dane w głębokim źródle, implementacja procesu, które je przeliczał, oraz pobieranie i wyświetlanie informacji w raportach.
Przechodząc do konkretów.
Trochę o refaktoryzacji.
Tylko dlaczego piszę o refaktoryzacji, a nie optymalizacji? Językiem projektu był T-SQL. W kontekście języków bazodanowych, rzadko słyszy się o pierwszym zabiegu. Nie rozumiem dlaczego, kodowanie to kodowanie, ale to temat na inny artykuł. W tym przypadku zapytanie zostało przepisane ponieważ było „brzydkie”. Długie i trudne w czytaniu. Oprócz zmiany wyglądu udało się znacznie poprawić dwa inne, kluczowe (optymalizacyjne) czynniki: obciążenie bazy oraz wydajność.
Zapytanie zwracało dane w DataSet dla jednego z wykresów. Raport z pierwotnym zapytaniem działał w sposób poprawny, w akceptowalnym przez klienta czasie. Po refaktoryzacji działał lepiej.
Można zapytać dlaczego brak refaktoryzacji uważam za błąd. Podstawowa odpowiedź to dług technologiczny. Załóżmy jednak, że to zbyt odległy problem. Co w takim razie mogło być nie tak, skoro pierwotne zapytanie zostało przez klienta odebrane? Wydajność całego, złożonego rozwiązania. Produkt docelowy składał się z kilkudziesięciu podobnych zapytań (częściowo również przepisanych). Po złożeniu wszystkiego w całość mogło okazać się, że kryterium wydajności nie będzie spełnione. Tutaj znalazł się czas na refleksję, na przemyślenie składni i logiki. Dzięki temu wydajność nie stanowiła problemu.
Poniżej metadane zapytania:
Pierwsza linijka dotyczy zapytania pierwotnego, druga zapytania po refaktoryzacji. Różnice widoczne. Komentarz zbędny.
Refaktoryzacja powinna być zawsze częścią projektu. Czas na przemyślenie rozwiązania musi być zaplanowany. Byłoby super gdyby nie był za nią odpowiedzialny autor bazowego rozwiązania. Świeże spojrzenie zawsze w cenie. 😉
Trochę o jakości.
Jednym z elementów projektu było stworzenie procedur przeliczających dane. Proces pobierał konkretne wartości z surowego ciągu znaków i przeliczał je zgodnie z regułami biznesowymi. Dla niektórych wyliczeń czasowych, wartości w sekundach należało zagregować do godzin/minut/sekund. I tu pojawił się błąd. Spowodowany przez źle wstawiony nawias.
Oba fragmenty kodu działają, a co gorsza tylko dla niektórych zdarzeń o określonych nazwach zwracały różne wartości.
Poniżej niepoprawne wyniki:
Poniżej poprawne wyniki:
Problem został wykryty podczas wyrywkowego sprawdzania spójności końcowego raportu. Różnice w wyliczeniach były na tyle niewielkie (1-3 minuty), że zostały zauważone dopiero przy użyciu innej metody wyliczeniowej.
Nie liczy się sam wynik, ale jego poprawność. Truizm, ale powyższy przykład dobrze go obrazuje. Naprawa błędu była banalnie prosta, trudniejsze było jego znalezienie. Najważniejsze jest jednak to, że błąd udało się wykryć przed rzeczywistym uruchomieniem systemu. Nauka płynąca na przyszłość? Każde wyliczenie matematyczne sprawdź dwoma sposobami.
Trochę o danych testowych.
Przygotowywane przez nas raporty miały być wielojęzyczne. Językiem developmentu był angielski. Siłą rzeczy tłumaczenia mogły pojawić się dopiero po zamknięciu procesu wytwórczego. Niestety nie dało się tego obejść.
Część wykresów prezentowała dane roczne w agregacji miesięcznej. Początkowo na wykresach miały się wyświetlać numery miesięcy. Klient poprosił nas, aby zastąpić je nazwami. Ze względu na ograniczoną ilość miejsca zastosowaliśmy 3-literowe skróty. Poniżej wersja angielska:
Problem pojawił się w wersji francuskiej:
W czym tkwi problem? W nagłym skoku wartości w miesiącu „Jui”. W miesiącu czy w miesiącach? W języku francuskim czerwiec to „Juin”, lipiec to „Juillet”. 3-literowy skrót: „Jui”. Rzecz banalna do naprawy. Wystarczyło zmienić wartość, po której odbywało się grupowanie. Przypadek nie do wykrycia bez właściwych danych testowych.
Wykres po zmianie:
Dane testowe muszą być pełne. Pod każdym względem. O ile jeszcze można spreparować ich ilość, gorzej z kompletnością. Preparacja rzeczywistości jest zadaniem karkołomnym. Chociaż w tym przypadku problemu można było uniknąć. Wystarczyło nie używać do agregacji wartości zależnych językowo. Nauczka na przyszłość.
Jakieś wnioski z powyższych przykładów?
Okres stabilizacji systemu nie powinien być jedynie marzeniem programisty, ale od samego początku zaplanowanym etapem w projekcie. Bez względu na jego wielkość. To taki czas na drugi oddech. Mamy gotowe, działające rozwiązanie. Najcięższa praca już za nami. Możemy teraz odetchnąć i zobaczyć, jak teoria przerodziła się w praktykę. A przy okazji coś dopieścić, bo tego nigdy nie za dużo. 😉
Zostaw komentarz