Narzędzia deweloperskie

Sama technologia to za mało. Potrzebne są jeszcze właściwie dobrane i porządnie naostrzone narzędzia.

 
 
 

Do tego, aby na podstawie wymagań stworzyć wyrafinowany system informatyczny, sama technologia nie wystarczy. Podobnie jak w warsztacie stolarskim - poza dobrym materiałem niezbędne są właściwe i porządnie naostrzone narzędzia. Od wielu lat dbamy o nasz „park maszynowy”, aby w jak najbardziej efektywny sposób wytwarzać systemy o wysokiej jakości. Śledzimy na bieżąco rozwój narzędzi deweloperskich na świecie i stosujemy najlepsze z nich, a tam gdzie tego wymaga specyfika naszego procesu wytwarzamy własne.

Wygodne środowisko pracy

Pracujemy w najbardziej przyjaznym dla inżyniera systemie operacyjnym jakim jest system Linux. Kod tworzymy głównie korzystając z Eclipse'a, ale równie często wspieramy się porządnym edytorem tekstu i narzędziami tekstowymi samego Linux'a. Korzystamy z wirtualizacji na poziomie systemu operacyjnego (VMWare), aby móc testować nasze rozwiązania na innych systemach operacyjnych i korzystać z dostępnych tam narzędzi.

Korzystamy z GIT'a jako systemu kontroli wersji kodu źródłowego, a z maven'a jako systemu budowania. Dla wszystkich budowanych przez nas systemów tworzymy dedykowane środowiska testowe, za pomocą których nasi menedżerowie a następnie klient na bieżąco mogą weryfikować efekty procesu dewelopmentu.

Szczególną uwagę poświęcamy temu, aby cykl od wprowadzenia zmiany w kodzie do obejrzenia jej efektów w rzeczywistym systemie był jak najkrótszy. Od samego początku naszej działalności rozwijamy narzędzie pozwalające skrócić ten cykl, a w ostatnich latach korzystamy z narzędzia JRebel. Dzięki temu nasi inżynierowie są w stanie obejrzeć efekty swojej pracy natychmiast.

Środowisko deweloperskie uzupełnia narzędzie do ciągłej integracji Jenkins, które na bieżąco wyłapuje większość niedociągnięć związanych z dewelopmentem projektów. W środowisko to wbudowane jest automatyczne uruchamianie testów jednostkowych JUnit oraz funkcjonalnych iMacros.

Efektywna komunikacja w zespole

Tworzenie oprogramowania to gra zespołowa, dodatkowo tocząca się bardzo długo. Czas życia naszych systemów to zazwyczaj pięć do siedmiu lat. Wymaga to od nas stosowania wielu różnych typów i form komunikacji między uczestnikami projektu.

Całość spraw związanych z prowadzeniem i dewelopmentem projektów obsługujemy za pomocą systemu obsługi zgłoszeń JIRA. Dużą zaletą tego systemu jest asynchroniczność komunikacji, co ogranicza przerywanie pracy innym osobom oraz pozwala każdemu lepiej zorganizować własny dzień pracy.

Z kolei wszelką zdobytą wiedzę, jak również standardy, procedury, czy instrukcje gromadzimy w Confluence Wiki.

Staramy się nie traktować ortodoksyjnie naszych narzędzi komunikacyjnych. Czasami zamiast opisywać złożony problem jako zgłoszenie w jirze, efektywniej jest porozmawiać przez telefon lub zorganizować krótkie spotkanie.

Dużą wagę przykładamy do komunikacji nieformalnej. Staramy się tworzyć w firmie takie warunki, które sprzyjają tego typu wymianom myśli. Wiele nietrywialnych problemów udało nam się rozwiązać podczas niezobowiązujących rozmów przy kuchennym stole.

Praca z kodem to praca z tekstem

W czasie wszechobecnych zintegrowanych środowisk deweloperskich, wizardów, podpowiadaczek i tym podobnych wodotrysków nie zapomnieliśmy, że tworzenie oprogramowania to przede wszystkim praca z tekstem. Dlatego poza doskonałą znajomością Eclipse'a podstawowym elementem warsztatu pracy naszych deweloperów jest znajomość i umiejętność posługiwania się narzędziami do obróbki tekstu.

Każdy z naszych deweloperów biegle posługuje się co najmniej jednym dodatkowym profesjonalnym edytorem tekstu. Nie przejmujemy się wojnami prowadzonymi między użytkownikami poszczególnych edytorów (np. vi kontra emacs). Każdy z nas używa i doskonali się w obsłudze edytora, który mu najbardziej odpowiada.

Perfekcyjnym uzupełnieniem dobrego edytora tekstów są Linux'owe narzędzia do obróbki tekstu (cat, grep, sort, sed, awk itp.). W połączeniu z potokami, czyli przekazywaniem standardowego wejścia i wyjścia, stanowią bardzo silne narzędzie. Dodatkowo ich nauczenie się nie jest szczególnie trudne.

