Dobieraj swoje narzędzia z uwagą

Oryginalny tytuł: Choose Your Tools with Care

Autor: Giovanni Asproni

Współczesne aplikacje rzadko budowane są od podstaw. Składane są z istniejących narzędzi — komponentów, bibliotek i frameworków — z wielu powodów:

• Rozmiar, złożoność i wyrafinowanie aplikacji wzrasta, podczas gdy czas na ich stworzenie staje się coraz krótszy. Czas i inteligencja deweloperów będą lepiej spożytkowane, jeśli pozwoli im się skupić na pisaniu kodu związanego z logiką biznesową, a nie infrastrukturą.
• Powszechnie używane komponenty i frameworki najprawdopodobniej zawierają mniej błędów, niż te tworzone samodzielnie w firmie.
• W sieci znajduje się mnóstwo oprogramowania o wysokiej jakości dostępnego za darmo, co oznacza obniżenie kosztów wytworzenia oraz większe prawdopodobieństwo znalezienia deweloperów z odpowiednią wiedzą i doświadczeniem.
• Tworzenie i utrzymywanie oprogramowania to zadania wymagające dużych nakładów ludzkiej pracy, więc taniej może być coś kupić, niż tworzyć.

Jednak dobranie odpowiedniej mieszanki narzędzi dla twojej aplikacji może okazać się trudnym zadaniem, wymagającym chwili namysłu. Kiedy dokonujesz wyboru, powinieneś pamiętać o kilku rzeczach:

• Różne narzędzia mogą przyjmować różne założenia o ich otoczeniu — np. otaczającej infrastrukturze, modelu danych, modelu kontroli dostępu, protokołach komunikacyjnych itd. — co może doprowadzić do niedopasowania architektonicznego pomiędzy aplikacją a narzędziami. Takie niedopasowanie prowadzi do tworzenia hacków i obejść, które sprawiają, że kod jest bardziej skomplikowany, niż powinien.
• Różne narzędzia mają różne cykle życia i ich aktualizacja może okazać się bardzo trudnym i czasochłonnym zadaniem, ponieważ nowa funkcjonalność, zmiana założeń projektowych, a nawet poprawki błędów mogą spowodować niekompatybilność z innymi. Im większa liczba narzędzi, tym problem staje się większy.
• Niektóre narzędzia wymagają konfiguracji, często dokonywanej za pomocą jednego lub kilku plików XML, który może urosnąć do rozmiarów wymykających się spod kontroli. Aplikacja może zacząć wyglądać na napisaną w XML z dodatkiem kilku linii kodu napisanych w jakimś języku programowania. Złożona konfiguracja może sprawić, że aplikacja stanie się trudna w utrzymaniu i rozszerzaniu.
• Uzależnienie od dostawcy pojawia się, kiedy kod mocno zależy od produktów jednego dostawcy, przez co zostaje przez nie ograniczony w zakresie łatwości konserwacji, wydajności, zdolności do ewoluowania, ceny itd.
• Jeśli planujesz używać darmowego oprogramowania, może okazać się, że nie jest wcale takie darmowe. Być może będziesz musiał wykupić komercyjne wsparcie, co może nie być tanie.
• Warunki licencyjne mają znaczenie nawet dla wolnego oprogramowania. Na przykład, w niektórych firmach nieakceptowalne jest używanie oprogramowania rozprowadzanego na licencji GNU z powodu jego wirusowego charakteru — oprogramowanie stworzone za jego pomocą musi być wydawane razem ze swoim kodem źródłowym. [Aby nie siać FUD należy wyjaśnić, że wolno włączać kod na licencji GNU GPL do programów o kompatybilnych licencjach. Słowo "wirusowa" ma negatywne konotacje, lepszym określeniem jest "wzajemna". Ponadto GNU GPL dotyczy kodu źródłowego programu lub samego programu, więc cokolwiek napisane w Emacs albo gedit (czyli oprogramowaniu na licencji GNU GPL) nie musi mieć wolnej licencji. Ostatecznie zamknięty program może współpracować z programem GPL pod warunkiem, że występuje wyraźny rozdział tych dwóch aplikacji. Po szczegóły odsyłam na odpowiednią podstronę gnu.org. - przyp. tłum.]

Moja osobista strategia omijania tych problemów polega na rozpoczęciu korzystania najpierw tylko z narzędzi, które są absolutnie niezbędne. Zazwyczaj początkowe wysiłki kierowane są na pozbycie się konieczności zajmowania się niskopoziomową infrastrukturą (i problemami) np. poprzez użycie jakiegoś oprogramowania pośredniego poziomu, zamiast używania gołych gniazd w rozproszonych aplikacjach. Potem dodaję więcej, jeśli tego potrzebuję. Mam też tendencję do izolowania zewnętrznych narzędzi od moich obiektów z domeny biznesowej za pomocą interfejsów i warstw abstrakcji, żebym mógł w miarę bezboleśnie wymienić narzędzie, jeśli będę do tego zmuszony. Pozytywnym skutkiem ubocznym tego podejścia jest to, że końcowa aplikacja jest mniejsza i używa mniej zewnętrznych narzędzi, niż początkowo przewidywałem.

Komentarze (0)

Dodaj komentarz