Najlepsze praktyki dotyczące funkcji

Użyj funkcji do zapisywania danych w tabelach

Zalecane podejście

Twórz funkcje, gdy wiele aplikacji lub etapów aplikacji zapisuje dane do tej samej tabeli oraz gdy konieczne jest zapewnienie:

• Pola obowiązkowe
• Dopuszczalne wartości (na przykład status musi pochodzić z zatwierdzonej listy)
• Spójne metadane (autor, data utworzenia)

Dlaczego ma to znaczenie

Gdy programiści-amatorzy tworzą rekordy w tabeli bezpośrednio w wyzwalaczach, mogą:

• Nie przestrzegać konwencji nazewnictwa identyfikatorów
• Pominąć pola obowiązkowe
• błędnie wpisać wartości pól („in progress” zamiast „in-progress”)
• Niespójnie wypełniać metadane

Funkcja wymusza stosowanie tego samego schematu i zapobiega tym błędom.

Przykład

Zamiast pozwalać każdemu twórcy aplikacji na tworzenie rekordów „Próbka” z niespójnymi polami i treścią, utwórz funkcję „Utwórz próbkę”, która:

• Wymaga spójnych danych wejściowych (identyfikator zadania, typ próbki, ilość, sygnatura czasowa, użytkownik, nazwa aplikacji)
• Sprawdza, czy typ próbki znajduje się na liście zatwierdzonych

Funkcja:CreateSample Dane wejściowe: - job_id (tekst) - sample_type (tekst) - quantity (liczba) - nazwa aplikacji (tekst) - użytkownik składający żądanie (użytkownik)

Logika: 1. Sprawdź, czy sample\_type znajduje się w ["A", "B", "C"] 2. Jeśli jest nieprawidłowy, zwróć komunikat o błędzie 3. Utwórz rekord w tabeli zawierający: - ID: wygenerowane w ramach funkcji - ID zadania: wartość z argumentu wejściowego - Typ próbki: wartość z argumentu wejściowego - Ilość: wartość z argumentu wejściowego - Numer partii: wartość z argumentu wejściowego (lub puste, jeśli nie podano) - Utwórca: wartość z argumentu wejściowego 4. Zwróć komunikat o pomyślnym zakończeniu

Wyniki: - status (tekst): „success” lub „error” - komunikat (tekst): opis błędu w przypadku niepowodzenia

Gdy trzeba utworzyć rekord w tabeli dla próbki, należy przekazać dane wejściowe do funkcji, a ona zajmie się resztą.

Wzorzec, którego należy unikać

Nie należy tworzyć funkcji dla każdej operacji zapisu do tabeli, nawet tych prostych.

Dlaczego powoduje to problemy

• Powoduje rozrost funkcji (setki funkcji jednorazowego użytku)
• Zwiększa złożoność bez żadnych korzyści w przypadku prostych operacji zapisu
• Utrudnia debugowanie (więcej miejsc do sprawdzenia)

Kiedy należy unikać funkcji do zapisów w tabeli

• Aktualizacja istniejącego rekordu w tabeli (na przykład aktualizacja statusu lub zmniejszenie ilości)
• Pojedyncze operacje zapisu do tabeli w aplikacji
• Brak konieczności stosowania zasad zarządzania lub walidacji

Należy używać funkcji w przypadku powtarzalnej logiki wieloetapowej

Zalecane podejście

Jeśli ta sama sekwencja akcji wyzwalających występuje na wielu etapach w różnych aplikacjach, należy wyodrębnić ją do funkcji.

Przykład: Pobierz kod ZPL do wydrukowania etykiety

Funkcja: Pobierzkod ZPLDane wejściowe: - Identyfikator materiału (tekst)

Zmienne: - Zmienna kodu ZPL (tekst)

Wyniki: - Kod ZPL (tekst)

