Poliglota w IT

Poliglota to osoba znająca wiele języków. Umiejętność ta pozwala kontaktować się werbalnie lub pisać w wielu językach świata. Zliczając języki naturalne i te służące programowaniu można zauważyć że jednych i drugich jest tak samo dużo. Czy zatem w programowaniu bycie poliglotą daje podobne do w/w korzyści?

Odpowiedzią jest idea PPP (Poly-Paradigm Programming). Idea ta zakłada, że do rozwiązywania problemów spotykanych w dzisiejszych systemach i aplikacjach konieczne jest używanie wielu języków a nawet wielu architektur. Dzięki takiemu podejściu jesteśmy elastyczni, lepiej dostosowani do konkretnych wymagań, nie próbujemy tworzyć wszystkiego jednym „młotkiem”. Oczywiście są pewne koszty, wzrasta złożoność, wymagane są szersze kompetencje, jest więcej miejsc styku gdzie architektury i języki muszą współpracować.
Rozważmy kilka problemów, bardzo często spotykanych w systemach ERP-CRM, oraz ich rozwiązania na przykładzie platformy Streamsoft NEXT która mocno czerpie z idei PPP.

Problem:
      Bardzo wolny czas wprowadzania zmian
Nowe wymagania, lub szybko pojawiające się potrzeby trudno pogodzić z powolnym i ociężałym procesem developerskim. Klienci nie chcą, nie mogą czekać.

Rozwiązanie:
      Komponenty + Skrypty (Java + Groovy)
Komponując system z dwóch bytów, wydajnych i przetestowanych z dobrze zdefiniowanym interfejsem komponentów, oraz z dynamicznych skryptów, które organizują te komponenty w elastyczne i szybko rekonfigurowalne scenariusze, rozwiązujemy kompleksowo problem. Stosujemy dwa języki, dwa podejścia. Kluczem jest takie dobranie obszarów aby złapać jak najwięcej korzyści jak najmniejszym kosztem zwiększenia złożoności.

Problem:
      Manualne tworzenie generycznych UI
Interfejs użytkownika w dużej części jest powtarzalny i generyczny, tworzenie go za każdym razem od zera, ręcznie, tworząc kod imperatywny, jest źródłem zła w wielu systemach. W dodatku … któż by chciał grzebać się w UI.

Rozwiązanie:
      Deklaratywne UI (Java + XML)
Po prostu UI nie tworzymy wcale, generujemy je na podstawie modelu danych i jego atrybutów, szczegóły topologiczne można zdefiniować także deklaratywnie za pomocą np. XML. Mniej pracy, przyjemniej, a otrzymane efekty są wyższej jakości.

Problem:
      Mozolne i czasochłonne kodowanie raportów
Wydruki i raporty są z jednej strony bardzo złożone a z drugiej strony można dostrzec w ich konstrukcji powtarzające się elementy (nagłówek, stopka, tabelka, tło, formatowanie), ręczne programowanie wydruków nawet przy zastosowaniu dobrych narzędzi (iText) nie jest łatwe. W dodatku … któż by chciał robić wydruki.

Rozwiązanie:
      Wydruki deklaratywne (XML + Runtime)
Łatwiej i efektywniej jest wydruk opisać deklaratywnie, np. w jakimś graficznym edytorze WYSIWYG, potem użyć specjalizowanego środowiska uruchomieniowego, które na podstawie modelu i źródła danych stworzy gotowy wydruk.

Przykłady można mnożyć, wszystkie powodują wspólną refleksję:

do danego problemu istnieje zbiór rozwiązań bliskich

optymalnemu, dane rozwiązanie jest bliskie optymalnemu tylko

na pewnym podzbiorze problemów

Implikacje powyższego są rozległe. Zawsze jak słyszę wypowiedzi „ekspertów” w rodzaju „SQL się nie nadaje, a noSQL jest super”, „ja używam tylko Ruby”, albo „Scala wykosi wszystko” oczywistym staje się pytanie o kontekst. Do czego ma być ta Scala czy Java taka dobra? Oczywiście do pewnej klasy problemów jest, ale do innych … niekoniecznie.

Uczmy się zatem języków, przyswajajmy technologie i architektury, bądźmy poliglotami w IT, to daje duże korzyści.