Problemy architektury konfiguracji 1C dla programistów

Krytyczne problemy architektury standardowych konfiguracji 1C

Standardowe konfiguracje 1C często umieszczają logikę biznesową bezpośrednio w formularzach, ograniczając jej wykonanie do środowiska klienckiego. Procedury w formularzach i modułach obiektów rzadko są oznaczone jako eksportowane, co uniemożliwia ich bezpośrednie wywołanie bez użycia rozszerzeń. Funkcje są ściśle powiązane i zależą od kontekstu formularza, łamiąc fundamentalną zasadę izolacji.

Przykłady typowych powiązań:

• Import wyciągów bankowych jest możliwy wyłącznie z poziomu formularza listy lub dokumentu.
• Uzupełnianie danych firmy lub kontrahenta na podstawie NIP jest ściśle powiązane z elementami formularza, co wymusza duplikowanie kodu przy programistycznym tworzeniu obiektów.

Taka architektura znacząco utrudnia ponowne wykorzystanie i testowanie modułów.

Nieracjonalne wykorzystanie wywołań serwera

Programiści 1C nadmiernie polegają na modułach z sufiksem _WywołanieSerwera_, wielokrotnie duplikując wywołania tych samych procedur. Funkcje w modułach ogólnego przeznaczenia są wywoływane bezpośrednio na serwerze bez flagi „Wywołanie serwera”, a następnie ponownie – przez moduły proxy z tą flagą, co prowadzi do niepotrzebnego rozrostu kodu.

Dziesiątki takich modułów w standardowych konfiguracjach dezorientują programistę. Bardziej logiczne byłoby eksportowanie procedur serwerowych za pomocą słowa kluczowego Eksport, bez zbędnych opakowań.

Monstrualne zapytania zamiast czytelnego kodu

Pozyskiwanie danych realizowane jest głównie za pomocą zapytań, nawet gdy wystarczające byłyby metody obiektowe. W modułach menedżerów dokumentów zapytania generują dane do wydruków, ale przy obliczaniu ruchów rozrastają się w nieczytelne konstrukcje z wieloma złączeniami i warunkami.

To poświęca czytelność na rzecz deklaratywności, utrudniając debugowanie i przyszłe modyfikacje. Alternatywą jest połączenie zapytań z logiką imperatywną w dedykowanych procedurach.

Niejednoznaczne struktury danych

Przy generowaniu wydruków kilka dokumentów tabelarycznych jest łączonych w jeden, rozdzielanych obszarami (_Dokument1_, _Dokument2_), zamiast przekazywania kolekcji. Struktury kolekcji imitują obiekty, ale ich skład pól często jest nielogiczny, co wymaga ręcznego mapowania przy modyfikacjach.

Chaotyczne łańcuchy asynchroniczne

Łańcuchy wywołań asynchronicznych w 1C są nazwane niejasno: nazwy procedur nie odzwierciedlają ich celu, brakuje komentarzy. Debugowanie procesu drukowania fiskalnych paragonów to typowy przykład – długa sekwencja bez jednego punktu wejścia.

Optymalnym podejściem jest automat stanów z parametrem aktualnego stanu, który dysponuje wywołaniami.

Przykład pseudokodu automatu:

Procedura WykonajDziałanie(AktualnyStan) Eksport
    Jeśli AktualnyStan = "Inicjalizacja" Wtedy
        InicjalizujParagon();
        PrzejdźDoStanu("Formowanie");
    InaczejJeśli AktualnyStan = "Formowanie" Wtedy
        SformujParagon();
        PrzejdźDoStanu("Probicie");
    // I tak dalej
    KoniecJeśli;
KoniecProcedury;

Brak bezpiecznego debugowania

Operacje krytyczne, takie jak komunikacja z drukarkami fiskalnymi, nie obsługują emulacji odpowiedzi. Kod oczekuje rzeczywistej odpowiedzi sprzętu, wykluczając testy wirtualne. Zwiększa to ryzyko podczas rozwoju i integracji.

Niestabilne nazewnictwo i refaktoryzacja

Obiekty aplikacyjne, moduły i pola są regularnie zmieniane, czasem z prefiksem _Usunąć_. Wyszukiwanie _Usunąć_ w konfiguracji zwraca setki elementów. Terminy takie jak „partnerzy/kontrahenci/kupujący” są niestabilne, a encje (umowy akceptacyjne) to łączone, to rozdzielane.

Takie podejście wskazuje na impulsywne decyzje architektoniczne, zmuszając programistów do marnowania czasu na migrację referencji.

Niespójność interfejsów

Elementy interfejsu mają zmienne nazwy: przycisk dodawania w części tabelarycznej _ZasobyDodaj_ lub po prostu _Dodaj_. Prawa kolumna dokumentu to _PrawaKolumna_ lub _NaglowekPrawo_. Utrudnia to automatyzację i tworzenie rozszerzeń.

Niewydajne algorytmy

Pomimo nacisku na wydajność, kod zawiera zbędne elementy. Przy drukowaniu faktur VAT ładowane są z góry wszystkie szablony, choć potrzebne są tylko nieliczne. Buforowanie na żądanie zminimalizowałoby obciążenie w 99% przypadków.

Duplikacja funkcjonalności HTTP

Różne zespoły implementują żądania HTTP osobno (dla bankowości bezpośredniej, wymiany ze stroną), bez jednego punktu przechwytywania. Brakuje ujednoliconego proxy do konfiguracji.

Wady funkcjonalne

Standardowe rozwiązania nie radzą sobie z rzeczywistymi scenariuszami z powodu uproszczonych założeń metodyków.

Problemy z obliczaniem kosztu wytworzenia

Przejście na miesięczne zamykanie okresów sprawdza się w dużej produkcji, ale dla handlu i średnich firm tworzy bariery: ujemne stany magazynowe na koniec okresu blokują rozliczenia.

Ograniczenia sprzętowe

Zakaz używania dwóch kas na jednym stanowisku to przykład blokowania optymalizacji korzystnych dla biznesu.

Nieprawidłowe rozliczanie bonusów

Bonusy z terminem ważności wymagają ewidencji partiami, ale 1C przechodzi na metody uśredzone, co prowadzi do błędów. Wersja 2.5 pogarsza problem, czyniąc funkcjonalność bezużyteczną bez przepisania.

Przestarzały model uprawnień dostępu

Role opierają się na checkboxach, ignorując dynamiczny kod. Pełne uprawnienia obejmują administracyjne, pozwalając użytkownikom tworzyć konta i pobierać bazę danych.

Co jest ważne

• Sztywność architektoniczna: powiązanie z formularzami i kontekstem ogranicza ponowne wykorzystanie.
• Duplikacja kodu: moduły _WywołanieSerwera_ mnożą logikę.
• Nieczytelne zapytania: potwory zamiast metod obiektowych.
• Brak emulacji: niemożliwość testowania operacji fiskalnych.
• Niestabilne nazewnictwo: setki elementów _Usunąć_ utrudniają utrzymanie.

— Editorial Team