Logika: 1. Zaktualizuj dane: Konfiguracja „Zmienna kodu ZPL” — ustaw na — [Wyrażenie dla kodu ZPL zawierające @Inputs.ID materiału] 2. Zwróć: „Kod ZPL” Źródło danych „Zmienna kodu ZPL”

Wzorzec, którego należy unikać

Nie należy tworzyć funkcji dla logiki, która występuje łącznie tylko 1–2 razy we wszystkich aplikacjach.

Dlaczego powoduje to problemy

• Nakład związany z zarządzaniem funkcją przewyższa korzyści
• Zmusza twórców aplikacji do nauki interfejsu funkcji na potrzeby rzadkiego przypadku
• Utrudnia debugowanie ze względu na konieczność przełączania się między funkcjami a aplikacjami

Osadzaj funkcje łącznika w funkcjach

Zalecane podejście

Korzystając z funkcji łącznika, należy przekazać dane wejściowe tej funkcji do funkcji, która ją wywołuje. Funkcja ta może wówczas w łatwiejszy i scentralizowany sposób obsługiwać ponowne próby w przypadku przekroczenia limitu czasu oraz radzić sobie z błędami, co pozwala uprościć logikę aplikacji w całym rozwiązaniu.

Osadzanie funkcji łączników w funkcjach może również zminimalizować nakład pracy związany z ewentualną przyszłą migracją systemu ERP poprzez zmniejszenie liczby zmian, które trzeba będzie wprowadzić w poszczególnych aplikacjach.

Przykład

Funkcja: Aktualizacjazlecenia produkcyjnegoDane wejściowe: - Identyfikator zlecenia (tekst) - Status (tekst)

Wyniki: - Komunikat o błędzie (tekst)

Zmienne: - Kod HTTP (liczba całkowita) - Liczba ponownych prób w przypadku przekroczenia limitu czasu (liczba całkowita) - Komunikat o błędzie (tekst)

Logika: 1. Uruchom funkcję łącznika 2. Jeśli kod HTTP oznacza sukces, zakończ funkcję 3. Jeśli kod HTTP oznacza przekroczenie limitu czasu, a liczba „Prób po przekroczeniu limitu czasu” jest mniejsza lub równa określonej wartości, zwiększ liczbę „Prób po przekroczeniu limitu czasu” i wróć do „Uruchom funkcję łącznika”4. Jeśli kod HTTP nie może zostać rozpoznany przez logikę funkcji, zwróć pomocny komunikat w polu wyjściowym „Komunikat o błędzie”

Przekazuj identyfikatory rekordów, a nie poszczególne pola rekordów tabeli

Zalecane podejście

Gdy funkcja potrzebuje danych z rekordu tabeli, należy przekazać identyfikator rekordu i załadować rekord wewnątrz funkcji.

Przykład

Chociaż poniższy przykład jest logicznie poprawny (gdzie „ID zamówienia” to identyfikator z tabeli „Zamówienia”, a pozostałe pola to kolumny w tej tabeli), istnieje prostsza konfiguracja.

Funkcja: Przetwarzaniezamówienia Dane wejściowe: - Identyfikator zamówienia (tekst) - Nazwa klienta (tekst) - Identyfikator produktu (tekst) - Ilość (liczba) - Termin realizacji (data i godzina) - Priorytet (tekst)

Logika: 1. [Wykonaj logikę przy użyciu pól wejściowych]

Poniższy przykład wykorzystuje minimalną liczbę danych wejściowych, aby osiągnąć ten sam wynik:

Funkcja: Przetwarzaniezamówienia Dane wejściowe: - Identyfikator zamówienia (tekst)

Logika: 1. Pobierz rekord z tabeli: tabela „Zamówienia”, gdzie ID = wprowadzony „ID zamówienia” 2. [Wykonaj logikę przy użyciu pól rekordu tabeli]

Dlaczego drugi przykład jest lepszym rozwiązaniem:

• Mniejsza liczba danych wejściowych (1 zamiast 6+)
• Funkcja może łatwo dostosować się w przypadku zmian w schemacie tabeli
• Bardziej przejrzyste wywołania funkcji w aplikacjach
• Zmniejsza ryzyko przypisania niewłaściwego pola do niewłaściwego parametru

Należy spójnie nazywać i opisywać funkcje oraz argumenty

Zalecane podejście

Stosuj spójną konwencję nazewniczą dla wszystkich funkcji w obszarze roboczym.

Nazwy funkcji

• Używaj formy czasownik + rzeczownik: Utwórz próbkę, Zaktualizuj status zadania, Sprawdź numer seryjny
• Nie używaj samych rzeczowników: Próbka, Zlecenie, Numer seryjny

Opis funkcji

• Napisz intuicyjny opis działania funkcji. Na przykład dla funkcji o nazwie „Utwórz usterkę” napisz opis typu „Tworzy nowy rekord w tabeli Usterki ze statusem OTWARTY”.

Nazwy danych wejściowych

• Używaj spójnej terminologii: zawsze „ID zlecenia pracy” (a nie czasami „ID zamówienia” lub „Work_id”)
• W miarę możliwości dopasuj nazwy pól tabeli

Nazwy bloków logicznych

• Bądź konkretny: „Pobierz rekord zlecenia”, a nie „Pobierz rekord tabeli”
• Pomóż przyszłym czytelnikom: „Sprawdź typ próbki”, a nie „Sprawdź wartość”

Dlaczego to ma znaczenie

• Twórcy aplikacji szybko rozumieją przeznaczenie funkcji
• Zmniejsza obciążenie poznawcze podczas korzystania z wielu funkcji
• Ułatwia analizę „gdzie jest używane”
• Poprawia jakość dokumentacji i szkoleń

Płynne obsługiwanie walidacji danych wejściowych i komunikatów o błędach użytkownika

Zalecane podejście

Zawsze oznaczaj dane wejściowe funkcji jako pola wymagane i stosuj reguły walidacji danych wejściowych tam, gdzie jest to właściwe. Nie waliduj danych wejściowych w funkcjach.

Dlaczego ma to znaczenie

• Użytkownicy aplikacji otrzymują jasne informacje zwrotne podczas wprowadzania wartości
• Upraszcza to logikę funkcji, ponieważ to aplikacja zajmuje się sprawdzaniem poprawności danych, a funkcja działa na danych, o których wiadomo, że są poprawne
• Zapobiega uszkodzeniu danych spowodowanemu nieprawidłowymi danymi wejściowymi

Wzorzec, którego należy unikać

Nie należy sprawdzać poprawności danych wejściowych wewnątrz funkcji.

Dlaczego powoduje to problemy

• Jest to zbędne, ponieważ edytor aplikacji oferuje już funkcje sprawdzania poprawności danych wejściowych
• Dodatkowe, niepotrzebne opóźnienie związane z ponownym sprawdzaniem poprawności danych wejściowych w obrębie funkcji

Ogranicz liczbę zapytań do tabel w pętlach

Jeśli funkcja przechodzi przez tablicę w pętli, unikaj wysyłania zapytań do tabel przy każdej iteracji. Zamiast tego wyślij zapytanie raz przed pętlą i odwołaj się do wyniku.

Używaj funkcji do logiki, a nie do prostych odwołań

Nie twórz funkcji, które służą wyłącznie do pobierania pojedynczego rekordu z tabeli — do tego służą operatory record placeholders. Funkcje zarezerwuj dla logiki, która przekształca dane.

Ogranicz rozmiar danych wyjściowych

Jeśli funkcja zwraca duże obiekty lub tablice, rozważ zwracanie tylko tych pól, których potrzebuje aplikacja, a nie całej tablicy obiektów.

Dodatkowe zasoby

{{snippet.Czy znalazłeś to, czego szukałeś?}}