Programowanie jako modelowanie

Czym zajmuje się programista? Pisaniem kodu, konfiguracją środowisk, debugowaniem, integracją z zewnętrznymi systemami? Z pewnością, ale czy jest to istota jego pracy?

Implementacja systemu wymaga wiedzy co ma być zaimplementowane. To dość banalne i oczywiste stwierdzenie jednak wiele projektów IT rozbija się właśnie o to, że nie do końca wiadomo co trzeba zrobić. Często też ta wiedza, określana zwykle jako wymagania, dezaktualizuje się w bardzo szybkim tempie. Nawet jeżeli w danym momencie wydawało nam się, że wszystko wiemy, to już po kilku tygodniach lub miesiącach okazuje się, że wiele jednak brakowało. Dlaczego tak się dzieje?

Zmieniające się wymagania

Zespoły często narzekają na ciągle zmieniające się wymagania, przez co nie sposób utrzymać wysokiej jakości kodu, a w efekcie wprowadzać kolejnych wymagań w akceptowalnym dla biznesu tempie. Przyjrzyjmy się jednak temu nieco dokładniej. Czy to same wymagania się zmieniają? Czy może raczej kolejne wymagania zupełnie nie pasują do kodu, który już wytworzyliśmy?

Same wymagania oczywiście potrafią się zmieniać. Może to wynikać zasadniczo z dwóch przyczyn:

• koncepcja biznesowa nie jest jeszcze wyklarowana
• doszło do niezrozumienia na styku biznes - IT

Pierwsza przyczyna jest trudna do eliminacji, na drugą możemy jednak coś poradzić. Tylko co da nam dotarcie komunikacji na linii biznes - IT, jeżeli kolejne wymagania i tak będzie trudno wpasować w istniejący kod?

Tu dochodzimy do drugiego z wymienionych na początku problemów. Niestety znacznie częściej nowe wymagania trudno jest wkomponować w system, niż dochodzi do faktycznej zmiany jednego ze starych wymagań. To nie jest problem po stronie biznesu tylko po stronie IT.

Analiza to coś więcej niż zbieranie wymagań

Skąd biorą się wymagania? Zazwyczaj są one “zbierane” w procesie zbierania wymagań, którym zajmują się najczęściej analitycy. Samo zebranie wymagań to jednak zbyt mało, aby powstał utrzymywalny system.

Jak wygląda powstawanie systemu sterowane kolejnymi “zebranymi” wymaganiami? Na początku tworzony jest jakiś zestaw abstrakcji (encji, tabelek, endpointów, etc.), dla pierwszego zestawu wymagań. Później przychodzą kolejne, które wymagają lekkiej modyfikacji istniejących abstrakcji i dodania kolejnych. Za każdym razem celem jest spełnienie wymagań jakiejś konkretnej funkcji systemu. Wymagania są więc z konieczności nakierowane na tę konkretną funkcję. Prowadzi to do traktowania ich do pewnego stopnia w izolacji.

A gdzie w tym wszystkim analiza? No właśnie, analiza to nie jest zbieranie wymagań, tylko dogłębne ich zrozumienie w kontekście działania systemu i zbudowanie na tej podstawie zestawu abstrakcji, które odzwierciedlają domenę, a nie oderwane wymagania.

Analiza wymaga więc zawsze szerszego kontekstu niż nowa funkcja dodawana do systemu.

Analiza wymaga też o wiele głębszego zrozumienia biznesu niż jest to konieczne do spełnienia kryteriów akceptacyjnych aktualnego zadania.

Czego brakuje?

Czego często brakuje w procesie wytwarzanie oprogramowania? Właśnie tej dogłębnej analizy, która przekłada się na opracowanie modelu.

Wytwarzanie oprogramowanie to tworzenie modelu rzeczywistości. Czym jest ta modelowana rzeczywistość? Jest to działalność operacyjna firmy, często określana w IT jako domena. Może to być handel książkami w internecie, planowanie procesów produkcji, albo diagnostyka medyczna. Istotne jest to, że w ramach domeny danego przedsiębiorstwa interesuje nas to jak działa to konkretne przedsiębiorstwo. Modele dla różnych firm z tej samej branży mogą się różnić.

Model to głęboka wiedza domenowa ujęta w trafne, zrozumiałe dla biznesu abstrakcje. Kod to jedynie formalny zapis tego modelu. Istotne jest to, żeby zarówno biznes jak i IT miały w głowach ten sam model. Jeżeli te modele są różne, to będziemy mieć do czynienia z problemem “niepasujących wymagań”.

Analiza to tworzenie modelu. Kto powinien się więc nią zajmować? Najlepiej cały zespół, chociaż oczywiście różne osoby będą w tym uczestniczyły w różnym stopniu. Istotne jest to, żeby nie był to t.zw. model analityczny, który jest najczęściej nieimplementowalny. Udział osób o kompetencjach technicznych jest tu konieczny.

Czy może istnieć “fabryka” oprogramowania?

Sukces automatyzacji produkcji w ciągu ostatnich stu lat doprowadził do wykorzystania metafory taśmy produkcyjnej o wiele częściej niż miało to sens. Metafora ta pokutuje niestety również w procesie wytwarzania oprogramowania.

Dlaczego jest to błędne podejście? Tworzenie modelu nie jest mechanicznym procesem jak montaż samochodów na taśmie produkcyjnej. Bardziej przypomina ono pracę kogoś kto projektuje tę taśmę, niż dokonuje na niej montażu. Montaż wykonują komputery przetwarzając informacje zgodnie z regułami wyznaczonymi przez model.

Z tego względu programiści nie są łatwo zastępowalni, gdyż model znajduje się w ich głowach. Nowy programista nie będzie produktywny dopóki nie odtworzy tego modelu we własnym umyśle, a tego nie da się zautomatyzować.

Ponadto samo opracowywanie modelu to proces twórczy, w którym najistotniejsze jest zrozumienie otaczającej nas rzeczywistości i ujęcie w system takich abstrakcji, które da się zaimplementować środkami jakimi w danym momencie dysponujemy.

Czy modelowanie jest opłacalne?

Jeżeli system nie służy jedynie do zbierania i wyświetlania danych (CRUD), to jest nie tylko opłacalne, ale krytyczne. Bez dobrego zrozumienia biznesu i opracowania modelu wiernie odzwierciedlającego rzeczywistość, utrzymanie systemów IT w dłuższej perspektywie staje się koszmarem zarówno dla biznesu jak i IT.

Kolejne artykuły w tej serii będą analizą różnych wzorców i technik przez pryzmat tego, co z rzeczywistości biznesowej one modelują. Patrzenie na narzędzia, które stosujemy na co dzień, w ten sposób, może ułatwić zrozumienie, dlaczego pewne techniki mają sens i w jakich granicach mają one sens.

1. Programowanie jako modelowanie
2. Czym jest model?
3. Jakiego modelu potrzebujemy
4. Czy logika aplikacyjna to część modelu domeny?
5. Co modelują transakcje?
6. Co agreguje Agregat?
7. Czy Saga to transakcja rozproszona?
8. Kim jest modelarz?