DevTalk #140 – O Salesforce CRM ze Stanisławem Zaniem

Cześć. Witamy w kolejnym odcinku podcastu DevTalk, w którym to dzisiaj bardzo nietypowy temat, ponieważ Stanisław Zań wprowadzi nas w aspekty programowania Salesforce. Przed Tobą DevTalk. Programistyczny głos w Twoim domu. Cześć Staszek. Cześć Maciej. Dziś będziesz nas zabawiał swoimi opowieściami na temat CRM-a, co jest dość nietypowym tematem jak na podcast programistyczny. Zanim jednak zaczniemy, to powiedz proszę parę słów o sobie. Cześć, jestem Staszek. Jestem programistą Salesforce już od pięciu lat i w zasadzie zacząłem tak moją karierę w IT. Nie pracowałem w innych technologiach, zacząłem od Salesforce-a i jakoś tak dostałem w tej branży na niebieskiej platformie.

Bardzo jestem ciekaw jak ta nasza rozmowa dzisiejsza się potoczy, bo szczerze mówiąc ja nigdy nie korzystałem z Salesforce'a, ledwo wiem co to jest i celowo się nie doszkalałem z tego tematu przed naszą rozmową, ponieważ prawdopodobnie większość naszych słuchaczek i słuchaczy jest na takim samym poziomie wiedzy na temat Salesforce'a jak ja teraz, więc poznanie co ty robisz na co dzień i co rozumiesz przez programowanie Salesforce'a może być wydaje mi się takim fajnym poszerzeniem horyzontów. Więc może zacznijmy od tego, co to w ogóle jest Salesforce? No to tu można rozdzielić na kilka warstw, ale tak od tej najbardziej ogólnej, no to Salesforce jest systemem CRM-owym, Customer Relationship Management, który pozwala nam zarządzać jakby relacjami z klientami, a już tak bardziej precyzyjnie to, co Salesforce oferuje, jeśli chodzi o pewne jego produkty, to jest głównie sprzedaż i serwis.

Czyli procesy sprzedażowe, tworzenie kontaktów, szans sprzedażowych itd. Ewentualnie serwis, czyli obsługa klientów. Na zasadzie robimy case'a do tego systemu, on się automatycznie zapisuje. Dookoła tego wszystkiego jest zrobiona infrastruktura programistyczna, łącznie z bazą danych, bezpieczeństwem i tak dalej i automatyzacja wielu funkcjonalności, które są jakby paczkowe oraz mamy też, czyli do tego momentu mamy takiego dużego sasa z produktami, a ponadto możemy również go rozszerzać i są takie pasowe elementy w tym produkcie i dodawać własne rozwiązania programistyczne, które możemy na przykład sobie w kodziku napisać. Ok. I Ty pracujesz jako programista, rozwijasz samego Salesforcea, czy pracujesz u jakiegoś klienta, który używa tego narzędzia i dopisujesz rozszerzenia specyficzne dla jednej konkretnej firmy?

To drugie. Pracuję zwykle u klientów tych już końcowych, którzy licencję do Salesforcea sobie kupują od samego Salesforcea, a mnie wynajmują, żebym tą platformę rozwijał i robił im szeroko pojęty konsulting i rozwój tej aplikacji. Znaczy tej aplikacji, tej konkretnej implementacji aplikacji, którą oni sobie wykupują i rozwijają. No bo zakładam, że to jest straszna kobyła i że generalnie można to porównać z jakimiś SharePointami i tak dalej, których to konkretne instancje u klientów mogą się między sobą diametralnie różnić. W zasadzie tak. Jak to działa pod spodem? To jest to multitenantowe środowisko i po prostu Salesforce nam udostępnia pewne zasoby na swoich serwerach, do których my się łączymy chmurowo i to sobie w tej chmurze jakoś tam działa.

Mogę też rozwijać frontend poprzez języki JavaScript, powiedzmy, a chociaż technologii frontendowych na ten moment są trzy z jakiegoś powodu, bo Salesforce ogólnie lubi bardzo dużo zmian robić. I co chwilę coś tam dodaje albo coś usuwa. No i jest jeszcze szereg narzędzi nazywanych deklaratywnymi, które są takim drag and dropem, które pozwalają nam również programować i pewne procesy też automatyzować. Natomiast przechodząc do języka np. do tego backendowego, to jest to język Java podobny, obiektowy, nazywa się Apex. Ale jest on trochę inny i ma pewne ograniczenia. Ogólnie wszystkie te backendowe rzeczy, które w Salesforce chcemy zaprogramować, no to musimy respektować tzw.

