1C - Dobro a zlo. Uspořádání bodů v holivarech kolem 1C

Přátelé a kolegové, v poslední době se častěji objevují články o Habrém s nenávistí vůči 1C jako vývojové platformě a projevy jejích obhájců. Tyto články identifikovaly jeden vážný problém: kritici 1C jej nejčastěji kritizují z pozice „neovládání“, nadávají na problémy, které se de facto snadno řeší, a naopak se nedotýkají problémů, které jsou skutečně důležité, stojí za to. diskutující a nejsou řešeny prodejcem . Věřím, že má smysl provést střízlivý a vyvážený přezkum platformy 1C. Co umí, co neumí, co by měl dělat, ale nedělá, a pro dezert, co dělá s třesknutím, a vaši vývojáři v %technology_name% to udělají sto let a zahodí to více než jeden roční rozpočet.

Výsledkem je, že jako manažer nebo architekt budete moci jasně pochopit, jaký úkol pro vás bude výhodné používat 1C a kde je třeba jej vypálit horkým železem. Jako vývojář ve světě „non-1C“ budete moci vidět, co je v 1C, co způsobuje rozruch. A jako vývojář 1C budete moci porovnat svůj systém s ekosystémy jiných jazyků a porozumět své poloze v souřadnicovém systému vývoje softwaru.

Pod řezem je spousta silných útoků na 1C, na kritiky 1C, na Javu, .NET a obecně... Ventilátor je plný, vítejte!

O mně

Předmět rozhovoru znám přibližně od roku 2004. Programuji snad od 6 let, od chvíle, kdy se mi do ruky dostala kniha o profesoru Fortranovi s komiksy o kočce, vrabci a housence. Z obrázků v knize jsem rozebíral programy, které kočka psala, a zjišťoval, co dělaly. A ano, v té době jsem ještě neměl skutečný počítač, ale byla tam kresba na šíření knihy a já poctivě mačkal papírová tlačítka a zadával příkazy, které jsem špehoval na kočce X.

Pak tu byl BK0011 a BASIC ve škole, C++ a assemblery na univerzitě, pak 1C a pak tolik dalších věcí, že jsem líný si to pamatovat. Posledních 15 let se věnuji především 1C, nejen co se kódování týče, ale 1C obecně. Nastavení úkolů, administrace a devops zde. Posledních 5 let se věnuji společensky užitečným činnostem ve smyslu vývoje vývojových a automatizačních nástrojů pro ostatní uživatele 1C, psaní článků a knih.

Pojďme se rozhodnout o předmětu diskuse

Nejprve si definujme, o čem budeme hovořit, protože písmena „1C“ mohou znamenat spoustu věcí. V tomto případě budeme písmeny „1C“ mínit výhradně vývojový rámec „1C: Enterprise“ moderní, osmé verze. Nebudeme moc mluvit o výrobci a jeho politice (ale budeme muset trochu udělat), nebudeme rozebírat konkrétní aplikace napsané pomocí tohoto frameworku. Technologie je oddělená, aplikace alias konfigurace jsou oddělené.

Architektura na vysoké úrovni 1C: Enterprise

Ne nadarmo uvádím slovo „rámec“. Z pohledu vývojáře je platforma 1C přesně rámcem. A musíte s ním zacházet přesně jako s rámcem. Představte si to jako Spring nebo ASP.NET, spouštěné nějakým runtimem (JVM nebo CLR). Stává se tak, že ve světě konvenčního programování („ne 1C“) je rozdělení na frameworky, virtuální stroje a specifické aplikace přirozené, protože tyto komponenty jsou obvykle vyvíjeny různými výrobci. Ve světě 1C není zvykem explicitně rozlišovat samotný vývojový framework a runtime, navíc konkrétní aplikace napsané pomocí frameworku jsou také převážně vyvíjeny samotným 1C. V důsledku toho vzniká určitý zmatek. Proto v rámci článku budeme muset uvažovat 1C z několika stran najednou a klasifikovat jej podle několika souřadnicových os. A do každé souřadnicové osy dáme lopatu hnědé hmoty a podíváme se na vlastnosti, výhody a nevýhody stávajícího řešení.

Názory na 1C

1C pro kupujícího

Kupující si zakoupí automatizační systém, se kterým může rychle vyřešit problémy s automatizací vlastního podnikání. Podnik může být malý stánek nebo to může být velká holdingová společnost. Je jasné, že potřeby těchto podniků jsou různé, ale oba jsou podporovány jedinou základnou kódu platformy.

Pro kupujícího 1C je to rychlý čas uvedení na trh. Rychle. Rychlejší než Java, C# nebo JS. Průměrný. Kolem nemocnice. Je jasné, že vizitkový web využívající React dopadne lépe, ale backend systému WMS se na 1C spustí rychleji.

1C jako nástroj

Každé technologické řešení má limity použitelnosti. 1C není univerzální jazyk; nežije odděleně od svého rámce. Je vhodné použít 1C, když potřebujete:

