Witamy w części #5 naszego niesamowitego blogpisać i webinar seria! W naszej serii pomagamy analizować wszystkie aplikacje Domino.

Tytuł webinar dla tego blogpost brzmiał: „Nie skończ w rowie, ponieważ nie byłeś świadomy blokad w kodzie źródłowym”.

Tym razem dzielimy się Dlaczego, co i jak należy analizować w swoich aplikacjach Domino.

Proszę zaakceptuj marketingowe pliki cookie aby wyświetlić ten film.

Słowo wstępne dla nie-programistów

Jeśli nie jesteś programistą: Poniższe wprowadzenie może pomóc w lepszym zrozumieniu dalszej części tego wpisu.

Każda baza danych w Twoim środowisku zawiera elementy projektu i kod. Ma to na celu wyświetlenie wszystkich zawartych w nim dokumentów. Czy to do ich tworzenia, edytowania czy czytania.

Widoki wyświetlają dokumenty w formacie listy. Można je sortować i/lub kategoryzować. Na przykład według daty, nazwy użytkownika lub czegokolwiek, co pasuje do odpowiedniej aplikacji i widoku.

Oprócz widoków warto zwrócić uwagę na jeszcze dwa elementy projektu. Pomagają one tworzyć, edytować lub czytać dokumenty w bazach danych:

  • Akcje w widokach (zwykle dostępne za pomocą przycisków lub opcji menu u góry widoków)
  • i Formularze, a także pola na formularzach

Baza danych może składać się z wielu innych typów elementów projektu. Każdy z nich może używać jednego lub wielu z następujących języków programowania:
@Formuły, LotusScript, JavaScript i Java.

Ten kod ponownie może mieć różne interfejsy i zależności:

  • inne bazy danych Notes/Domino,
  • inne aplikacje, takie jak Microsoft Excel czy SAP,
  • system plików – czy to na klientach, czy na serwerach –,
  • system operacyjny,
  • i wiele, wiele innych zależności.

Aplikacja może zawierać jedną lub wiele baz danych i być dostępna na jednym lub wielu serwerach. Replikacja zapewnia synchronizację tych samych baz danych na różnych serwerach. Powoduje to doskonałą wydajność, równoważenie obciążenia i wysoką dostępność w różnych lokalizacjach geograficznych/sieciach.

Rozważając optymalizację, modernizację lub migrację aplikacji, musisz wiedzieć:

  • jak złożona jest aplikacja (pomyśl o typach i liczbie elementów projektu, a także linii kodu),
  • co robi cały kod,
  • i czy kod będzie łatwy w użyciu w twoim projekcie.

Zacznijmy więc od Dlaczego

Większość programistów nie opracowała samodzielnie wszystkich aplikacji. Nawet jeśli tak (chapeau!), to najprawdopodobniej nie stało się to „całe wczoraj”, ale w ciągu kilku lat. Czy nadal wystarczająco dobrze pamiętasz kod we wszystkich swoich aplikacjach?

Ponadto niektóre firmy nie mają już nawet programisty Domino. Nie mówiąc już o wszystkich, którzy przez lata pomagali budować dzisiejszy krajobraz aplikacji.

Następnie znajomość kodu źródłowego aplikacji jest świetna do uruchamiania/utrzymywania jej w Domino w takiej postaci, w jakiej jest.

Na koniec chcesz znaleźć wszystkie przeszkody, a także pomocny kod, jeśli nie ogólnie dobre, złe i brzydkie.

Jeśli chcesz zoptymalizować, zmodernizować lub zmigrować swoje aplikacje:

Podsumowując, czy nie byłoby wspaniale, gdybyś mógł zaoszczędzić sobie cennego czasu, frustracji i pułapek? Znajomość interesariuszy Twoich aplikacji, staje się znacznie potężniejszy w połączeniu z analizą projektu i kodu aplikacji.

Gdy poznasz swoich interesariuszy, będziesz także wiedział:

  • Na kogo będą miały wpływ wszelkie zmiany wprowadzone w aplikacji?
  • W jaki sposób zostaną one naruszone?
  • Z kim powinieneś się skonsultować, zanim zaczniesz wprowadzać zmiany?
  • Kto czerpie korzyści z pracy, którą wykonujesz?

Co prowadzi nas do Co

