Tym razem nasz wpis będzie stosunkowo krótki. Ostatnimi czasy spotkaliśmy się z opinią, iż podczas wytwarzania oprogramowania najlepiej jest stosować tylko najpopularniejsze frameworki. Kryterium popularności miały stanowić: ilość zastosowań w projektach, ilość pobrań wprost ze statystyk VCS oraz częstotliwość aktualizacji. Jak nie trudno się domyślić, tak radykalna opinia ma swoje podstawy, zazwyczaj w doświadczeniu indywidualnych osób. Czy jednak jest zasadna? Na ten temat postaramy się odpowiedzieć w niniejszym wpisie.
Na samym początku warto zastanowić się skąd w ogóle taka opinia. Znaleźliśmy dwa podstawowe źródła omawianego spojrzenia na stosowane frameworki, biblioteki oraz narzędzia. Pierwsze z nich to zwyczajne doświadczenie zawodowe oraz obycie z daną technologią. Jeżeli dany profesjonalista przez lata korzysta z konkretnego rozwiązania to logicznym jest, iż tę samą pracę wykona szybciej oraz często dokładniej niż przy użyciu nowej biblioteki, z którą musi się zapoznać. Czas projektowy pełni tutaj istotną rolę. Programista, dev ops, tester lub inny członek całego zespołu często nie może wykonać powierzonego zadania perfekcyjnie, ponieważ kłóci się to z założeniami biznesowymi. W efekcie zamiast wybrać framework, który stworzono aby zaadresować konkretną niszę – wybór zazwyczaj pada na rozwiązanie, w którym zespół czuje się komfortowo, pomijając ukryte koszty, o których później.
Drugą sytuacją, w której dochodzi do odrzucenia dedykowanego rozwiązania jest niechęć, spowodowana często osobistym urazem względem danej technologii. Nie jest to nadzwyczajne zjawisko, często bowiem obiecujące biblioteki dedykowane do rozwiązania konkretnego problemu nie posiadają dokumentacji lub, co gorsza, istniejąca dokumentacja jest nieprawidłowa – przechodząc przez jej kolejne kroki pracownik nie jest w stanie doprowadzić oprogramowania do stabilnego, działającego stanu. Rzadziej zdarza się, że niechęć ta wynika z braku kompetencji, ale ten temat nie dotyczy dzisiejszego wpisu.
Wracając jednak do sedna, stwierdzenie, że najlepiej korzystać z najpopularniejszych bibliotek jest częściowo słuszne. Te bowiem dostarczają częstych aktualizacji oraz oferują lepsze wsparcie. Natomiast w kontekście skali znacznie bardziej istotna wydaje się kwestia architektury oprogramowania. Nie bez powodu istnieją relacyjne, grafowe oraz inne bazy danych, a także frameworki, które je obsługują. Oczywiście da się zamodelować system detekcji oszustw za pomocą relacyjnych baz danych, jednak w tym wypadku grafowe bazy danych oferują znacznie większą efektywność. Dodatkowo, od pewnego etapu (skali), zastosowanie relacyjnych systemów bazodanowych nie jest już możliwe.
Tak więc znacznie ważniejsza jest wybrana architektura rozwiązań i dopasowany do niej framework niż jego popularność. Możemy stwierdzić, że omawiany radykalny pogląd jest zatem bardzo populistyczny i niebezpieczny. Z drugą cechą wiążą się właśnie ukryte koszty, o których wcześniej we wpisie wspominaliśmy. Pozornie tanie i szybkie rozwiązanie, pasujące dla całego zespołu może dojść do etapu, w którym jego dalsza rozbudowa jest nieopłacalna lub wręcz fizycznie niemożliwa bez przebudowy architektury. Popularna, relacyjna baza danych, jeden z najwyżej notowanych języków programowania w.g. TIOBE, zero stresu, wyzwań i problemów – niestety taka utopia zazwyczaj kończy się ścianą, przy której klient zostawiany jest z aplikacją na miarę swoich potrzeb – bez możliwości rozbudowy, a cały projekt (poza utrzymaniem) przestaje mieć rację bytu.
Zwracamy na to szczególną uwagę i apelujemy, aby w pierwszej kolejności sugerować się potencjalną opcją rozbudowy rozwiązania, jego architekturą, a dopiero później popularnością stosowanych frameworków. Rozumiemy, że zdarza się, iż dany projekt musi zostać zrealizowany, a na wspomniane przez nas rozwiązanie nie ma budżetu. Jednak trzeba mieć świadomość, że w tej sytuacji przyszła współpraca może okazać się niemożliwa, a wraz ze wzrostem skali, klient może zacząć zgłaszać uwagi.