• serverová aplikace
• aplikace, kde se objevují finance
• s připraveným uživatelským rozhraním, ORM, Reporting, XML/JSON/COM/PDF/YourDataTransferingFormat
• s podporou procesů a úloh na pozadí
• se zabezpečením na základě rolí
• se skriptovatelnou obchodní logikou
• se schopností rychle vytvořit prototyp a krátkou dobou uvedení na trh

Nepotřebujete 1C, pokud chcete:

• strojové učení
• výpočty GPU
• počítačová grafika
• matematické výpočty
• CAD systému
• zpracování signálu (zvuk, video)
• highload http volání se stovkami tisíc rps

1C jako výrobní společnost

Stojí za to pochopit, co je podnikání 1C jako výrobce softwaru. Společnost 1C prodává řešení obchodních problémů prostřednictvím automatizace. Různé podniky, velké nebo malé, ale to je to, co prodává. Prostředkem k dosažení tohoto cíle jsou podnikové aplikace. Pro účetnictví, mzdové účetnictví atd. K psaní těchto aplikací využívá společnost vlastní platformu pro vývoj obchodních aplikací. Speciálně přizpůsobené pro běžné úkoly těchto stejných podnikových aplikací:

• Finanční účetnictví
• snadné přizpůsobení obchodní logiky
• široké možnosti integrace v heterogenních prostředích IT

Jako výrobce se 1C domnívá, že toto je strategie, která vám umožní pracovat s partnery a klienty v režimu win-win. S tím můžete polemizovat, ale zhruba takto se společnost propaguje: hotová řešení obchodních problémů, která mohou partneři rychle přizpůsobit a integrovat do jakéhokoli prostředí IT.

Všechny nároky nebo přání pro 1C jako rámec by měly být nahlíženy výhradně tímto prizmatem. „Chceme OOP v 1C,“ říkají vývojáři. "Kolik nás bude stát podpora OOP v platformě, pomůže nám to zvýšit prodej krabic?" říká 1C. Otevírá jeho „prizma“ prodeje řešení obchodních problémů:

- Hele, obchod, chceš OOP ve svém 1C?
- Pomůže mi to vyřešit mé problémy?
- Kdo ví...
- Pak to není potřeba

Tento přístup může být dobrý nebo špatný v závislosti na tom, kdo se na něj dívá, ale tak to prostě je. Když už mluvíme o tom, že v 1C není žádná funkce X, musíte pochopit, že tam není z nějakého důvodu, ale v kontextu volby „náklady na implementaci vs. částka zisku“.

Technologické zařazení

„Ve skutečnosti se Odinesniks ze všech sil snaží používat ty nejlepší vzory, pečlivě vybrané starostlivými metodiky a vývojáři platformy 1C.
Když píšete svůj hloupý kód pro jednoduchý spravovaný formulář, ve skutečnosti používáte model-view-controller с obousměrná datová vazba в třívrstvý-data-app-engine, ochucené objekt-relační-mapování na vysoké úrovni na základně deklarativní popis metadatmít vlastní dotazovací jazyk nezávislý na platformě, c deklarativní datově řízené uživatelské rozhraní, kompletní transparentní serializace a doménově orientovaný programový jazyk.

Kde se vývojáři 1C liší od svých západních kolegů, je PR. Rádi dávají každému kousku odpadu velké jméno a běhají s ním jako se špinavým pytlem.“
A. Orefkov

Platforma 1C má klasickou 3-vrstvou architekturu, v jejímž středu je aplikační server (resp. jeho emulace za málo peněz pro malé obchodníky). Jako DBMS se používá buď MS SQL nebo Postgres. Existuje také podpora pro Oracle a IBM DB2, ale to je spíše esoterické, nikdo neví, co se stane, pokud implementujete 1C na tyto databáze při střední a vysoké zátěži. Věřím, že 1C sám to neví.

Klientská část je buď tenký klient nainstalovaný na počítači uživatele, nebo webový klient. Klíčovou vlastností je, že programátoři nepíší 2 různé kódy, píší jednu aplikaci v jednom jazyce a v případě potřeby nebo potřeby ji můžete zobrazit v prohlížeči. Kdo tam chtěl skutečný plný zásobník a jeden jazyk pro frontend a backend, node.js? Nikdy se jim nepodařilo udělat úplně to samé až do konce. Skutečný plný zásobník existuje, ale budete ho muset napsat v 1C. Ironie osudu, takové věci :)

Cloudové řešení SaaS 1C:Fresh funguje také v režimu prohlížeče, ve kterém si nemůžete koupit 1C, ale pronajmout si malou databázi a sledovat tam prodeje shawarma. Pouze v prohlížeči, bez instalace nebo konfigurace.

Kromě toho existuje starší klient, který se v 1C nazývá „běžná aplikace“. Legacy is legacy, vítejte ve světě aplikací v roce 2002, ale stále se bavíme o aktuálním stavu ekosystému.

Serverová část 1C podporuje klastrování a škálování přidáním nových strojů do klastru. Zde bylo rozbito poměrně hodně kopií a v článku o tom bude samostatná sekce. Stručně řečeno, toto není úplně stejné jako přidání několika přesně stejných instancí za HAProxy.