Nie budowałem nigdy czegoś aż tak dużego, co musiałoby się faktycznie z 15 sekund przeliczać. Na ogół jest to taki limit, który Wychodzi dopiero, kiedy aplikacja jest bardzo duża, długo nie była refaktorowana i pod spodem się już dzieje tyle rzeczy w kółko, że raczej jest to oznaka, że trzeba ten system przepisać, aniżeli że jest tam coś faktycznie do naprawy, bo coś tam po prostu zostało źle utrzymane po kilku latach. Czy jest to częste podejście w tym środowisku, żeby przepisywać te aplikacje? To zależy w zasadzie, bo konie specyfiką Salesforcea jest to, że mamy obowiązkowe updaty trzy razy w roku, więc nie jest tak, że można się kisić na Javie 8 od 15 lat, tylko faktycznie trzy razy w roku mamy obowiązkowe przejście na nowszą wersję.

I Salesforce stara się rozwijać trochę te swoje narzędzia, więc raz na rok, raz na dwa lata dojdzie faktycznie coś, co pozwoli nam uprościć te poprzednie rzeczy i trochę to zoptymalizować. Więc takie podejście, że raz na Kolejny odcinek. Jak wygląda jakiś w Twojej pracy codziennej stosunek tego pisania w tym języku javopodobnym versus frontend versus przyciąganie klocków drag and drop?

To zależy od klienta na pewno i frontendu szczerze powiem dotykałem najmniej. O tamtą chwilę wygląda tak, że masz jakieś komponenty, które są przygotowane nie przez jakieś zewnętrzne biblioteki, tylko jakieś komponenty przygotowane przez Salesforce biblioteki, tak? Żeby to jakoś pasowało wszystko do siebie. Tak, dokładnie. To też zależy, który frontend, tak? No bo są trzy technologie frontendowe, powiedzmy. Ale no, raczej Salesforce nam udostępnia komponenty zbudowane przez niego. Ten najnowszy frontendowy język jest w bibliotekach, który się nazywa Lightning Web Components, LWC. I to faktycznie jest taki stack komponentów od Salesforce'a, które wyglądają jak Salesforce i można je rozwijać. Natomiast tego frontendu z mojego doświadczenia robi się najmniej, no bo już frontend jakby jest zawarty w pakiecie z Salesforce'em.

Mamy tam, możemy sobie po prostu tak upraszczając chodzić po bazie danych i wyświetlać rzeczy w dynamiczny lub niedynamiczny sposób i faktycznie sobie te frontendowe rzeczy dostosowywać tym, co Salesforce nam gwarantuje i dopiero chcemy sobie to bardzo rozwinąć, dodać jakieś niesamowite kolorki, animacje, to dopiero przechodzimy do pisania tego frontendowego kodziku. Jeśli chodzi o stosunek pracy, no to raczej obecnie jest tak, że staramy się jak najwięcej wyklikiwać w narzędziach deklaratywnych i przeciągać te bloczki, które tak samo nam pozwalają odczytywać rekordy z bazy, zapisywać, iterować po nich, robić jakieś zmiany. Po prostu są takie ify i pętle. Zaniem, Stanisław.

50% tych declaratywnych, 30% backendowych i 20% frontendowych. Tak bym powiedział, że w moich ostatnich latach tak to wyglądało. Czy te designery, te budowanie tych workflows różnych, czy one są kierowane do osób także biznesowych, czy raczej właśnie do programistów, którzy tylko używają ich, żeby biznesowi dostarczyć te konkretne funkcje? To Salesforce to trochę rozgranicza u siebie w nomenklaturze wewnętrznej, ponieważ mamy taki podział kompetencji na konsultantów i na deweloperów powiedzmy. I to też w zależności od firmy wygląda trochę inaczej, natomiast modelowo według Salesforce konsultantem Jest osoba, która idzie sobie do takich osób z biznesu, robi z nimi analizę i jednocześnie jest w stanie właśnie tymi narzędziami drag and drop coś tam wyklikać i pokazać jakieś proste lub bardziej nawet skomplikowane procesy, żeby razem z nimi dewelopować, powiedzmy.

