Problémy architektury konfigurací 1C pro vývojáře

Kritické problémy architektury standardních konfigurací 1C

Standardní konfigurace 1C často umisťují aplikační logiku přímo do formulářů, čímž omezují její běh na klientské prostředí. Procedury ve formulářích a modulech objektů jsou jen zřídka označeny jako exportované, což znemožňuje jejich přímé volání bez použití rozšíření. Funkce jsou navzájem úzce provázané a závisí na kontextu formuláře, čímž porušují princip izolace.

Příklady typických vazeb:

• Načítání bankovních výpisů je možné pouze z formuláře seznamu nebo dokumentu.
• Vyplňování údajů o organizaci nebo obchodním partnerovi na základě identifikačního čísla (DIČ) je svázáno s prvky formuláře, což při programovém vytváření objektů vyžaduje duplikaci kódu.

Taková architektura výrazně komplikuje opětovné využití a testování modulů.

Iracionální využívání volání serveru

Vývojáři 1C se nadměrně spoléhají na moduly s příponou _VoláníServeru_, čímž duplikují volání stejných procedur. Funkce v modulech obecného určení jsou volány bez příznaku „Volání serveru" přímo na serveru a následně znovu prostřednictvím proxy modulů s tímto příznakem, což vede k zbytečnému množení kódu.

Desítky podobných modulů ve standardních konfiguracích vývojáře zcela dezorientují. Bylo by mnohem logičtější exportovat serverové procedury pomocí klíčového slova Export, bez zbytečných obálek.

Monstrózní dotazy namísto čitelného kódu

Získávání dat je realizováno převážně pomocí dotazů, i když by postačovaly objektové metody. V modulech manažerů dokumentů dotazy připravují data pro tisk, ale pro výpočet pohybů se rozrůstají do nečitelných konstrukcí s množstvím spojení a podmíněných větví.

Tím se čitelnost obětuje ve prospěch deklarativního přístupu, což komplikuje ladění i úpravy. Alternativou je kombinace dotazů s imperativní logikou přímo v procedurách.

Nejednoznačné datové struktury

Při generování tiskových sestav se více tabulkových dokumentů slučuje do jednoho a odděluje se oblastmi (_Dokument1_, _Dokument2_) namísto předávání kolekcí. Struktury kolekcí napodobují objekty, ale jejich složení polí je často nelogické, což při úpravách vyžaduje ruční mapování.

Chaotické asynchronní řetězce

Řetězce asynchronních volání v 1C jsou pojmenovány neinformativně: názvy procedur nevystihují jejich účel a chybí komentáře. Ladění procesu tisku fiskálních dokladů ukazuje typický příklad – dlouhá posloupnost bez jediného vstupního bodu.

Optimální přístup představuje konečný automat s parametrem aktuálního stavu, který volání řídí a směruje.

Příklad pseudokódu automatu:

Procedura ProvéstAkci(AktuálníStav) Export
    Pokud AktuálníStav = "Inicializace" Pak
        InicializovatČek();
        PřejítKStavu("Formování");
    JinakPokud AktuálníStav = "Formování" Pak
        SestavitČek();
        PřejítKStavu("Probíjení");
    // At dál.
    KonecPokud;
KonecProcedury

Chybějící bezpečné ladění

Kritické operace, jako je komunikace s fiskálními tiskárnami, nepodporují emulaci odpovědí. Kód očekává skutečnou odezvu hardwaru, což vylučuje virtuální testování. To zvyšuje rizika při vývoji a integracích.

Nestabilní pojmenování a refaktorizace

Aplikační objekty, moduly a pole jsou pravidelně přejmenovávány, někdy s prefixem _Smazat_. Vyhledávání _Smazat_ v konfiguraci vrátí stovky položek. Termíny jako „partneři/obchodní partneři/zákazníci" nejsou stabilní a entity (např. smlouvy o akceptaci platebních karet) se střídavě slučují nebo rozdělují.

Tento přístup svědčí o impulzivních architektonických rozhodnutích, která vývojáře nutí trávit čas migrací odkazů.

Nekonzistence rozhraní

Prvky rozhraní mají variabilní názvy: tlačítko pro přidání v tabulkové části _ZasobyPridat_ nebo jednoduše _Pridat_. Pravý sloupec dokumentu je pojmenován _PravySloupec_ nebo _HlavickaPrava_. To komplikuje automatizaci i tvorbu rozšíření.

Neefektivní algoritmy

Navzdory důrazu na výkon obsahuje kód zbytečné nadbytečnosti. Při tisku daňových dokladů se předem načítají všechny šablony, ačkoliv je potřeba jen několik z nich. Načítání do mezipaměti na vyžádání by v 99 % případů minimalizovalo zátěž.

Duplikace funkcionality HTTP

Různé týmy implementují požadavky HTTP odděleně (pro přímé bankovnictví, výměnu dat s webem), bez jednotného zachytávacího bodu. Chybí sjednocený proxy modul pro konfiguraci.

Defekty funkcionality

Standardní řešení často selhávají v reálných scénářích kvůli zjednodušujícím předpokladům metodiků.

Problémy s výpočtem vlastních nákladů

Přechod na měsíční uzavírání vyhovuje velké výrobě, ale pro obchod a střední podniky vytváří bariéry: záporné zůstatky na konci období zablokují výpočet.

Omezení týkající se hardwaru

Zákaz provozu dvou pokladen na jednom pracovním místě je příkladem blokování optimalizací, které by byly pro podnikání výhodné.

Nekorektní evidence bonusů

Propadající bonusy vyžadují dávkovou evidenci, ale 1C přechází na průměrné metody, což vede k chybám. Verze 2.5 tento problém zhoršuje a činí funkcionalitu bez přepsání kódu nepoužitelnou.

Zastaralý model přístupových práv

Role jsou orientovány na zaškrtávací políčka a ignorují dynamický kód. Plná práva zahrnují i administrativní oprávnění, což uživatelům umožňuje vytvářet účty a stahovat databázi.

Co je důležité

• Architektonická rigidita: vazba na formuláře a kontext omezuje opětovné využití.
• Duplikace kódu: moduly _VoláníServeru_ množí logiku.
• Nečitelné dotazy: monstrózní konstrukce namísto objektových metod.
• Chybějící emulace: nemožnost testovat fiskální operace.
• Nestabilní pojmenování: stovky prvků s prefixem _Smazat_ komplikují údržbu.

— Editorial Team