Framework pro vývoj aplikací používá vlastní programovací jazyk, který zhruba připomíná mírně vylepšený VB6 přeložený do ruštiny. Pro lidi, kteří nenávidí vše ruské, kteří nevěří, že „if“ je přeloženo jako „pokud“, je nabízena druhá možnost syntaxe. Tito. Pokud chcete, můžete to napsat v 1C tak, aby to bylo k nerozeznání od VB.

Právě tento programovací jazyk je hlavním důvodem nenávisti přezdívek 1C vůči jejich platformě. Přiznejme si to, ne bezdůvodně. Jazyk byl koncipován tak jednoduše, jak je to jen možné, navržený tak, aby naplňoval mantru „VÝVOJÁŘI, VÝVOJÁŘI“ v měřítku alespoň v SNS. Komerční podstata takového řešení je podle mého názoru jasně viditelná: více vývojářů, větší pokrytí trhu. To se splnilo, podle různých odhadů ze 45 % na 95 %. Hned řeknu, že psát v jazyce, který si myslíte, je opravdu jednodušší. A umím docela dost programovacích jazyků.

Začněme jazykem.

1C programovací jazyk

Zároveň silná a slabá stránka systému. Poskytuje snadný vstup a čitelnost. Na druhou stranu nebyl od vydání verze 8 v roce 2002 aktualizován a je morálně zastaralý. Někdo řekne „hlavní nevýhodou je, že neexistuje žádný OOP“ a bude se mýlit. Za prvé, OOP nemá ráda nejen Nuralieva, ale ani Torvalda. A za druhé, OOP stále existuje.

Z pohledu vývojáře má k dispozici framework se základními třídami zobrazenými na DBMS. Vývojář může převzít základní třídu „Directory“ a zdědit z ní adresář „Clients“. Může do ní přidávat nová pole tříd, například INN a Address, a také v případě potřeby může přepsat (přepsat) metody základní třídy, například metodu OnWrite/AtRecord.

Framework je navržen tak, že hlubší dědičnost je málokdy potřeba a omezení v OOP podle mě dává smysl. 1C se zaměřuje na vývoj řízený doménou a nutí vás přemýšlet především o předmětu vyvíjeného řešení, a to je dobře. Není zde nejen žádné pokušení, ale také není potřeba psát 10 různých DTO a ViewModelů jen proto, aby se někde ukázala nějaká data z domény. Vývojář 1C vždy operuje s jednou entitou, aniž by zaplňoval kontext vnímání tuctem tříd s podobnými názvy, které představují stejnou entitu, ale z jiné strany. Jakákoli aplikace .NET bude například nutně obsahovat pět nebo dva ViewModely a DTO pro serializaci do JSON a přenos dat z klienta na server. A přibližně 10–15 % kódu vaší aplikace bude vynaloženo na přenos dat z jedné třídy do druhé pomocí per nebo berliček, jako je AutoMapper. Tento kód musí být napsán a programátoři musí být placeni za jeho vytvoření a údržbu.

Ukazuje se, že jazyk 1C je obtížné vyvinout, aniž bychom jej zkomplikovali na úroveň mainstreamových jazyků, čímž ztrácí výhodu jednoduchosti. Co je v podstatě řešeno za úkol prodejce: vydat standardní řešení, které si každý student přistižený na ulici může upravit s požadovanou úrovní kvality (t.j. je dokončeno zakrytí případu od stánku po velkou továrnu). Pokud jste stánek, vezměte studenta, pokud jste továrna, vezměte si guru od svého implementačního partnera. Skutečnost, že implementační partneři prodávají studenty za cenu guru, není problém s frameworkem. Architektonicky musí framework řešit problémy obou, kód standardních konfigurací (který jsme prodali firmám s příslibem přizpůsobení) by měl být schopen pochopit student a guru by měl být schopen porozumět, co chcete.

Co podle mě v jazyce opravdu chybí, co vás nutí psát víc, než byste uměli, je to, co plýtvá časem placeným zákazníkem.

• Možnost psaní na úrovni, například TypeScript (výsledkem je rozvinutější nástroje pro analýzu kódu v IDE, refaktoring, méně útočných jambů)
  Dostupnost funkcí jako prvotřídní objekty. Poněkud složitější koncept, ale množství typického standardního kódu by se dalo výrazně snížit. Studentovo porozumění kódu, IMHO, by se dokonce zvýšilo kvůli snížení objemu