Zanim zagłębimy się w „Co z Twojego kodu powinieneś przeanalizować”, pamiętaj: 

Istnieje wiele innych ważnych punktów danych, które należy wziąć pod uwagę przed analizą kodu: 

  • Jakie są najczęściej używane i najmniej złożone aplikacje?
    Te szybko się zwracają. I nie powinieneś spędzać czasu z aplikacjami, których nikt nie używa! Aby uzyskać więcej informacji, zobacz także tutaj i tutaj
  • Którzy użytkownicy końcowi potrzebują lokalnych replik ze względu na wydajność lub użycie w trybie offline? 
  • Z jakich aplikacji korzystają twoi VIP-y lub najważniejsze centra zysku? 

To tylko kilka przykładów, o których warto pamiętać – można znaleźć więcej tutaj (patrz slajdy 17-21)

Jaki kod należy teraz przeanalizować i czego w nim szukać? 

Wszystko. Okres. We *wszystkich* twoich aplikacjach. A dla każdego z nich to znaczy 

  • Cały kod: @Formulas, Java, JavaScript i LotusScript 
  • Wszystkie elementy projektu (pomyśl o „kontenerach kodu”). Mogą to być formularze, podformularze, widoki, kolumny, akcje, agenty, przyciski, biblioteki skryptów itp. 
  • Następujące elementy projektu często zasługują na szczególną uwagę:
    XPages, klasy Java, aplety, pliki Jar, usługi sieciowe, funkcje aplikacji złożonych i podobne 

Właściwa analiza obu elementów projektu aplikacji i kod odpowiada na dwa zasadnicze pytania: 

  1. Gdzie mieszka cały twój kod? Ile jest gdzie? A jaki to typ kodu? 
  2. Co robi ten kod?

Poniższe dwa przykłady pokazują wartość analizy zarówno projektu, jak i kodu: 

a) Im więcej formularzy, pól i kodu ma aplikacja, tym bardziej czasochłonna będzie jej modernizacja lub migracja 

b) Aplikacja korzystająca z Java Code nie jest idealnym kandydatem do migracji do SharePoint. Tak, to częściowo zależy od tego, co robi odpowiedni kod. Jednak pomaga w uszeregowaniu aplikacji i prevent pułapki.

CO powinieneś szukać w swoim kodzie 

Wyszukiwanie w kodzie może być zabawne lub frustrujące. 

Po eksportowanie projektu Twoich aplikacji do DXL (Domino XML Language), oto trzy wskazówki na początek: 

  1. Uruchom notatnik lub podobny i sprawdź wynik. Aby uzyskać pierwsze wrażenie, spróbuj znaleźć część swojego kodu, wyszukując jego części. Szukaj także nazw użytkowników, nazw serwerów i podobnych 
  2. Wypróbuj LotusScript Manager lub Source Sniffer z OpenNTF
    (*nie* używaj Lotus Analyzer! Ma ukryty projekt i telefony do domu) 
  3. Pro-Challenge: podziel kod z DXL na dokumenty w bazie danych Notes. Ułatwia to kategoryzację, wyszukiwanie i przetwarzanie końcowe (na przykład w celu zliczenia elementów projektu) 

Jeśli próbowałeś któregokolwiek z powyższych, być może zauważyłeś kilka niedociągnięć po drodze: 

a) Twoje wyszukiwania pasują również do komentarzy/uwag w twoim kodzie 

b) Wyszukiwania łączone, takie jak @Db (kolumna OR wyszukiwanie), wzywają do zajęcia się najpierw pro-challenge
(= dzielenie kodu na dokumenty Notes/Domino lub bazę danych SQL). Oddzielne wyszukiwania prowadzą do zduplikowanych wyników. To z kolei działa bardzo przeciwko twojemu celowi, jakim jest przejrzenie jak najmniejszej liczby kodu. 

c) Twoje wyszukiwania pasują również do kodu, którego nie szukałeś. Na przykład: 

  • Wyszukiwanie „Otwarte” spowoduje znalezienie NotesDatabase[Object].Open i NotesStream[Object].Open 
  • Wyszukiwanie „@DbLookup” obejmuje wyszukiwanie w tej samej bazie danych, w której znajduje się kod. Jednak możesz chcieć wyszukiwać tylko w innych/zewnętrznych bazach danych. Twój wynik obejmuje również wyszukiwania spoza programu Notes, takie jak ODBC. Jednak możesz szukać tylko wyszukiwań w Notatkach. 