A programista to jest ktoś, kto zrobi to trochę lepiej potencjalnie, ale też umie pisać kod. Więc w zasadzie Salesforce jest fajną karierą dla kogoś, kto chce rozwijać biznes tak programistycznie, natomiast też lubi rozmawiać, bo faktycznie ta ścieżka konsultancka i wyklikanie tych rzeczy na bieżąco jest bardzo tutaj, mimo wszystko potężne. Można zrobić prawie wszystko to, co w kodzie. Trochę gorzej, trochę wolniej i z ograniczeniami, ale jednak można. I pewnie można część z tego zrobić już w trakcie jakichś tam tych rozmów, tak? Nawet, że rozmawiasz sobie z biznesem, jednocześnie klikasz, słuchając, co oni mówią, na bieżąco wprowadzasz te zmiany i też oni mogą, prawdopodobnie patrząc w kod, niewiele by zrozumieli, a jak patrzą te klocki na ekranie, którymi poruszasz i zmieniasz ich konfigurację, to coś tam mogą też zrozumieć, tak?

Jednym z projektów ostatnich na przykład to było, musieliśmy zaimplementować na produkcie Salesforce'a kalendarz do spotkań powiedzmy i trzeba było dokonfigurować dostępność ludzi, zasobów i to było dużo administracji jakby powiedzmy Po stronie bazy danych, żeby wszystkie te konfiguracje zasobów ludzi i miejsc dostosować do tego produktu. Dużo klikania w tych bloczkach, żeby formularz, który pozwala do wyklikania takiego spotkania też był dla klienta. Zaniem Zaniewicz.

Jak ktoś bardzo chce, to może popsuć. A jeżeli popsuje, no to wtedy są takie problemy, że Salesforce sam w sobie nie bardzo proponuje narzędzia do powrotu do poprzednich wersji, że tak powiem. Jeżeli coś popsujemy w naszej bazie danych Salesforce'a, która jest bazą na ich serwerach, I nie zrobimy sami rollbacka na zasadzie backupu, na zasadzie nie wciągniemy sobie starych danych do Excela, no to prawdopodobnie nie bardzo mamy jak te dane poprawić, no bo Salesforce takich narzędzi sam z siebie nie daje, chyba że zapłacimy naprawdę bardzo, bardzo dużo pieniędzy. I się dogadamy z supportem. A jeśli chodzi o sam kodzik, no to tak samo nie ma możliwości zrobakowania rozwiązań. Tak jak to sobie wyobrażam, jak to wygląda w innych technologiach powiedzmy javowych, no to zakładam, że jak wdrożymy złą wersję kodu z jakimś błędem na serwer, no to w razie co można sobie go przebudować, skompilować i wrzucić nową, znaczy tą poprzednią, która działa, no to tutaj tak nie możemy zrobić.

W zasadzie, jeżeli chcemy zrobić rollback, to musimy ręcznie wycofać wszystkie zmiany, które sobie wróciliśmy, te błędne. Więc jak dodaliśmy jakąś klasę, która ma dużo dependencji i wszystko zablokuje i nie możemy jej usunąć w dwie minuty, no to w zasadzie mamy trochę zabrickowany system na południach, powiedzmy, tak, dopóki tego wszystkiego sobie nie powrócimy. I są duże biznesy innych firm zewnętrznych, które się specjalizują tylko w procesie DevOpsowym dookoła Salesforcea właśnie, żeby te rollbacki umożliwić w sensowny sposób. Więc można popsuć, natomiast To nie jest tak, że jest to bardzo łatwo. Chociaż te procesy cyterskie też są różne, bo z drugiej strony Salesforce teoretycznie wymaga przed wdrożeniem, żeby kod był pokryty testami na 75% minimum i jeżeli jest tego pokrycia procentowego mniej, no to nie możemy go przepchnąć na środowisko wyżej.

Wspomniałeś o tym, że kod musi być pokryty testami w minimum 75%, a następnie od razu przeskoczyłeś do tego, że 10 testerów klepie manualnie na jednym serwerze i testuje tę aplikację. To o jakich testach mówimy? No właśnie i tutaj zależy jak też te testy zdefiniujemy. Teoretycznie mówimy o... Wymóg pokrycia 75% jest dla testów unitowych, jednostkowych. Chociaż wiem, że jakby ktoś spojrzał takim purystycznym okiem na te testy, to by powiedział, że to nie są wcale testy jednostkowe, tylko to są testy prawie że integracyjne, ponieważ sam Salesforce w dokumentacji wymaga, żeby... W czasie pisania testów stworzyć sobie rekord w bazie danych testowej, po prostu przez te nasze DML-owe i SQL-owe zapytania, pobrać ten rekord i coś sobie sprawdzić.