• Univerzální sbírkové literály, inicializátory. Totéž – snížení množství kódu, který je třeba napsat a/nebo se na něj podívat očima. Plnění kolekcí zabere přes 9000 % programovacího času 1C. Psát toto bez syntaktického cukru je dlouhé, drahé a náchylné k chybám. Obecně platí, že množství LOC v řešeních 1C přesahuje všechny myslitelné limity ve srovnání s dostupnými otevřenými frameworky a obecně se všemi vašimi podnikovými Java dohromady. Jazyk je upovídaný a to se zvrhává na množství dat, paměti, brzd IDE, času, peněz...
• konečně konstrukce Mám hypotézu, že tato konstrukce chybí kvůli tomu, že nenašli její úspěšný překlad do ruštiny :)
• Vlastní datové typy (bez OOP), analogy Type od VB6. Umožní vám nezadávat struktury pomocí komentářů v BSP a magických metod, které tyto struktury konstruují. Získáme: méně kódu, nápovědu přes tečku, rychlejší řešení problému, méně chyb kvůli překlepům a chybějícím vlastnostem struktur. Typování uživatelských struktur nyní zcela spočívá na vývojovém týmu knihovny Standard Subsystem Library, který ke své cti pečlivě píše komentáře k očekávaným vlastnostem předávaných struktur parametrů.
• Žádný cukr při práci s asynchronními voláními na webovém klientovi. callback-hell v podobě ProcessingNotifications je dočasná berlička způsobená náhlou změnou API hlavních prohlížečů, ale takhle se nedá žít pořád, ztrácí se výhoda „studentského porozumění“ asynchronnímu kódu víc a víc. Přidejte žádnou podporu tohoto paradigmatu v hlavním IDE a věci se ještě zhorší.

Toto je jeden z palčivých problémů, je jasné, že seznam by mohl být mnohem větší, ale nesmíme zapomínat, že se stále nejedná o univerzální jazyk, nevyžaduje multithreading, lambda funkce, přístup ke GPU a rychlý výpočty s plovoucí desetinnou čárkou. Toto je skriptovací jazyk obchodní logiky.

Programátora, který už s tímto jazykem hodně pracoval, kouká do js nebo c#, se v rámci tohoto jazyka začne nudit. to je fakt. Potřebuje rozvoj. Na druhé straně stupnice jsou pro dodavatele náklady na implementaci specifikovaných funkcí oproti nárůstu příjmů po jejich implementaci. Zde nemám žádné informace o tom, co aktuálně v očích firmy převažuje.

Vývojové prostředí

Ani tady to nejde hladce. Existují dvě vývojová prostředí. Prvním je konfigurátor, který je součástí dodávky. Druhým je prostředí Enterprise Development Tools, zkráceně EDT, vyvinuté na bázi Eclipse.

Konfigurátor poskytuje celou řadu vývojových úloh, podporuje všechny funkce a je hlavním prostředím na trhu. Je také morálně zastaralý, nevyvíjí se, podle pověstí - kvůli množství technického dluhu uvnitř sebe. Situaci by mohlo zlepšit otevření interního API (ve formě přátelství s Sněhulák A. Orefkové nebo na nezávislé bázi), ale není tomu tak. Praxe ukázala, že komunita bude psát své vlastní funkce v IDE, pokud do ní nebude zasahovat dodavatel. Ale máme, co máme. Konfigurátor byl v letech 2004-2005 skvělý, hodně připomínal tehdejší Visual Studio, místy byl i chladnější, ale v těch časech se zasekl.

Navíc objem průměrného standardního řešení od té doby několikrát vzrostl a IDE dnes prostě nezvládá množství kódu, kterým je napájeno. Použitelnost a možnosti refaktoringu nejsou ani nulové, jsou v červených číslech. To vše vývojářům nadšení nepřidává a sní o tom, že se přesunou do jiných ekosystémů a budou tam dál kódovat sračky, ale v příjemném prostředí, které vám svým chováním neplivne do tváře.

Jako alternativa je nabízeno IDE napsané od začátku, postavené na Eclipse. Tam jsou zdroje, jako v každém jiném softwaru, živé ve formě textových souborů, jsou uloženy v GIT, pull request větve, to vše. Nevýhodou je, že již mnoho let neopustil status beta, i když se s každým vydáním zlepšuje. Nebudu psát o nevýhodách EDT, dnes je to mínus, zítra je to pevná funkce. Relevance takového popisu rychle zmizí. Dnes je možné vyvíjet v EDT, ale je to neobvyklé, musíte být připraveni na určitý počet chyb IDE.

Pokud se na situaci podíváte výše zmíněným „1C hranolem“, dostanete něco takového: vydání nového IDE nezvýší prodeje krabic, ale může se snížit odliv VÝVOJÁŘŮ. Je těžké říci, co čeká ekosystém z hlediska komfortu pro vývojáře, ale Microsoft už podělal mobilní vývojáře tím, že jim své služby nabídl příliš pozdě.

Řízení vývoje

Všechno je zde výrazně lepší než při psaní kódu, zvláště v poslední době, kdy snahy komunity vynesly na světlo problémy automatizace administrace, spustily prototypy volající po vyhození úložiště 1C do koše a použití git, rychlé obviňování, revize kódu , statická analýza, automatické nasazení atd. Do platformy bylo přidáno mnoho funkcí, které zvyšují úroveň automatizace vývojových úloh. Všechny tyto funkce však byly přidány pouze a výhradně pro vývoj našich vlastních velkých produktů, kdy bylo zřejmé, že se bez automatizace neobejdeme. Došlo k automatickému sloučení, třícestnému srovnání s KDiff a tak dále. Spuštěno na Github gitconverter, který byl, upřímně řečeno, ideologicky od projektu odtažen gitsync, ale upravený tak, aby vyhovoval procesům společnosti dodavatele. Díky tvrdohlavým klukům z open-source se automatizace vývoje v 1C rozjela. Otevřené API pro konfigurátor, IMHO, by také posunulo morální zaostalost hlavního IDE.