Dobra znajomość tego typu narzędzi przydaje się nam również na etapie utrzymania systemu. Z łatwością jesteśmy w stanie prowadzić rozbudowane analizy pracy naszych systemów w oparciu o tekstowe zapisy zdarzeń (ang. logs).

Jesteśmy otwarci na inne języki programowania

Java stanowi podstawę naszej wiedzy programistycznej. W tym języku piszemy systemy dla naszych Klientów oraz cześć narzędzi na własny użytek. Cały czas jednak śledzimy dynamiczny rozwój innych języków, zwłaszcza że coraz częściej są one implementowane na platformę JVM.

Dlaczego znajomość innych języków czy innych paradygmatów programowania jest dla nas cenna?

Przede wszystkich dlatego, że pozwala nam spojrzeć na programowanie systemów z innej, szerszej perspektywy. Widzimy inne możliwości rozwiązywania tych samych problemów. Bardzo często prostsze i lepsze niż w języku, którym się na co dzień posługujemy. Możliwości te inspirują nas potem do zmiany stylu programowania, nawet jeśli nie zmieniamy języka.

Efektem naszych poszukiwań są między innymi:

  • zastosowanie języka funkcyjnego Clojure do programowania warstwy wizualnej naszych aplikacji (szablony stron),
  • użycie Python'a w wielu narzędziach, które służą utrzymaniu systemów.

Testowanie jako proces twórczy

Lubimy doprowadzać nasze oprogramowanie do perfekcji. Dlatego do testowania systemów przykładamy wyjątkową wagę. Testowanie to specyficzny aspekt tworzenia systemów. Wielu osobom kojarzy się z katorżniczą pracą specjalnego zespołu, który całkowicie ręcznie odtwarza działania końcowego użytkownika. Wiele firm stosuje tego typu podejście. Uważamy, że jest ono totalnie nieefektywne. My koncentrujemy się na programowaniu testów i automatyzacji procesu ich uruchamiania. U nas testowanie jest procesem twórczym!

Na poziomie podstawowych komponentów oprogramowania (klasy, moduły) korzystamy z testów JUnit. Aby zapewnić sobie informację zwrotną o tym jak dobrze nasz kod jest przetestowany korzystamy z narzędzia EMMA. Pozwala ono analizować stopień pokrycia kodu testami. Oba narzędzia są wkomponowane w mechanizm budowania aplikacji.

Funkcjonalność systemu dostępną dla końcowego użytkownika testujemy za pomocą narzędzia iMacros. Umożliwia ono zapisanie interakcji użytkownika z systemem uruchomionym w przeglądarce internetowej, a następnie wielokrotne jej odtworzenie.

Zarówno testy jednostkowe jak i funkcjonalne włączone są w proces ciągłego budowania kodu (ang. continuous integration build). Takie połączenie zapewnia nam szybkie sprzężenie zwrotne i pozwala na błyskawiczną reakcję w przypadku wykrycia problemu.

Przed wieloma z naszych systemów stawiane są bardzo duże wymagania wydajnościowe. Wymaga to od nas prowadzenia testów wydajnościowych zarówno przed wdrożeniem produkcyjnym jak i po każdej istotnej zmianie. Niestety żadne z dostępnych narzędzi komercyjnych jak i Open Source nie było w stanie sprostać naszym wysokim wymaganiom w tym zakresie (symulacja skomplikowanych procesów biznesowych przy jednoczesnym obciążeniu idącym w setki megabitów ruchu). Dlatego wytworzyliśmy własne narzędzia i z powodzeniem stosujemy je w naszych największych  projektach.

Utrzymanie systemów też wymaga narzędzi

Oprócz narzędzi związanych z samym wytworzeniem systemów posiadamy szereg narzędzi związanych z ich utrzymaniem produkcyjnym. Dużą część z nich wytworzyliśmy samodzielnie. Są to przede wszystkim narzędzia do:

  • monitorowania aplikacji, serwera aplikacji oraz bazy danych,
  • automatyzacji procesów instalacji i aktualizacji aplikacji,
  • prowadzenia testów obciążeniowych i analizy ich wyników.

Bowiem prawdziwą sztuką nie jest wykonanie systemu a zapewnienie jego sprawnej pracy przez wiele lat ciągłej eksploatacji. Pamiętamy, że każdy system w czasie swojego wieloletniego życia podlega różnym zmianom i usprawnieniom, a niejednokrotnie poważnym przebudowom. Dlatego jego utrzymanie stanowi poważne wyzwanie, wymagające dodatkowych kompetencji - często odmiennych od tych, które są niezbędne do stworzenia oprogramowania.

 
 

Oglądaj nasz kanał na YouTube

 
 

Masz pytanie?

 
 
 
Jarosław Błąd
 
Jarosław Błąd

Dyrektor Pionu Produktów

jaroslaw.blad at e-point dot pl