Szlochzanim będziemy kontynuować nasze poszukiwania, musimy zoptymalizować Kod

Aby uzyskać dobre wyniki wyszukiwania, musimy usunąć wszelkie komentarze z całego kodu. Tak, dobrze jest mieć komentarze w swoim kodzie, aby później lepiej go zrozumieć. Ale zniekształcają nasze wyniki wyszukiwania. 

Poniższe ilustracje ilustrują sposób, w jaki programista może komentować w LotusScript i @Formulas: 

W @Formulas komentarze zaczynają się od REM, po którym następuje dowolna ilość spacji (= spacje lub tabulatory). Następnie pojawia się właściwy komentarz otoczony podwójnymi cudzysłowami lub nawiasami klamrowymi.

Przygotowaliśmy już powyższe do przetestowania ZA DARMO

Cały ten artykuł pomoże Ci zrozumieć i przeprowadzić własną, niezależną analizę aplikacji. Możesz jednak chcieć zaoszczędzić cenny czas i szybko działać. Wszystko co musisz zrobić to zarejestruj się w naszym gotowym do gry iDNA Applications piaskownica. Jak tylko się zarejestrujesz, wszystko, co musisz zrobić, to zalogować się i przejść do naszego gotowe natychmiastowe wyszukiwanie kodu. To prawda, nie pokazuje twoich własnych aplikacji, ale daje dobre wyobrażenie o tym, jak powinno działać wyszukiwanie kodu.

Do testowania użyj wyszukiwania tekstowego za pomocą „florian”, „vogler”, „server”, „/acme”, „/O=acme” i „workflow”. Wypróbuj również wyszukiwanie wyrażeń regularnych, np. „(?iw)@db(lookup|column)”.

Teraz naprawdę zagłębmy się w CZEGO szukać *w* całym (projektowaniu i) kodzie twoich aplikacji:

Jeśli chcesz zoptymalizować

  • Wyszukaj GetNthDocument – ​​jest wolniejszy niż GetFirst/GetNextDocument
  • Wyszukaj zakodowane na stałe nazwy serwerów, nazwy użytkowników, nazwy plików baz danych, adresy IP, adresy e-mail, identyfikatory replik itp.
  • Wyszukaj stary kod (@V2If, @V3Username, @V4UserAccess, @UserPrivileges, @IfError)
  • Niezależnie od kodu: znajdź najczęściej używane/popularne bazy danych i okaż im trochę miłości. Spraw, by były ładniejsze i bardziej nowoczesne!

Jeśli chcesz zmodernizować

  • Sprawdź, czy aplikacja w dużym stopniu opiera się na klasach NotesUI*. To nie działa w przeglądarkach internetowych i wymaga poprawek
    Sprawdź kod, który nie jest obsługiwany w przeglądarkach. Wskazówka: wyszukaj w pomocy Projektanta hasło „Nie możesz używać tej funkcji w aplikacjach internetowych”.
  • Czy jest już dużo kodu sugerującego obsługę przeglądarki?
    tj. @WebDbName, @BrowserInfo, @ClientType, Domino @DbCommands, …
  • Czy Twoja aplikacja/kod opiera się na drukowaniu? To może być trudne z poziomu przeglądarki
  • Przeanalizuj swój kod, aby sprawdzić, czy działa dalej HCL Nomad
    • Czy aplikacja jest zależna od XPages, Java lub ODBC? To nie działa na HCL Nomad.
    • Czy aplikacja korzysta z wywołań C-API? Jeśli tak, czy kod działa również na iOS i Androidzie?
    Czy Twoja aplikacja wymaga rozszerzeń klienta innych firm?
  • Niezależnie od kodu: znajdź najczęściej używane/popularne bazy danych i daj im trochę miłości. Spraw, by były ładniejsze i bardziej nowoczesne!