Dnes ukládání zdrojů 1C v git s commity spojenými s problémy v Jira, recenze v Crucible, tlačítka od Jenkinse a Allure hlásí o testování kódu v 1C a dokonce statická analýza v SonarQube - to je daleko od novinek, ale spíše o mainstream ve firmách, kde se hodně vyvíjí 1C.

podávání

Tady je toho hodně co říct. Za prvé je to samozřejmě server (1C serverový cluster). Nádherná věc, ale vzhledem k tomu, že se jedná o zcela černou skříňku, dostatečně podrobně, ale specificky zdokumentovanou - zvládnutí spouštění nepřetržitého provozu v režimu vysoké zátěže na několika serverech je údělem pár vyvolených, kteří nosí medaile s nápisem „Expert na technologické otázky“. Stojí za zmínku, že správa serveru 1C se v zásadě neliší od správy jakéhokoli jiného serveru. Je to síťová aplikace s více vlákny, která spotřebovává paměť, CPU a diskové prostředky. Poskytuje dostatek příležitostí pro sběr telemetrie a diagnostiku.

Problém je v tom, že prodejce nenabízí nic speciálního z hlediska hotových řešení právě pro tuto diagnostiku. Ano, existuje 1C: Instrumentation and Control Center, jsou dokonce docela dobré, ale jsou velmi drahé a ne každý je má. V komunitě existuje řada vylepšení pro připojení Grafana, Zabbix, ELK a dalších věcí ze standardní sady administrátorů, ale neexistuje jediné řešení, které by vyhovovalo většině. Úkol čeká na svého hrdinu. A pokud jste firma, která plánuje spuštění na clusteru 1C, potřebujete odborníka. Své vlastní uvnitř nebo zvenčí, ale potřebujete to. Je normální, že existuje samostatná role s kompetencemi pro provoz serveru, ne každý uživatel 1C by to měl vědět, stačí pochopit, že taková role je potřeba. Vezměme si například SAP. Tam se programátor s největší pravděpodobností ani nezvedne ze židle, pokud je požádán, aby na aplikačním serveru něco nakonfiguroval. Může být jen hloupý a nebude se stydět. V metodice SAP pro to existuje samostatná role zaměstnance. Z nějakého důvodu se v průmyslu 1C věří, že by to mělo být kombinováno u jednoho zaměstnance za stejný plat. Je to klam.

Nevýhody 1C serveru

Je tu přesně jedno mínus - spolehlivost. Nebo, chcete-li, nepředvídatelnost. O náhlém podivném chování serveru se již začalo mluvit ve městě. Univerzální prostředek - zastavení serveru a vymazání všech mezipamětí - je dokonce popsán v příručce pro odborníky a dokonce se doporučuje dávková kniha, která to dělá. Pokud váš systém 1C začne dělat něco, co by ani teoreticky dělat neměl, je čas vymazat mezipaměť dat relace. Podle mého odhadu jsou v celé zemi jen tři lidé, kteří vědí, jak obsluhovat 1C server bez tohoto postupu a nesdílejí tajemství, protože... z toho žijí. Možná je jejich tajemstvím, že čistí data relace, ale nikomu o tom neřeknou, kámo.

Jinak je server 1C stejná aplikace jako kterákoli jiná a je spravován v podstatě stejným způsobem, čtením dokumentace a klepáním na tamburínu.

přístavní dělník

Užitečnost použití kontejnerového 1C serveru ve výrobě zatím nebyla prokázána. Server není klastrován pouhým přidáním uzlů za balancer, což snižuje výhody produkční kontejnerizace na minimum a nebyla zavedena praxe úspěšného provozu v kontejnerech v režimu vysokého zatížení. Výsledkem je, že pouze vývojáři používají Docker+1C k nastavení testovacích prostředí. Tam je to velmi užitečné, aplikované, umožňuje vám hrát si s moderními technologiemi a odpočinout si od sklíčenosti konfigurátoru.

Komerční složka

Z investičního hlediska vám 1C umožňuje vyřešit problém rychlého spuštění obchodních nápadů díky širokým možnostem tříd aplikací. 1C z krabice dává velmi slušný Reporting, integrace s čímkoli, webový klient, mobilní klient, mobilní aplikace, podpora různých DBMS vč. bezplatné, multiplatformní serverové i nainstalované klientské části. Ano, uživatelské rozhraní aplikací bude žluté, někdy je to mínus, ale ne vždy.
Výběrem 1C firma získá sadu softwarových řešení, která jim umožní budovat velmi širokou škálu aplikací, a také spoustu vývojářů na trhu, kteří chtějí méně peněz než Javaisté a zároveň rychleji produkují výsledky.