Tak więc i do tego momentu... Sugeruję z dokumentacji, żeby tak zrobić, bo trochę nie bardzo mamy frameworki do mockowania i stubowania tych testów. Istnieją, ale są ograniczone dość mocno, więc jakby te operacje bazodonowe w samych testach są powszechne, więc powiedzmy, że piszemy unitowo-integracyjne testy, natomiast później manualnie jednak testerzy to na środowiskach wyżej na ogół starają się testować. Czy to są jakieś biblioteczki do testów, takie wzięte ze środowiska Javy, czy to są też dostarczane przez Salesforce'a, jakieś autorskie? Z asercjami, jakimiś tam porównaniami i tak dalej? Są autorskie od Salesforce'a, natomiast przez to, że ta platforma jest bardzo ograniczona, to znaczy bardzo ograniczona.

Nie ma dostępu do bebechu, więc jakiegoś fajnego mockito też się nie da zrobić. I te wszystkie open source'owe podejścia, które do tego są, to jest to ładny framework do tego, żeby to, co Salesforce nam dostarczył, używać bardziej, powiedzmy, rozsądnie. I żeby to było słudniejsze w użyciu. Natomiast mimo wszystko jest to dostarczane przez Salesforce. No i są różne ograniczenia, na przykład tego, że nie da się mockować statycznych metod z jakiegoś powodu. Jak ktoś kiedyś pisał cały kodzik na statycznych metodach, no to później się nie da w ogóle nic zamokować, no bo ten framework nie obsługuje i nie możemy żadnej metody tam wrzucić. A powiedz, jak to jest, znaczy, a jakie są praktyki? Jakby jest dążenie, bo rozumiem, że jest społeczność wokół Salesforce'a również zbudowana czy w Polsce, czy w różnych krajach, tak?

Jakieś meetupy, czy konferencje, czy... Tak, to regularnie mamy, w każdym większym mieście w Polsce obecnie są meetupy z Salesforce'a, można przyjść zjeść pizzę, Salesforce na ogół płaci za to i sobie porozmawiać o praktykach. I właśnie te praktyki, jeśli chodzi o testy konkretnie, jest takie dążenie do tego pokrycia testami jak największego, czy raczej, żeby odmienić te 75% wymagane? I właśnie co się stanie, jak nie masz tych 75%? Jeżeli pokrycie kodu spadnie na 74%, to nie jesteśmy w stanie wdrożyć kodu wyżej. Po prostu produkcja nam nie pozwoli, żeby ta paczka z nowym kodem przeszła. Można to obejść, no bo w zasadzie ten kod, on sprawdza tylko pokrycie linii kodu, natomiast nie sprawdza poprawności asercji. Więc są metody, żeby wygenerować sztuczne ilości pokrycia, jeżeli bardzo tego chcemy.

Natomiast nie polecam tej praktyki. Jednak też 75% jest wymagane, więc Staramy się na ogół trzymać to 80-85%, żeby było trochę zapasu, bo też nie wszystko można pokryć. Przez to jak Salesforce Ascend działa, to na przykład pewnych wyjątków nie da się złapać w testach, no i trzeba mieć ten margines, że nie wszystko się uda. Natomiast tu też jest taki warunek, że tylko APEX-owe, te backendowe rzeczy wymagają testów. Frontend można tam pisać, ale nie jest to sprawdzane i z mojego doświadczenia praktycznie nikt tego nie robi. Nie ma testów na AWS CRM frontendowe rzeczy. Jeśli chodzi o deklaratywne, to Salesforce już nie wymaga żadnych testów tam, więc zdecydowanie możemy sobie wyklikać.

Można jakoś tam zintegrować gita, czy jakieś inne repozytorium, może Salesforceowe jest dedykowane, gdzie ten kod faktycznie jest wersjonowany, można sobie go tam przewijać w historii, czy nie bardzo? Korzystamy z gita po prostu zewnętrznego, Salesforce sam w sobie nic nie daje takiego. Jest jakieś podejście, które się nazywa DevOps Center, taka specjalna aplikacja, natomiast jest bardziej do DevOpsowych rzeczy do wdrażania, natomiast samo repozytorium i ich rewersji nie. No, ale dobre praktyki u nas są takie, żeby jednak mieć to repozytorium gdzieś w jakimś gicie czy w innym aruże i trzymać. Aczkolwiek jest też taka rzecz, że Salesforce udostępnia na swojej platformie konsolę deweloperską powiedzmy, która wygląda jak taki bardzo stary Notepad++ i przez to, że dużo jest kontraktorów z krajów Azji Wschodniej, którzy nie bardzo czasem stają dostępy, no to praktyką na pewnych dużych projektach jest to, że się z historii wersji po prostu nie używa.