Jeśli chcesz migrować

  • Ile formularzy, pól, widoków itp. ma aplikacja? Nie wybieraj najpierw najbardziej złożonego.
  • Czy Twoja aplikacja zależy od kodu lub elementów projektu, które nie działają dobrze na odpowiedniej platformie docelowej?
    Na przykład: Java <> SharePoint, zbyt wiele folderów <> SharePoint. C-API. Prywatna lub publiczna książka adresowa, poczta (wysyłanie i) szyfrowanie. UseLSX, ODBC, DB2, DOS/cmd, OLE, pliki, katalogi, MIME, łącza do dokumentów itp.
  • Czy aplikacja zależy od innych baz danych?
    Pomyśl o @DbLookups, które łączą się z innymi bazami danych (nie używając np. „“:““ jako serwer:nazwa pliku, na przykład). To samo dotyczy New NotesDatabase, GetDatabase, .Open, .OpenWithFailover, .OpenIfModified, .OpenByReplicaID, [FileOpenDatabase], [Compose] itd.
  • Niezależnie od kodu i migracji: pokochaj jedną z pozostawionych baz danych, spraw, by była ładniejsza i bardziej nowoczesna.

Na koniec przyjrzyjmy się, JAK najlepiej przeszukać kod

Poniższe rzeczy są naprawdę przerażające. Jeśli nie jesteś programistą, pomiń tę sekcję!

Po części omówiliśmy już, dlaczego wyszukiwanie kodu za pomocą tylko (pod)łańcuchów znaków nie zaprowadzi cię za daleko. W zbyt wielu przypadkach pasuje za dużo lub za mało. Przyjrzeliśmy się również, dlaczego usunięcie wszystkich komentarzy jest konieczne przed przeszukaniem kodu.

Ponadto podczas wyszukiwania kodu bardzo, bardzo, bardzo ważne jest:
NIE szukaj kodu, myśląc o tym, jak byś go opracował. Myśl szerzej, a będziesz zaskoczony, gdy dowiesz się, jak inni ludzie kodują.

Jakie są więc lepsze podejścia do wyszukiwania kodu niż tylko dopasowania podciągów?

Pełnotekstowy indeks obsługujący symbole wieloznaczne, takie jak „*” (gwiazdka), zaprowadzi Cię nieco dalej w grze. Np. przy wyszukiwaniu „@dbcolumn* OR @dblookup*” – ale brakuje w nim obsługi precyzyjnej negacji. Dokładne negowanie części kodu jest niezbędne, aby np. znaleźć tylko @DbLookups, które nie wskazują na tę samą bazę danych.

Poniższy @DbLookup wyszukuje dane z tej samej bazy danych, w której wykonywany jest kod. Czyni to poprzez „“:“” jako drugi parametr:

Kolejny @DbLookup wyszukuje dane z „lokalnej” książki adresowej (klienta lub serwera, w zależności od tego, gdzie działa):

Wyszukiwanie dowolnego @DbLookup, który wyszukuje dane z „names.nsf”, jest całkiem łatwe. Nawet z symbolami wieloznacznymi: @dblookup(:„nazwy.nsf”). Tak jest, dopóki nie natkniesz się na taki kod:

Teraz nagle musimy szukać kodu w wielu wierszach — tak, widzieliśmy już taki kod.

Jeszcze gorzej jest, gdy zmienne, nie mówiąc już o @funkcjach, wchodzą w grę jako parametr:

Powyższy kod wyszukuje dane z tej samej bazy danych. Zmienna ht_filename jest wynikiem @Subset(@DbName;-1). To ponownie skutkuje nazwą pliku bazy danych, w której działa kod.

Podobnie poniższy przykładowy kod wyszukuje dane z lokalnej książki adresowej:

Najlepszym rozwiązaniem do wyszukiwania kodu byłoby przeanalizowanie kodu. To pozwoliłoby nam rozwiązać wartość ht_filename w powyższych przykładach. Jednak nie znaleźliśmy na to mądrego rozwiązania.

Znaleźliśmy sprytne rozwiązanie do wyszukiwania kodu z precyzyjną negacją:

Używamy wyrażeń regularnych.

Poniższe wyrażenie regularne jest ogromnym krokiem naprzód. Pozwala nam szukać dowolnego @DbLookup, który nie wyszukuje danych z tej samej bazy danych, z której działa:

@dblookup([^;];(?!””(:””)?).*
@dblookup(Otwarty nawias musi być chroniony w wyrażeniach regularnych, stąd \(
[^;]*;po którym następuje „wszystko oprócz średnika” aż do następnego średnika.

Wyszukiwanie „.*;” byłoby błędne, ponieważ to wyrażenie byłoby zachłanne. Będzie wyszukiwać do ostatniego średnika.
(?!””(:””)?)Następnie negacja „”, po której następuje kolejne opcjonalne :„” – drugim parametrem może być „” lub „„:„”
.*do końca linii

Ten przykład nadal wymaga dopracowania

  • obsługuje również dowolną ilość białych znaków prawie wszędzie,
  • i obsługuj sytuacje, w których @dbname lub @subset(@dbname;1):@subset(@dbname;-1) używają tej samej bazy danych
  • i znajdź tylko te @DbLookups, dla których klasa to „” lub „Notatki” (wielkość liter nie ma znaczenia)

Jako dodatkowe punkty możesz również chcieć znaleźć @dblookups używane w LotusScript Evaluates. Często cudzysłowy również wymagają zmiany znaczenia.

Wyrażenie regularne, które spełnia wszystkie powyższe wymagania (z wyjątkiem parsowania kodu) jest… prawdopodobnie najbrzydszą rzeczą, jaką dziś zobaczysz: 

Mógłbym wymieniać i wymieniać godzinami

Jeśli udało ci się przejść przez te naprawdę przerażające rzeczy powyżej, chylę czoła przed tobą! Jesteś programistą superbohaterów i przeżyłeś wyrażenia regularne.

Dobra wiadomość dla wszystkich czytelników jest taka: my w panagenda wykonali już sporo ciężkiej pracy. I uwielbiamy się dzielić.

Jeśli spojrzysz na naszą iDNA Applications piaskownica, znajdziesz ponad 70 gotowych wyrażeń regularnych. Wyszukują one ponad 300 różnych znalezisk kodów. Możesz użyć wszystkich tych wzorców w swoim własnym rozwiązaniu do wyszukiwania kodu ZA DARMO.

I na wypadek, gdybyś miał mądrzejszy pomysł niż używanie wyrażeń regularnych lub wpadł na jakieś nowe lub ulepszone wyrażenia regularne: daj nam znać, a my z kolei podzielimy się z community.

Jeśli nie masz czasu na zbudowanie własnego kod rozwiązanie wyszukiwania:

Istnieje wiele rozwiązań innych firm, które mogą pomóc. Niektóre z nich są dostępne w OpenNTF. Niektóre z nich to rozwiązania komercyjne, takie jak nasze własne panagenda iDNA Applications.

Podsumowując

Właściwa analiza Twoich aplikacji służy trzem głównym celom:

  • Oszczędność (dużo) czasu, frustracji i pieniędzy
  • Koncentracja na właściwych rzeczach i wiedza
  • Umożliwienie udanej transformacji krajobrazu Domino

Optymalizacja, modernizacja lub migracja

  • Cokolwiek robisz, nie zapomnij obdarzyć miłością przynajmniej jednej ze swoich aplikacji Domino. To ci się zwróci. Wiele ty

Następny w naszej serii

Raporty z postępów. Są częścią każdego projektu i nie są zabawne w produkcji. Musisz dzielić się nie tylko swoimi postępami. Musisz także dostarczyć zespołom projektowym dane, których potrzebują do wykonywania swojej pracy. To trudne do skoordynowania i nigdy się nie kończy. Ale raporty z postępów mogą być twoim przyjacielem, gdy zgłaszasz sukces!

Projekty migracji i modernizacji są niezwykle kosztowne i bardzo głośne. Od samego początku wiele oczu będzie skierowanych na ciebie. Oczekiwania będą wysokie. Jak uchronić swój projekt przed niepowodzeniem? Czasami nie możesz. Niektóre projekty są skazane na niepowodzenie, zanim jeszcze się rozpoczną. Powinieneś wiedzieć przed wyjazdem.

Odtąd będzie to ciągłe poszerzanie kręgu zastosowań, nad którymi pracujemy. Każdy krok będzie bardziej kosztowny, a rozważne planowanie przyniesie jeszcze większe korzyści.

O tej serii:

Wiele firm na całym świecie zobowiązało się do HCL Notes/Domino* przez lata. Znają wiele korzyści płynących z tego związku. Ponadto Notes/Domino leży w centrum ich procesów i sposobu ich działania. Mimo to decydenci IT na całym świecie zaczynają wyobrażać sobie przyszłość, w której Notes/Domino może odgrywać mniejszą rolę lub wcale.

*dawniej IBM Notes/Domino