Například úkol poslat klientovi PDF fakturu lze vyřešit za hodinu studentské práce. Stejný problém v .NET lze vyřešit zakoupením proprietární knihovny nebo několika dny či týdny kódování strohým, vousatým vývojářem. Někdy obojí najednou. A ano, mluvil jsem pouze o generování PDF. Ještě jsme neřekli, odkud tento návrh zákona přijde. Webový frontender musí vytvořit formulář, kam bude operátor zadávat data, backender bude muset vytvořit dto modely pro přenos JSON, modely pro uložení do databáze, samotnou strukturu databáze, migraci do ní, vytvoření grafického zobrazení právě tohoto účtu a teprve potom - PDF. Na 1C je celý úkol od nuly dokončen přesně za hodinu.

Plnohodnotný účetní systém pro malý stánek s jedním obchodním procesem nákup/prodej je hotový za 3 hodiny S reportováním prodejů, účtováním zboží v nákupních a prodejních cenách v členění podle skladu, kontrolou přístupových práv, webového klienta a mobilní aplikace . Dobře, zapomněl jsem na aplikaci, s aplikací ne za 3 hodiny, za šest.

Jak dlouho bude tento úkol trvat vývojáři .NET od instalace vizuálního studia na čistý počítač po jeho předvedení zákazníkovi? A co náklady na vývoj? Stejná věc.

Přednosti 1C jako platformy

1C je silný ne proto, že by na něm bylo něco specifického, co je nejlepší na světě. Naopak v každém jednotlivém subsystému můžete najít zajímavější analogii ve světovém softwaru. Na základě kombinace faktorů však nevidím platformu podobnou 1C. V tom spočívá komerční úspěch. Výhody platformy jsou rozptýleny po celé ploše a nejzřetelněji jsou viditelné, když vidíte, jak se to dělá na jiných platformách. V zásadě to ani NEJSOU rysy, ale naopak – odmítnutí rysů ve prospěch jednoho konkrétního paradigmatu. Několik příkladů:

1. Unicode. Co sakra může být jednoduššího? V roce 2019 není potřeba používat jednobajtová kódování ASCII (s výjimkou integrace se starými staršími). Nikdy. Ale ne. Každopádně někdo v nějaké tabulce používá jednobajtový varchar a aplikace bude mít problémy s kódováním. V roce 2015 selhala autorizace LDAP gitlabu kvůli nesprávné práci s kódováním; JetBrains IDE stále nefunguje všude s azbukou v názvech souborů. 1C poskytuje vysoce kvalitní izolaci kódu aplikace od databázové vrstvy. Tam je nemožné psát tabulky na nízké úrovni a hromady neschopných juniorů na úrovni databáze jsou nemožné. Ano, mohou tam být jiné problémy od neschopných juniorů, ale škála problémů je mnohem menší. Nyní mi řeknete, že vaše aplikace je navržena správně a vrstva přístupu k databázi je izolovaná, jak má být. Podívejte se znovu na svou firemní vlastní aplikaci Java. Pečlivě a upřímně. Trápí vás svědomí? Pak mám z tebe radost.
2. Číslování dokumentů/příruček. V 1C rozhodně není nejflexibilnější a ne nejlepší. Ale to, co dělají v bankovním softwaru a v samostatně psaných účetních systémech - no, je to prostě tma. Buď se zasekne identita (a pak „aha, proč máme díry“), nebo naopak vyrobí generátor, který pracuje se zamykáním na úrovni DBMS (a stane se úzkým hrdlem). Ve skutečnosti je poměrně obtížné provést tento zdánlivě jednoduchý úkol - end-to-end enumerátor entit, s sekcí jedinečnosti založenou na určité sadě klíčů, prefixací, aby neblokoval databázi při paralelním zadávání dat .
3. Identifikátory záznamů v databázi. 1C učinilo rázné rozhodnutí – všechny identifikátory odkazů jsou absolutně syntetické a to je vše. A nejsou žádné problémy s distribuovanými databázemi a výměnami. Vývojáři jiných systémů tvrdohlavě vytvářejí něco jako identitu (je kratší!), přetahují je do GUI, dokud není čas vytvořit několik souvisejících instancí (a pak budou objeveny). Nemáš tohle? Upřímně řečeno?
4. Seznamy. 1C má docela úspěšné mechanismy pro procházení (velkých) seznamů a procházení v nich. Dovolte mi provést rezervaci ihned - při správném použití mechanismu! Obecně je to téma dost nepříjemné, nedá se ideálně vyřešit: buď je intuitivní a jednoduché (ale riziko obrovských záznamů na klientovi), nebo je stránkování tak či onak pokřivené. Ti, kteří stránkují, to často dělají křivě. Ti, kteří dělají poctivý posuvník, přidávají databázi, kanál a klienta.
5. Spravované formuláře. Není pochyb o tom, že ve webovém klientovi rozhraní nefunguje dokonale. Ale funguje to. Ale pro mnoho dalších účetních a bankovních systémů je vytvoření vzdáleného pracoviště projektem na podnikové úrovni. Prohlášení: naštěstí pro ty, kteří to původně vytvořili na webu, to nebude mít vliv.
6. Mobilní aplikace. V poslední době můžete také psát mobilní aplikace ve stejném ekosystému. Zde je to trochu složitější než u webového klienta, specifika zařízení vás nutí psát přímo pro ně, ale přesto si nenajímáte samostatný tým mobilních vývojářů. Pokud potřebujete aplikaci pro interní potřeby firmy (když je mobilní řešení firemního problému důležitější než žlutý design uživatelského rozhraní), jednoduše použijete stejnou platformu hned po vybalení.
7. Hlášení. Tímto slovem nemyslím BI systém s velkými daty a zpožděním na ETL procesu. Jedná se o výkazy provozních zaměstnanců, které umožňují posoudit stav účetnictví tady a teď. Zůstatky, vzájemné vyrovnání, přehodnocení atd. 1C přichází z krabice se systémem hlášení s flexibilním nastavením seskupení, filtrů a vizualizace na straně uživatele. Ano, na trhu existují analogy chladičů. Ale ne v rámci all-in-one řešení a za cenu někdy vyšší než all-in-one řešení. A častěji je to dokonce naopak: pouze reportování, ale dražší než celá platforma a horší kvalita.
8. Tisknutelné formuláře. No, použijte .NET k vyřešení problému se zasíláním výplatních pásek v PDF zaměstnancům e-mailem. A nyní úkol tisknout faktury. Co takhle uložit jejich kopie do stejného PDF? Pro přezdívku 1C je výstup jakéhokoli rozvržení do PDF +1 řádek kódu. To znamená + 40 sekund pracovní doby místo dnů nebo týdnů v jiném jazyce. Rozvržení tištěných formulářů v 1C se neuvěřitelně snadno vyvíjí a je dostatečně výkonné, aby konkurovalo placeným protějškům. Ano, pravděpodobně v tabulkových dokumentech 1C není mnoho interaktivních příležitostí; pomocí OpenGL nemůžete rychle získat 3D diagram s měřítkem. Ale je to opravdu nutné?