Rzadko się zdarzały duże zadania, które zajmowały więcej niż taki dwutygodniowy sprint. To naprawdę, żeby jedna osoba klapała to dłużej, no to... Ja już bym powiedział, że jest problem projektowy, no bo Salesforce trochę nie służy do projektowania takich ogromnych kobył, tak? Przynajmniej nie w takiej skali. Znaczy no, można to zrobić, no bo jednak jest dość elastyczną platformą, ale no nie robimy tutaj mikroserwisów, które się asynkronicznie komunikują w pół sekundy, tak? Więc ta komunikacja na ogół... Po prostu często w środku wychodzi, że jednak brakuje czegoś w tej analizie biznesowej i trzeba coś poprawiać. No jednak tak. Jednak się to zdarza dość często. Chociaż te zmiany nie są finalnie takie duże, bo jednak pracujemy na takich mniejszych wersjach kodu.

Mówiłem 25 minut temu, że ciekawe, jak część naszych słuchaczy zareaguje, czy doceni swoją aktualną pracę, czy raczej zatęskni za czymś, o czym będziesz opowiadał. W sumie jestem ciekaw. Dajcie znać nam w komentarzach na różnych platformach, jakie jest wasze postrzeganie tego. A w sumie aż się trochę boję pytać, ale czy tam AI coś zmienia? No to to też zależy. Na pewno Salesforce obecnie bardzo promuje swoje rozwiązanie AI, które się nazywa AgentForce. No i jeśli chodzi np. o to pisanie kodu Apexowego w tym przypadku, jak sobie porównywałem z chatem GPT, z Gminy itd., to Salesforceowe rozwiązanie jest zdecydowanie najgorsze i wypluwa najgorszy kodzik, który ma wszystkie złe praktyki, których ja się uczyłem. Wszystkie te limity zapytań w pętli są przekroczone.

Przynajmniej do dzisiaj tak jest. Wiem, że teraz Jakieś nowe rzeczy wychodzą. AgentForce Vibes, bodajże się to nazywa, ponieważ Salesforce bardzo idzie w marketingowe nazwy, które też często zmienia. To nagrywamy to pod koniec 2025 roku, więc może w 2079, kiedy go słuchacie, już jest okej. Być może tak i na pewno Salesforce teraz udostępnia, bo bardzo promuje, żeby implementować różne agenty na swoich rozwiązaniach, którzy przejmą właśnie obowiązki. Tego, co można w kodziku napisać. Natomiast z tego, co ja się dowiaduję do tej pory, jest to na tyle drogie i na tyle słabo udokumentowane i ciężkie we wdrożeniu, że jest to używane tylko w małych projektach.

Nawet jak duża firma prosi o jakąś implementację AI-ów, to na ogół są to bardzo małe rzeczy. Są duże problemy kosztowe i z testowaniem tego wszystkiego i Support z Salesforce też niekoniecznie jest tu pomocny, bo sami jeszcze nie wiedzą, jak to do końca działa. Rewolucja idzie, ale jeszcze dochodzi. Przypomniało mi się, w ogóle gdzie ostatnio Salesforce mi się obił o uszy i ja słucham takiego podcastu AI Daily Brief, zresztą bardzo fajnego, który tam mówi o nowinkach w świecie AI-owym i słucham tego dwa razy w tygodniu powiedzmy od I właśnie jakoś przed wakacjami było dużo o tym, że właśnie jak powiedziałaś tę nazwę AgentForce, to mi tak kliknęło, że przed wakacjami chyba jakoś bardzo było głośno o tym, że Salesforce mocno idzie w tego AI-a i że faktycznie bardzo duży nacisk jest kładziony na to, żeby zawojować ten CRM-owy świat i być może nie tylko za pomocą tych technologii.

Na wakacjach chyba właśnie zmieniali model finansowania tego i wyszedł troszkę tańszy i powiedzmy pewnie dlatego też stąd zmiana i też jest duże wydarzenie z Salesforce Dreamforce na jesieni, więc pewnie to było marketingowo przygotowane też pod to. A Tobie jako Tobie, rozumiem, że w takim razie nie możesz sobie odpalić kursora czy jakiegoś innego IDE wspieranego LLM-ami, żeby pokodzić te feature, które dostarczasz? Teoretycznie mogę, natomiast ja jeszcze nie miałem takiej praktyki w firmie, w której pracowałem, bo stwierdzili, że jednak nie jest to na temat potrzebne. Wiem, że da się tak, natomiast nie wiem, jak bardzo jest to pomocne. Aczkolwiek przez to, że ten kod jest tak bardzo podobny do Javy, z mojego doświadczenia w bawieniu się takimi rzeczami, to on wypluwa często biblioteki, które są w Javie, a nie ma w Apexie.