Typowy kod w pracy jest osadzony w jakimś stosie technologicznym, w architekturze projektu, i rozwiązuje projektowe problemy. Jak to niby zbibliotekować, a potem przenieść do innego projektu?
Dużo zależy od tego jak rozwinięty jest ekosystem dla języka w którym piszesz. Gdy poprzedni zespół zaczynał tworzenie systemu to ekosystem Scali był dużo mniej rozbudowany niż teraz. Wobec tego popisali sami biblioteki, które dzisiaj już czasem mają popularne odpowiedniki. Przykłady:
- klient HTTP,
- biblioteka do obsługi CSV,
- mikroframework do RESTowych enpointów z próbkami (healthchecki) oraz proste narzędzie monitorujące odpalające te próbki w kółko na bieżąco i pokazujące stan systemu,
- infrastruktura dla testów integracyjnych dla mikroserwisów: mikroframework do RESTowych endpointów w serwisach by wywołać konkretne akcje czy sprawdzenia + narzędzie pozwalające odpalać testy napisane we własnym DSLu, które korzystają z tych endpointów,
- testy przeglądarkowe, czyli:
- nakładka na selenium (fluent interface)
- mechanizm, który pozwala odpalać pulę JVMek i przeglądarek, by odpalić N instancji aplikacji i mieć szybsze wykonanie testów,
Jako że ekosystem Scali mocno się zmienił w ciągu ostatnich kilku lat to obecnie staramy się raczej szukać sprawdzonych otwartych bibliotek, niż rozwijać biblioteki od kolegów z poprzedniego zespołu, bo przede wszystkim te biblioteki nie mają żadnej dokumentacji albo jakieś szczątkowe. Na pierwszy ogień poszedł klient HTTP, później biblioteki do CSV w razie potrzeby. Dodajemy też nowe sposoby monitorowania (Kamon/ Grafana). Następna w kolejności będzie infrastruktura testowa dla testów przeglądarkowych jeśli zmienimy architekturę systemu i zastąpimy komponentowy framework server-side za pomocą RESTa na backendzie i SPA na frontendzie.
@ShookTea a jeśli w tej bibliotece jest jakaś luka bezpieczeństwa albo poważny bug to co? ;) Jasne że "można", ale często architekt na to nie pozwoli. Widziałem już takie biblioteki co to fajnie działały dla HelloWorld, ale w dużym projekcie powodowały wywalenie się aplikacji z out of memory :D I co potem powiesz klientowi któremu system nagle przestaje działać? ;) Zewnętrzne zależności zawsze niosą pewne ryzyko, ale jednak można mieć nadzieje że bibliotekę standardową języka ktoś przetestował, tak samo jakiś popularny framework. Ale już noname lib z randomowego githuba?
Poważne luki bezpieczeństwa są wszędzie. Banki mają specjalizowane zespoły, które wykrywają luki bezpieczeństwa w aplikacjach jako całości i komunikują się z zespołami tworzącymi te aplikacje.
Naszych klientów nie interesują specjalnie biblioteki jakich używamy. Ich interesuje to czy system działa. Jeśli coś się spieprzy to nie mówimy, że biblioteka X ma błąd i rozkładamy ręce tylko szacujemy ile coś nam zajmie czasu by to poprawić i co można zrobić na szybko by kupić sobie czas (bo np za chwilę przyjdą ważne transakcje i wtedy np trzeba zrestartować jeden mikroserwis). Równocześnie w zasadzie nie zdarza się by te biblioteki, które przytoczyłem sprawiały jakieś problemy na produkcji, bo tylko trzy na produkcji lądują i są to proste i rzadko zmieniane rzeczy: klient HTTP, biblioteka do CSV i REST z próbkami.