Toto je jen hrstka příkladů, kdy se omezení funkčnosti nebo zavádění kompromisů ukazuje jako důležitý architektonický přínos do budoucna. Dokonce i kompromis nebo ne nejúčinnější možnost - je již v krabici a považuje se za samozřejmost. Jeho nezávislá implementace bude buď nemožná (protože taková rozhodnutí musí být učiněna na začátku projektu a na to není čas a vůbec žádný architekt), nebo několik drahých iterací. V každém z uvedených bodů (a to není úplný seznam architektonických řešení) se můžete podělat a zavést omezení, která blokují škálování. V každém případě se jako obchodník musíte ujistit, že vaši programátoři při vytváření „systému od nuly“ mají rovné ruce a okamžitě dobře provedou jemné systémové problémy.

Ano, stejně jako v každém jiném komplexním systému má 1C sám také řešení, která blokují škálování v určitých aspektech. Nicméně opakuji, na základě kombinace faktorů, nákladů na vlastnictví a množství již předem vyřešených problémů nevidím na trhu důstojného konkurenta. Za stejnou cenu získáte finanční aplikační framework, clusterovaný vyvážený server, s UI a webovým rozhraním, s mobilní aplikací, s reportingem, integrací a hromadou dalších věcí. Ve světě Java si najmete front-endový a back-endový tým, ladíte nízkoúrovňové hejna podomácku psaného serverového kódu a platíte zvlášť za 2 mobilní aplikace pro 2 mobilní OS.

Neříkám, že 1C vyřeší všechny případy, ale pro interní podnikovou aplikaci, kdy není potřeba brandovat UI - co jiného je potřeba?

Háček

Pravděpodobně jste nabyli dojmu, že 1C zachrání svět a že všechny ostatní způsoby psaní firemních systémů jsou špatné. Vůbec to tak není. Z pohledu obchodníka, pokud zvolíte 1C, musíte kromě rychlého uvedení na trh vzít v úvahu následující nevýhody:

• Spolehlivost serveru. Jsou vyžadováni opravdu kvalitní specialisté, kteří dokážou zajistit jeho nepřetržitý provoz. Není mi znám žádný hotový školicí program pro takové specialisty od dodavatele. Existují kurzy na přípravu na zkoušku Expert, ale to podle mého názoru nestačí.
• Podpěra, podpora. Viz předchozí odstavec. Abyste měli podporu od dodavatele, musíte si ji koupit. Z nějakého důvodu to není v průmyslu 1C akceptováno. A u SAP je to téměř nutností a nikoho to neobtěžuje. Bez firemní podpory a bez experta na zaměstnance můžete zůstat sami s 1C závadami.
• Přesto nemůžete s 1C dělat úplně všechno. Toto je nástroj a jako každý nástroj má své limity použitelnosti. V prostředí 1C je velmi žádoucí mít architekta systému „non-1C“.
• Dobré přezdívky 1C nejsou levnější než dobří programátoři v jiných jazycích. I když je pronájem špatných programátorů drahý, bez ohledu na jazyk, ve kterém píší.

Udělejme tečky

• 1C je framework pro rychlý vývoj aplikací (RAD) pro podnikání a je k tomu přizpůsoben.
• Třívrstvé propojení s podporou hlavních DBMS, klientským uživatelským rozhraním, velmi dobrým ORM a reportingem
• Široké možnosti integrace se systémy, které umí to, co 1C nedokáže. Pokud chcete strojové učení, vezměte Python a pošlete výsledek do 1C přes http nebo RabbitMQ
• Není třeba se snažit dělat vše pomocí 1C, musíte pochopit jeho silné stránky a použít je pro své vlastní účely
• Vývojáři, kteří tíhnou k tomu, že se ponoří do vychytávek technologického rámce a každých N let přepracují na nový engine, se s 1C nudí. Všechno je tam velmi konzervativní.
• Vývojáři se také nudí, protože se o ně ze strany výrobce zajímá velmi málo. Nudný jazyk, slabé IDE. Vyžadují modernizaci.
• Na druhou stranu vývojáři, kteří nemohou najít zábavu používáním a učením se jiné technologii, která je baví, jsou špatní vývojáři. Budou kňučet a přesunout se do jiného ekosystému.
• Zaměstnavatelé, kteří nedovolí svým 1C přezdívkám napsat něco v Pythonu, jsou špatní zaměstnavatelé. Přijdou o zaměstnance se zvídavou myslí a na jejich místo přijdou opičí kodéři, kteří ač se vším souhlasí, zatáhnou firemní software do bažin. Bude se to muset ještě přepsat, takže možná by bylo lepší trochu zainvestovat do Pythonu o něco dříve?
• 1C je komerční společnost a implementuje funkce výhradně na základě svých vlastních zájmů a účelnosti. Nemůžete ji za to vinit, obchod musí myslet na zisk, takový je život
• 1C vydělává peníze prodejem řešení obchodních problémů, nikoli vývojářských problémů Vasyi. Tyto dva pojmy korelují, ale prioritou je přesně to, co jsem řekl. Když je vývojář Vasya připraven zaplatit za osobní licenci pro 1C: Resharper, objeví se to docela rychle, „Resharper“ od A. Orefkové je toho důkazem. Pokud by to prodejce podporoval a nebojoval by proti tomu, objevil by se trh se softwarem pro vývojáře. Nyní je na tomto trhu jeden a půl hráče s pochybnými výsledky, a to vše proto, že integrace s IDE je negativní a vše se děje o berlích.
• Praxe obsluhy více strojů zmizí v zapomnění. Moderní aplikace jsou příliš velké na to, aby si je pamatovaly jak ze strany kódu, tak ze strany obchodního využití. Server 1C se také stává složitějším, nebude možné pojmout všechny typy odborných znalostí u jednoho zaměstnance. To by mělo znamenat poptávku po specialistech, což znamená atraktivitu profese 1C a zvýšení platů. Pokud dříve Vasya pracoval tři v jednom za jeden plat, nyní musíte najmout dva Vasyy a konkurence mezi Vasyy může urychlit celkový růst jejich úrovně.

Závěr

1C je velmi hodnotný produkt. V mém cenovém rozpětí neznám vůbec žádné analogy, napište do komentářů, pokud nějaké existují. Odliv vývojářů z ekosystému je ale čím dál tím znatelnější a jde o „odliv mozků“, ať se na to díváte jakkoli. Průmysl je hladový po modernizaci.
Pokud jste vývojář, nezavěšujte se na 1C a nemyslete si, že v jiných jazycích je všechno kouzelné. Možná, když jsi junior. Jakmile bude potřeba řešit něco většího, bude se muset déle hledat a intenzivněji dokončovat hotová řešení. Pokud jde o kvalitu „bloků“, ze kterých lze postavit řešení, je 1C velmi, velmi dobrý.

A ještě jedna věc - pokud si k vám přijde najmout přezdívka 1C, pak může být přezdívka 1C bezpečně jmenována do pozice vedoucích analytiků. Jejich porozumění úkolu, oblasti předmětu a schopnosti rozkladu je vynikající. Jsem si jistý, že je to právě kvůli nucenému použití DDD ve vývoji 1C. Člověk je trénován k tomu, aby přemýšlel především o smyslu úkolu, o souvislostech mezi objekty předmětné oblasti, a zároveň má technické zázemí v integračních technologiích a formátech výměny dat.

Uvědomte si, že ideální rámec neexistuje a postarejte se o sebe.
Dobré pro všechny!

PS: děkuji moc speshurický za pomoc s přípravou článku.

Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. Přihlásit se, prosím.

Máte ve svém podniku 1C?

• 13,3%Vůbec ne.71

• 30,3%Existuje, ale jen někde v účtárně. Základní systémy na jiných platformách162

• 41,4%Ano, fungují na něm hlavní obchodní procesy221

• 15,0%1C musí zemřít, budoucnost patří %technology_name%80

Hlasovalo 534 uživatelů. 99 uživatelů se zdrželo hlasování.

Zdroj: www.habr.com