1C – Jó és rossz. Pontok elrendezése 1C körüli holivarokban

Barátaim és kollégáim, a Habr az utóbbi időben egyre több olyan cikket látott, amelyek az 1C-t, mint fejlesztői platformot kritizálják, valamint a védelmezőinek nyilatkozatait. Ezek a cikkek egy komoly problémára világítanak rá: az 1C kritikusai leggyakrabban a "megbirkózásra képtelen" álláspontból kritizálják, olyan problémákat kritizálva, amelyek valójában könnyen megoldhatók, miközben éppen ellenkezőleg, figyelmen kívül hagyják a valóban fontos kérdéseket, amelyekről érdemes lenne beszélni, és amelyekkel a gyártó nem foglalkozik. Úgy vélem, hogy van értelme józan és kiegyensúlyozott áttekintést készíteni az 1C platformról. Kitérünk arra, hogy mit tud, mit nem tud, mit kellene tennie, de nem teszi, és végül, de nem utolsósorban, mit csinál zseniálisan, miközben a %technology_name% fejlesztői száz évet fognak ezzel tölteni, sok éves költségvetést elpazarolva.

Ennek eredményeként Ön, mint vezető vagy architekt, világos képet kaphat arról, hogy mely feladatok profitálhatnak az 1C-ből, és hol kell a határait feszegetni. Nem 1C-s fejlesztőként láthatja, mi az 1C különlegessége, ami miatt akkora a felhajtás. 1C fejlesztőként pedig összehasonlíthatja rendszerét más nyelvi ökoszisztémákkal, és megértheti, hol helyezkedik el a szoftverfejlesztési környezetben.

A szöveg alatt rengeteg vastag támadás érkezik az 1C, az 1C kritikusai, a Java, a .NET és általában a felhasználók ellen... A rajongók fel vannak készülve, üdvözöljük!

Magamról

2004 óta ismerkedem ezzel a témával. Valószínűleg úgy hat éve programozok, mióta kaptam egy könyvet Fortran professzorról, képregényekkel egy macskáról, egy verébről és egy hernyóról. Elemeztem a könyv képein látható macska által írt programokat, és kitaláltam, mit csinálnak. És igen, akkoriban még nem volt igazi számítógépem, de volt egy kép a könyv hátulján, és engedelmesen nyomogattam a papírgombokat, beírva azokat a parancsokat, amiket X, a macska című könyvből szedtem össze.

Aztán volt BK0011 és BASIC az iskolában, C++ és assembler az egyetemen, aztán 1C, és aztán annyi minden más, hogy már emlékezni is nehéz rá. Az elmúlt 15 évben elsősorban 1C-vel foglalkoztam, nem csak kódolással, hanem általában az 1C-vel. A feladatkijelölés, az adminisztráció és a DevOps is ide tartozik. Az elmúlt öt évben közösségi szolgálatban vettem részt, fejlesztői és automatizálási eszközöket fejlesztettem más 1C fejlesztőknek, valamint cikkeket és könyveket írtam.

Döntsük el a vita tárgyát

Először is, definiáljuk, miről beszélünk, mivel az "1C" szónak sok minden lehet a jelentése. Ebben az esetben az "1C" kizárólag az 1C:Enterprise fejlesztői keretrendszerre, a jelenlegi nyolcadik verzióra utal. Nem fogunk sokat beszélni a gyártóról vagy a szabályzatairól (de azért egy kicsit szólnunk kell). Nem fogunk konkrétan az ezzel a keretrendszerrel írt alkalmazásokat megvitatni. A technológia különálló, és az alkalmazások (más néven konfigurációk) is különállóak.

Az 1C: Enterprise magas szintű architektúrája

Nem véletlenül említem a „keretrendszer” szót. Fejlesztői szempontból az 1C platform pontosan az – egy keretrendszer. És úgy is kell kezelni. Képzeljük el úgy, mint a Springet vagy az ASP.NET-et, amelyet egy futási környezet (JVM, illetve CLR) hajt végre. A hagyományos („nem 1C”) programozás világában a keretrendszerekre, virtuális gépekre és specifikus alkalmazásokra való felosztás természetes, mivel ezeket a komponenseket jellemzően különböző gyártók fejlesztik. Az 1C világában azonban nem szokás explicit módon megkülönböztetni a fejlesztői keretrendszert és magát a futási környezetet. Továbbá a keretrendszerrel írt specifikus alkalmazásokat nagyrészt maga az 1C is fejleszti. Ez némi zavart okoz. Ezért ebben a cikkben az 1C-t több szempontból is megvizsgáljuk, és több tengely mentén osztályozzuk. És minden tengely mentén beleássuk magunkat a részletekbe, és megvizsgáljuk a meglévő megoldás jellemzőit, előnyeit és hátrányait.

Nézőpontok az 1C-n

1C a vevőnek

A vevő egy olyan automatizálási rendszert szerez be, amely lehetővé teszi számára, hogy gyorsan megoldja saját üzleti automatizálási igényeit. Ez a vállalkozás lehet egy kis kioszk vagy egy nagy holdingtársaság. Bár ezeknek a vállalkozásoknak egyértelműen eltérő igényeik vannak, mindkettőt egyetlen platformkódbázis támogatja.

Egy vevő számára az 1C gyors piacra kerülési időt kínál. Gyors. Gyorsabb, mint a Java, a C# vagy a JS. Átlagosan. Nem feltétlenül. Egyértelmű, hogy egy névjegykártya weboldal jobb lesz Reactben, de egy WMS rendszer backendje gyorsabban indul el az 1C-ben.

1C, mint eszköz

Minden technológiai megoldásnak megvannak az alkalmazhatósági korlátai. Az 1C nem általános célú nyelv; nem létezik a keretrendszerétől függetlenül. Az 1C használata akkor van értelme, ha a következőkre van szükség:

• szerveralkalmazás
• egy pénzügyekkel kapcsolatos alkalmazás
• előre elkészített felhasználói felülettel, ORM-mel, jelentéskészítéssel, XML/JSON/COM/PDF/YourDataTransferingFormat formátummal
• háttérfolyamatok és feladatok támogatásával
• szerepköralapú biztonsági rendszerrel
• szkriptelhető üzleti logikával
• a prototípus gyors létrehozásának és a rövid piacra jutási időnek köszönhetően

Nincs szükséged 1C-re, ha azt akarod:

• gépi tanulás
• GPU-számítások
• számítógépes grafika
• matematikai számítások
• CAD rendszer
• jelfeldolgozás (hang, videó)
• Nagy terhelésű HTTP-hívások több százezer RPS-sel

Az 1C, mint gyártó cég

Fontos megérteni az 1C üzleti tevékenységét, mint szoftvergyártót. Az 1C automatizáláson keresztül értékesít megoldásokat üzleti problémákra. Akár nagy, akár kisvállalkozásoknak szánja, pontosan ezt értékesíti. Az üzleti alkalmazások jelentik az eszközt e cél eléréséhez. Könyvelési, bérszámfejtési és egyéb célokra a vállalat saját üzleti alkalmazásfejlesztési platformot használ ezen alkalmazások fejlesztéséhez. Ez kifejezetten az ugyanezen üzleti alkalmazások gyakori feladataihoz van szabva:

• pénzügyi számvitel
• az üzleti logika egyszerű testreszabása
• széleskörű integrációs lehetőségek heterogén IT környezetekben

Gyártóként az 1C úgy véli, hogy ez a stratégia kölcsönösen előnyös kapcsolatot tesz lehetővé a partnerekkel és az ügyfelekkel. Bár ez vitatható, a vállalat nagyjából így reklámozza magát: üzleti problémákra kész megoldásokat kínál, amelyeket a partnerek gyorsan testre szabhatnak és integrálhatnak bármilyen informatikai környezetbe.

Az 1C-vel, mint keretrendszerrel kapcsolatos minden panaszt vagy kívánságot kizárólag ezen a lencsén keresztül kell vizsgálni. „OOP-t akarunk az 1C-ben” – mondják a fejlesztők. „Mennyibe fog kerülni nekünk az OOP-támogatás a platformon? Segíteni fog-e növelni a dobozos eladásokat?” – kérdezi az 1C. Felfedik az üzleti problémákra adott megoldások értékesítésének „lencséjét”:

— Hé, üzlet, szeretnétek OOP-t az 1C-ben?
– Ez segíteni fog a problémáim megoldásában?
-Ki tudja...
- Akkor nincs rá szükség.

Ez a megközelítés lehet jó vagy rossz, attól függően, hogy ki nézi, de ez egyszerűen így van. Amikor azt mondjuk, hogy az 1C-ben nincs X funkció, meg kell értenünk, hogy az nem okkal van ott, hanem a „bevezetés költsége kontra profit” kompromisszum kontextusában.

Technológiai osztályozás

„Valójában az Odinets felhasználói teljes mértékben kihasználják a legjobb mintákat, amelyeket az 1C platform gondoskodó módszertanosai és fejlesztői gondosan választottak ki.”
Amikor egy egyszerű menedzselt űrlaphoz írod a hülye kódodat, valójában azt használod, hogy modell-nézet-vezérlő с kétirányú adatkötés в háromrétegű adatalkalmazás-motor, ízesített magas szintű objektumkapcsolat-leképezés az alapon deklaratív metaadat-leírás, amelynek megvan a saját platformfüggetlen lekérdezőnyelv, C deklaratív adatvezérelt felhasználói felület, teljesen transzparens szerializáció és domain-orientált programozási nyelv.

Amiben az 1C fejlesztői különböznek nyugati társaiktól, az a PR-juk. Imádnak minden ostobaságot nagy nevet adni, és úgy felháborodni rajta, mintha az a szemük fénye lenne.
A. Orefkov

Az 1C platform klasszikus háromszintű architektúrával rendelkezik, amelynek középpontjában az alkalmazáskiszolgáló (vagy annak emulációja, amely kisvállalkozások számára alacsony költséggel elérhető) áll. Adatbázis-kezelő rendszerként MS SQL-t vagy Postgres-t használnak. Támogatás van Oracle-höz és IBM DB2-höz is, de ez nagyrészt ezoterikus; senki sem tudja, mi fog történni, ha az 1C-t közepes vagy nagy terhelés alatt ezeken az adatbázisokon implementálják. Gyanítom, hogy maga az 1C sem tudja.

A kliensoldal vagy egy, a felhasználó gépére telepített vékony kliens, vagy egy webes kliens. A lényege, hogy a programozók nem két különböző kódot írnak; egyetlen alkalmazást írnak egyetlen nyelven, és azt a felhasználó telepítheti a böngészőben, ha akarja vagy szüksége van rá. Ki akart egy igazi full-stack megoldást egyetlen nyelven, a node.js-sel mind a front-, mind a backend felülethez? Soha nem sikerült teljesen konzisztens élményt elérniük. Létezik igazi full-stack megoldás, de azt 1C-ben kell megírni. Ironikus, de így működik.

Az 1C:Fresh felhőalapú SaaS megoldás böngésző módban is működik. Az 1C megvásárlása helyett bérelhet egy kis adatbázist, és ott követheti nyomon a shawarma eladásait. Egyszerűen használhatja böngészőjében, telepítés vagy beállítás nélkül.

Van egy hagyományos kliens is, amit az 1C „normál alkalmazásnak” nevez. A hagyományos az hagyományos, üdvözlünk a 2002-es alkalmazások világában, de az ökoszisztéma jelenlegi állapotáról beszélünk.

Az 1C szerver támogatja a klaszterezést és a skálázást új gépek hozzáadásával a klaszterhez. Erről elég sok vita folyik, és ezt a cikk egy külön részében tárgyaljuk. Röviden, ez nem egészen ugyanaz, mint néhány azonos példány hozzáadása a HAProxy mögé.

Az alkalmazásfejlesztési keretrendszer saját programozási nyelvet használ, amely nagyjából egy kissé továbbfejlesztett, oroszra fordított VB6-ra hasonlít. Azok számára, akik utálnak mindent, ami orosz, és nem hiszik, hogy az „if” azt jelenti, hogy „ha”, egy második szintaxislehetőséget kínálunk. Ez azt jelenti, hogy ha szükséges, 1C-ben úgy írhatunk, hogy az vizuálisan megkülönböztethetetlen legyen a VB-től.

Pontosan ez a programozási nyelv a fő oka annak, hogy az 1C fejlesztői utálják a platformjukat. Őszintén szólva, nem ok nélkül. A nyelvet a lehető legegyszerűbbnek tervezték, hogy legalább a FÁK szintjén teljesítse a "FEJLESZTŐK, FEJLESZTŐK" mantrát. Véleményem szerint a döntés mögött meghúzódó kereskedelmi indoklás egyértelmű: több fejlesztő, nagyobb piaci elérhetőség. A becslések az esetek 45%-ától 95%-áig terjednek, és rögtön leszögezem, hogy a gondolkodásmódod szerinti nyelven írni valóban könnyebb. És én elég sok programozási nyelvet ismerek.

Kezdjük talán a nyelvvel.

1C programozási nyelv

Ez a rendszer erőssége és gyengesége is egyben. Könnyű bevitelt és olvashatóságot biztosít. Másrészt a 2002-es 8-as verzió óta nem frissítették, és elavult. Egyesek azt mondhatják, hogy "a fő hátrány az OOP hiánya", de tévednének. Először is, nemcsak Nuraliev nem szereti az OOP-t, hanem Torvalds is. Másodszor, az OOP létezik.

Egy fejlesztő szemszögéből nézve van egy keretrendszerük, amelynek alaposztályai a DBMS-hez vannak leképezve. Foghatják a „Directory” alaposztályt, és kiterjeszthetik belőle az „Customers” könyvtárat. Hozzáadhatnak új osztálymezőket, például az adóazonosító számot (TIN) és a címet, és szükség esetén felülbírálhatják az alaposztály metódusait, például az OnWrite metódust.

A keretrendszert úgy tervezték, hogy mélyebb öröklődésre ritkán van szükség, és az OOP korlátozás véleményem szerint értelmes. Az 1C a domainvezérelt fejlesztésre összpontosít, és arra kényszerít, hogy elsősorban a fejlesztendő megoldás témakörére gondolj, és ez jó dolog. Nemcsak nincs kísértés, de nincs szükség arra sem, hogy 10 különböző DTO-t és ViewModel-t írj csak azért, hogy valahol megjelenítsd a domain adatokat. Egy 1C fejlesztő mindig egyetlen entitással dolgozik, anélkül, hogy a kontextusát egy tucat hasonló nevű osztállyal terhelné, amelyek ugyanazt az entitást más perspektívából reprezentálják. Bármely .NET alkalmazás például elkerülhetetlenül tartalmaz néhány ViewModel-t és DTO-t a JSON-ba szerializáláshoz és az adatok kliensről szerverre történő átviteléhez. Az alkalmazás kódjának körülbelül 10-15%-át az adatok egyik osztályból a másikba történő manuális vagy olyan hackek, mint az AutoMapper, átvitelére fordítod. Ezt a kódot meg kell írni, és a programozókat meg kell fizetni a létrehozásáért és karbantartásáért.

Kiderült, hogy az 1C nyelvet nehéz fejleszteni anélkül, hogy a bonyolultságát a mainstream nyelvek szintjére növelnénk, ezáltal elveszítve az egyszerűség előnyét. Mi a szállító végső célja: egy olyan szabványos megoldás leszállítása, amelyet bármelyik, az utcáról lecsapott diák a kívánt minőségi szinten testre szabhat (azaz a helyzet lefedi a kioszktól a nagy gyárig). Ha kioszk vagy, alkalmazz egy diákot; ha gyár vagy, alkalmazz egy gurut egy implementációs partnertől. Az a tény, hogy a implementációs partnerek a diákokat guruk árán adják el, nem a keretrendszer kérdése. Architekturális szempontból a keretrendszernek mindkét fél igényeit ki kell elégítenie; a szabványos konfigurációk kódjának (amelyeket a testreszabás ígéretével értékesítettünk a vállalkozásoknak) érthetőnek kell lennie egy diák számára, és egy guru amúgy is bármit megért.

Ami véleményem szerint igazán hiányzik a nyelvből, ami arra kényszeríti az embert, hogy többet írjon a lehetségesnél, ami felemészti az ügyfél által kifizetett időt.

• Lehetőség van gépelésre például TypeScript szinten (ennek eredményeként fejlettebb kódelemző eszközök érhetők el az IDE-ben, refaktorálás, kevesebb bosszantó hiba)
  Első osztályú objektumok funkciói. Egy kicsit összetettebb koncepció, de a sablonkód mennyisége jelentősen csökkenthető lenne a tipikushoz képest. Véleményem szerint a diákok kódértése is javulna a csökkentett mennyiség miatt.
• Univerzális gyűjteményliterálok és inicializálók. Ugyanez vonatkozik a megírandó és/vagy áttekintendő kód mennyiségének csökkentésére is. A gyűjtemények feltöltése az 1C programozási idő több mint 9000%-át teszi ki. Ennek szintaktikai cukor nélküli megírása időigényes, költséges és hibalehetőségekkel teli. Általánosságban elmondható, hogy az 1C megoldásokban a LOC-ok száma meghaladja az összes elképzelhető határt a rendelkezésre álló nyílt forráskódú keretrendszerekhez, sőt, az összes vállalati Java programhoz képest együttvéve. A nyelv bőbeszédű, és ez adatmennyiséggé, memóriává, IDE-lassulásokká, idővé és pénzzé fajul.
• végre szerkezetek Azt feltételezem, hogy ez a szerkezet hiányzik, mert nem találtak rá jó orosz fordítást 🙂
• Natív adattípusok (nem OO), analógok a VB6 Type típusával. Ez kiküszöböli a struktúrák standard alrendszerkönyvtárban található megjegyzések és mágikus metódusok használatával történő begépelésének szükségességét ezen struktúrák létrehozásához. Az eredmény: kevesebb kód, pontozott tippek, gyorsabb problémamegoldás, valamint kevesebb elgépelés és hiányzó struktúratulajdonság. Jelenleg a felhasználó által definiált struktúrák begépelése teljes mértékben a Standard Subsystem Library fejlesztőcsapatának a felelőssége, amely – javára legyen mondva – aprólékosan írja a megjegyzéseket az átadott paraméterstruktúrák várható tulajdonságaihoz.
• A webes kliensen aszinkron hívásokkal való munka hiánya. A NotificationHandling formájában megjelenő visszahívási pokol egy átmeneti megoldás, amelyet a főbb böngészők API-jainak hirtelen változása okoz, de ez nem tartható fenn örökké; az aszinkron kód „diákszintű megértésének” előnye egyre inkább elvész. Ehhez jön még, hogy a fő IDE-ben hiányzik a paradigma támogatása, és a helyzet még rosszabbra fordul.

Ezek csak néhány a sürgető kérdések közül. A lista nyilvánvalóan sokkal hosszabb is lehetne, de nem szabad elfelejtenünk, hogy ez nem egy általános célú nyelv. Nem igényel többszálú működést, lambda függvényeket, GPU-hozzáférést vagy gyors lebegőpontos számításokat. Ez egy üzleti logikai szkriptnyelv.

Egy programozó, aki sokat dolgozott ezzel a nyelvvel, majd utána a JS-be vagy a C#-ba kezdett beleunni. Ez tény. Fejlődnie kell. A mérleg másik oldalán a szállító mérlegeli ezen funkciók bevezetésének költségeit az általuk generált bevételnövekedéssel szemben. Nincs információm arról, hogy jelenleg melyik a fontosabb szempont a cég szemében.

Fejlesztőkörnyezet

A dolgok itt sem mennek zökkenőmentesen. Két fejlesztői környezet létezik. Az első a Configurator, amely a disztribúció része. A második az Enterprise Development Tools (EDT) környezet, amelyet Eclipse segítségével fejlesztettek.

A konfigurátor teljes körű fejlesztési feladatokat kínál, minden funkciót támogat, és ez a piacon kapható fő környezet. Emellett elavult, és a pletykák szerint a benne lévő technikai adósság mennyisége miatt nem fejlesztik. A helyzeten javítani lehetne a belső API megnyitásával (barátság formájában a ...-val). Hóvihar A. Orefkova vagy függetlenül), de ez nem így van. A tapasztalat azt mutatja, hogy a közösség összekaparja a saját IDE funkcióit, amíg a gyártó nem avatkozik bele. De megvan, amink van. A konfigurátor nagyszerű volt 2004-2005-ben, nagyon emlékeztetett az akkori Visual Studio-ra, sőt néhol még jobb is volt, de akkoriban megrekedt.

Ráadásul az átlagos tipikus megoldás mérete azóta többszörösére nőtt, és a mai IDE-k egyszerűen nem bírják a bevitt kódmennyiséget. A használhatóság és a refaktorálási képességek még csak nem is nullák, sőt, csökkennek. Mindez elriasztja a fejlesztőket, akik arról álmodoznak, hogy más ökoszisztémákba költöznek, és ott továbbra is silányan programoznak, de egy kellemes környezetben, amely nem köpi az arcukba a viselkedésével.

Alternatív megoldásként egy Eclipse-re épülő, a nulláról épített IDE-t kínálunk. A forráskódja, mint bármely más szoftver, GIT-ben tárolt szövegfájlokként, ágakként, pull requestekként és minden egyéb funkcióként él. A hátránya, hogy évek óta nem hagyta el a béta státuszt, bár minden egyes kiadással egyre jobb. Nem fogok részletesen belemenni az EDT hátrányaiba, mondván, hogy a mai hátrány a holnap javított funkciója. Egy ilyen leírás gyorsan irrelevánssá válna. Az EDT-ben való fejlesztés ma már lehetséges, de szokatlan, és fel kell készülni bizonyos számú hibára az IDE-ben.

Ha a fent említett „1C” lencsén keresztül nézzük a helyzetet, az eredmény nagyjából ez: egy új IDE megjelenése nem fogja fellendíteni a dobozos eladásokat, de valószínűleg csökkenti a fejlesztők lemorzsolódását. Nehéz megmondani, hogy mit tartogat a jövő az ökoszisztéma számára a fejlesztők kényelme szempontjából, de a Microsoft már egyszer átverte a mobilfejlesztőket azzal, hogy túl későn ajánlotta fel szolgáltatásait.

Fejlesztésmenedzsment

Itt minden lényegesen jobb, mint a kódírás, különösen az utóbbi időben, amikor a közösség erőfeszítései rávilágítottak az automatizált adminisztrációval kapcsolatos problémákra, az 1C repository eldobását és a git használatát sugalló prototípusok elindítására, a gyors hibázásra, a kódellenőrzésre, a statikus elemzésre, az automatikus telepítésre és így tovább. Számos olyan funkcióval bővült a platform, amelyek növelik a fejlesztési feladatok automatizálásának szintjét. Ezeket a funkciókat azonban kizárólag a saját nagyméretű termékeink fejlesztéséhez adtuk hozzá, amikor világossá vált, hogy az automatizálás már nem lehetséges. Megjelentek az automatikus egyesítések, a háromirányú KDiff összehasonlítások és más hasonló funkciók. Elindítottunk egy GitHub projektet. gitconverterakit őszintén szólva ideológiai okokból kivontak a projektből gitsync, de a gyártó folyamataihoz igazítva. Az elkötelezett nyílt forráskódú csapatnak köszönhetően az 1C fejlesztési automatizálása előrelépett. Véleményem szerint egy nyílt konfigurátor API leküzdené a fő IDE erkölcsi elmaradottságát is.

Manapság az 1C forráskódok Gitben történő tárolása Jira feladatokhoz kapcsolt commitokkal, a Crucible-ben történő áttekintések, a Jenkins-től egy gombbal történő bevezetése, valamint az Allure 1C-ben történő kódtesztelésről szóló jelentései, sőt... statikus elemzés a SonarQube-ban — ez már nem újdonság, hanem inkább általánosan elterjedt azoknál a cégeknél, amelyek sok 1C fejlesztéssel rendelkeznek.

Adminisztráció

Sok mindenről lehetne itt beszélni. Először is, természetesen ott van a szerver (az 1C szerverklaszter). Csodálatos dolog, de mivel egy teljes fekete dobozról van szó, amelyet kellően részletesen, de egy sajátos módon dokumentáltak, a több szerveren történő megszakítás nélküli, nagy terhelésű működés csak néhány kiválasztott, a „Technológiai Szakértő” érmet viselő személy kiváltsága. Érdemes megjegyezni, hogy elvileg egy 1C szerver adminisztrációja nem különbözik bármely más szerver adminisztrációjától. Ez egy hálózatalapú, többszálú alkalmazás, amely memóriát, CPU-t és lemezerőforrásokat fogyaszt. Kiterjedt lehetőségeket kínál a telemetria gyűjtésére és diagnosztikára.

A probléma az, hogy a gyártó nem kínál semmi különlegeset a diagnosztika kész megoldásai terén. Igen, létezik az 1C:KIP és a TsUP, és bár nem rosszak, nagyon drágák, és nem mindenkinek van meg. A közösség számos fejlesztéssel rendelkezik a Grafana, a Zabbix, az ELK és más szabványos adminisztrációs eszközök csatlakoztatására, de nincs egyetlen olyan megoldás, amely a többségnek megfelelne. A feladat a bajnokára vár. És ha olyan vállalkozásról van szó, amely egy 1C klaszteren tervezi elindítani a rendszert, szüksége van egy szakértőre. Akár belső, akár külső szakértőről van szó, szükség van rájuk. Normális, hogy van egy külön szerepkör szerverspecifikus kompetenciákkal; nem minden 1C szakembernek szüksége van erre a tudásra, de meg kell érteni, hogy szükség van egy ilyen szerepkörre. Vegyük például az SAP-t. Egy ottani programozó valószínűleg fel sem kelne a székéből, ha megkérnék, hogy konfiguráljon valamit az alkalmazásszerveren. Lehet, hogy egyszerűen nem tudnak semmit, és nem fognak szégyellni. Az SAP módszertanban erre külön alkalmazotti szerepkör van. Valamiért az 1C iparág úgy véli, hogy ezeket a képességeket egyetlen alkalmazottban kellene egyesíteni ugyanazon fizetésért. Ez tévhit.

Az 1C szerver hátrányai

Csak egy hátránya van: a megbízhatóság. Vagy, ha úgy tetszik, a kiszámíthatatlanság. A hirtelen, kiszámíthatatlan szerverviselkedés a város beszédtémája. Az univerzális megoldás – a szerver leállítása és az összes gyorsítótár törlése – még a szakértői kézikönyvben is le van írva, sőt, egy batch fájlt is ajánlanak erre a célra. Ha az 1C-d olyasmit kezd csinálni, amit elméletileg sem szabadna, itt az ideje, hogy töröld a munkamenet-adatok gyorsítótárát. Véleményem szerint az egész országban csak körülbelül három ember van, aki tudja, hogyan kell egy 1C szervert üzemeltetni e nélkül az eljárás nélkül, és nem osztják meg a titkaikat, mert így keresik a kenyerüket. Talán az a titkuk, hogy törlik a munkamenet-adatokat, de senkinek sem szólnak róla, hehe.

Egyébként az 1C szerver ugyanolyan alkalmazás, mint bármely más, és nagyjából ugyanúgy adminisztrálható, dokumentáció olvasásával és dobolással.

Dokkmunkás

A konténeres 1C szerver éles környezetben való használatának hasznosságát még nem bizonyították. A szerver nem klaszterezhető egyszerűen egy terheléselosztó mögé helyezett csomópontokkal, ami minimalizálja a konténeresítés előnyeit éles környezetben, és a konténerekben való sikeres nagy terhelésű működés sem bizonyított. Ennek eredményeként a Docker + 1C-t csak a fejlesztők használják tesztkörnyezetek beállításához. Ott rendkívül hasznos és praktikus, lehetővé téve a fejlesztők számára, hogy modern technológiákkal játsszanak, és szünetet tartsanak a konfigurációs eszköz fáradságos munkájában.

Kereskedelmi komponens

Befektetési szempontból az 1C lehetővé teszi az üzleti ötletek gyors elindítását az alkalmazásosztályok széleskörű képességeinek köszönhetően. Alapértelmezés szerint az 1C nagyon tiszteletre méltó jelentéskészítési minőséget, mindennel való integrációt, webes klienst, mobilklienst, mobilalkalmazást, különféle adatbázis-kezelő rendszerek (DBMS) támogatását, beleértve az ingyeneseket is, valamint platformfüggetlen támogatást kínál mind a szerver, mind a telepíthető kliens komponensek esetében. Igen, az alkalmazás felhasználói felülete sárga lesz, ami néha hátrány, de nem mindig.
Az 1C választásával egy vállalkozás olyan szoftvermegoldások csomagját kapja, amelyek lehetővé teszik számára, hogy nagyon széles körű alkalmazásokat építsen, valamint rengeteg fejlesztőt a piacon, akik kevesebb pénzt akarnak, mint a Java fejlesztők, és gyorsabb eredményeket érnek el.

Például egy ügyfélnek PDF formátumú számla elküldése elvégezhető egy óra diákmunkával. Ugyanez a feladat .NET-ben elvégezhető egy saját könyvtár megvásárlásával, vagy egy szigorú, szakállas fejlesztő néhány napos vagy heti kódolásával. Néha mindkettő egyszerre. És igen, csak a PDF generálásáról beszéltem. Nem mondtuk, hogy honnan is származik majd a számla. A webes frontend fejlesztőnek kell létrehoznia az űrlapot, ahová az operátor beírja az adatokat, a backend fejlesztőnek DTO modelleket kell létrehoznia a JSON továbbításához, modelleket az adatbázisban való tároláshoz, magát az adatbázis-struktúrát, a migrációkat, magát a számla grafikus ábrázolásának generálását, és csak ezután a PDF-et. Az 1C-ben a teljes feladat, a nulláról, pontosan egy óra alatt elvégezhető.

Egy teljes értékű számviteli rendszer egy kis kioszk számára, egyetlen vételi/eladási üzleti folyamattal, körülbelül három óra alatt felépíthető. Tartalmaz értékesítési jelentéseket, készletnyilvántartást vételi és eladási árak szerint, raktárankénti lebontást, hozzáférés-vezérlést, webes klienst és mobilalkalmazást. Oké, túlzok az alkalmazással kapcsolatban; az alkalmazással nem három, hanem hat órát vesz igénybe.

Mennyi idő alatt telepíti egy .NET fejlesztő a Visual Studio-t egy tiszta számítógépre, amíg bemutatja az ügyfélnek? És mi a helyzet a fejlesztés költségeivel? Pontosan.

Az 1C platform erősségei

Az 1C erőssége nem az, hogy egyetlen konkrét, kategóriájában legjobb funkcióval is rendelkezne. Épp ellenkezőleg, minden egyes alrendszernek van egy érdekesebb megfelelője a globális szoftverek terén. Több tényező kombinációja alapján azonban nem látok az 1C-hez hasonló platformot. Pontosan ebben rejlik a kereskedelmi sikere. A platform előnyei szétszórva vannak, és akkor a legvilágosabban láthatók, amikor megnézzük, hogyan valósítják meg őket más platformokon. Ezek többnyire nem is funkciók, hanem inkább a funkciók elutasítása egy adott paradigma javára. Néhány példa:

1. Unicode. Mi a fene lehetne ennél egyszerűbb? Ne használj egybájtos ASCII kódolásokat 2019-ben (kivéve az átlátszatlan, régi rendszerekkel való integrációt). Kizárt. De nem. Valaki továbbra is egybájtos varchar-t fog használni valamelyik táblázatban, és az alkalmazásnak kódolási problémái lesznek. 2015-ben a GitLab LDAP-engedélyezése nem megfelelő kódoláskezelés miatt meghiúsult, és a JetBrains IDE továbbra sem mindig kezeli a cirill betűket a fájlnevekben. Az 1C kiválóan elkülöníti az alkalmazáskódot az adatbázis rétegtől. Nem engedélyezi az alacsony szintű táblatipizálást, és az inkompetens junior fejlesztők hibái az adatbázis szintjén lehetetlenek. Igen, az inkompetens junior fejlesztők más hibái is lehetségesek, de a problémák választéka sokkal kisebb. Most azt fogod mondani, hogy az alkalmazásod helyesen van megtervezve, és az adatbázis-hozzáférési réteg megfelelően van elkülönítve. Vess még egy pillantást az egyedileg írt vállalati Java alkalmazásodra. Nézd meg alaposan és őszintén. Nem gyötör a lelkiismereted? Akkor örülök neked.
2. Dokumentum/könyvtár számozás. Biztosan nem a legrugalmasabb vagy legjobb az 1C-ben. De amit a banki szoftverekben és az egyedi számviteli rendszerekben művelnek, az egyszerűen elképesztő. Néha beillesztenek egy identitást (aztán "ó, miért vannak lyukak?"), néha létrehoznak egy generátort, amely az adatbázis-kezelő rendszer szintjén zárolással működik (és szűk keresztmetszetet képez). Valójában meglehetősen nehéz ezt a látszólag egyszerű feladatot – egy végponttól végpontig terjedő entitásszámozási rendszert, amelynek egyediségét bizonyos kulcskészletek lebontják, és előtagokkal látják el – úgy megvalósítani, hogy az ne zárolja az adatbázist a párhuzamos adatbevitel során.
3. Adatbázis-rekordazonosítók. Az 1C merész döntést hozott – minden linkazonosító teljesen szintetikus, és kész. És az elosztott adatbázisokkal és tőzsdékkel sincsenek problémák. Más rendszerek fejlesztői makacsul összedobnak valami olyasmit, mint az identity (végül is rövidebb!), és behúzzák a grafikus felhasználói felületbe, amíg el nem jön az ideje több összekapcsolt példány létrehozásának (és akkor már csak egy jutalom vár rájuk). Nálatok nincs semmi ilyesmi? Komolyan?
4. Listák. Az 1C-nek vannak egészen jó mechanizmusai a (nagy) listák görgetésére és a bennük való navigálásra. Hadd tisztázzam azonnal – ez csak akkor igaz, ha helyesen használod a mechanizmust! Ez egy meglehetősen kényes probléma, és nincs ideális megoldás: vagy intuitív és egyszerű (de hatalmas kliensrekordokat kockáztat), vagy a lapozás valamilyen módon hibás. Azok, akik a lapozást megvalósítják, gyakran rosszul csinálják. Azok, akik megfelelő görgetősávot készítenek, összekuszálják az adatbázist, a csatornát és a klienst.
5. Kezelt űrlapok. Persze a webes kliensfelület nem tökéletes. De működik. Sok más könyvelési és banki rendszer esetében azonban egy távoli munkaállomás megvalósítása vállalati szintű projekt. Jogi nyilatkozat: szerencsére ez nem érinti azokat, akik eredetileg a weben valósították meg.
6. Mobilalkalmazás. Az utóbbi időben mobilalkalmazásokat is lehet fejleszteni ugyanazon az ökoszisztémán belül. Ez egy kicsit bonyolultabb, mint egy webes klienssel, mivel az eszköz sajátosságai egyedi fejlesztést igényelnek. Azonban nem kell külön mobilfejlesztőkből álló csapatot felvenni. Ha belső vállalati igényekre van szükséged egy alkalmazásra (amikor egy vállalati problémára a mobil megoldás fontosabb, mint egy mutatós felhasználói felület), egyszerűen ugyanazt a platformot használod alapból.
7. Jelentéskészítés. Ezzel nem egy big data-val és ETL-késéssel rendelkező BI-rendszerre gondolok. Olyan operatív személyzeti jelentésekre gondolok, amelyek lehetővé teszik a számviteli állapot azonnali felmérését. Egyenlegek, elszámolások, készleteltérések és így tovább. Az 1C egy alapértelmezés szerint egy jelentéskészítő rendszert tartalmaz, rugalmas beállításokkal a csoportosításokhoz, szűrőkhöz és a felhasználói oldali vizualizációhoz. Igen, vannak jobb alternatívák a piacon. De ezek nem all-in-one megoldások, és az áruk néha magasabb, mint egy all-in-one megoldásé. Leggyakrabban az ellenkezője történik: csak jelentéskészítés, de drágább, mint a teljes platform, és alacsonyabb minőségű.
8. Nyomtatott űrlapok. Próbáld meg a .NET-et használni a bérszámfejtési dokumentumok PDF formátumban történő e-mailben történő elküldésének problémájára. Mi a helyzet a számlák nyomtatásával? Mi a helyzet a másolataik PDF formátumba mentésével? Egy 1C felhasználó számára bármilyen elrendezés PDF formátumba írása egy plusz kódsort jelent. Ez 40 másodpercnyi munkát jelent, ahelyett, hogy napokat vagy heteket töltene egy másik nyelven. Az 1C-ben nyomtatott űrlapelrendezések hihetetlenül könnyen fejleszthetők és elég hatékonyak ahhoz, hogy versenyezzenek a fizetős megoldásokkal. Igen, az 1C táblázatok valószínűleg nem kínálnak sok interaktív funkciót, és nem lehet gyorsan 3D-s diagramot készíteni méretezéssel OpenGL használatával. De valóban szükséges ez?

Ezek csak néhány példa arra, amikor a funkcionalitás korlátozása vagy a kompromisszumok megvalósítása jelentős építészeti előnyt jelent a későbbiekben. Még egy kompromisszum vagy a nem tökéletes megoldás is már előre elkészített, és magától értetődőnek veszik. Független megvalósítása vagy lehetetlen lenne (mert ezeket a döntéseket a projekt elején kell meghozni, erre pedig nincs idő, és amúgy sincs építész), vagy több költséges iterációt igényelne. Ezen pontok mindegyike (és ez messze nem a teljes lista az építészeti döntésekről) elrontható, és olyan korlátozásokat vezethet be, amelyek akadályozzák a skálázhatóságot. Mindenesetre vállalkozóként gondoskodnia kell arról, hogy a programozói, amikor a nulláról építenek egy rendszert, képzettek legyenek, és azonnal jól kezeljék a finom rendszerrészleteket.

Igen, mint minden más komplex rendszernek, az 1C-nek is vannak olyan megoldásai, amelyek így vagy úgy blokkolják a skálázódást. Azonban ismétlem, a tényezők kombinációját, a birtoklási költségeket és az előre megoldott problémák számát tekintve nem látok méltó versenytársat a piacon. Ugyanannyiért kapsz egy pénzügyi alkalmazás keretrendszert, egy fürtözött, kiegyensúlyozott szervert felhasználói felülettel és webes felülettel, mobilalkalmazást, jelentéskészítést, integrációt és egy csomó egyéb funkciót. A Java világában felbérelsz egy front-end és back-end csapatot, hibakeresed az alacsony szintű problémákat az egyedi szerverkódban, és külön fizetsz két mobilalkalmazásért két mobil operációs rendszerhez.

Nem azt mondom, hogy az 1C minden esetet megold, de egy belső vállalati alkalmazáshoz, amikor nincs szükség a felhasználói felület arculatának módosítására, mire van még szükség?

Szépséghiba

Azt a benyomást keltheti Önben, hogy az 1C megmenti a világot, és a vállalati rendszerek fejlesztésének minden más módszere hibás. Ez egyáltalán nem igaz. Üzleti szempontból, ha az 1C-t választja, a gyors piacra jutási idő mellett a következő hátrányokat is figyelembe kell vennie:

• Szerver megbízhatósága. Valóban magas színvonalú szakemberekre van szükségünk, akik képesek biztosítani a zökkenőmentes működését. Nem tudok semmilyen, a gyártók által biztosított képzési programról ilyen szakemberek számára. Vannak tanfolyamok a "Szakértő" vizsgára való felkészítéshez, de véleményem szerint ezek nem elegendőek.
• Támogatás. Lásd az előző pontot. A szállítói támogatás igénybevételéhez meg kell vásárolni. Valamiért ez nem gyakori az 1C iparágban. De az SAP-nál szinte kötelező, és úgy tűnik, senkit sem zavar. Vállalati támogatás és egy szakértő személyzet nélkül egyedül maradsz az 1C hibákkal.
• Végül is nem lehet mindent az 1C-vel megcsinálni. Ez egy eszköz, és mint minden eszköznek, ennek is megvannak a maga korlátai. Egy 1C-alapú környezetben nagyon kívánatos, hogy egy rendszerarchitektus ne legyen 1C szakértő.
• A jó 1C programozók nem olcsóbbak, mint más nyelveken írt jó programozók. A rossz programozók felvétele azonban drága, függetlenül attól, hogy milyen nyelven írnak.

Tegyük fel az i-re a pontot

• Az 1C egy gyors alkalmazásfejlesztési (RAD) keretrendszer üzleti célokra, amelyet erre a célra szabtak.
• Egy háromszintű rendszer, amely támogatja a főbb adatbázis-kezelő rendszereket (DBMS), kliens felhasználói felülettel, meglehetősen jó ORM-mel és jelentéskészítéssel.
• Kiterjedt integrációs lehetőségek olyan rendszerekkel, amelyek támogatják az 1C által támogatott képességeket. Ha gépi tanulásra van szüksége, használjon Pythont, és vigye át az eredményeket az 1C-be HTTP vagy RabbitMQ segítségével.
• Nem kell mindent az 1C-ben megcsinálnod; meg kell értened az erősségeit, és azokat a saját előnyödre kell fordítanod.
• Azok a fejlesztők, akik hajlamosak technológiai keretrendszerekkel és kütyükkel babrálni, majd N évente átdolgozni őket egy új motor használatához, unatkoznak az 1C-ben. Minden nagyon konzervatív benne.
• A fejlesztők is unatkoznak, mert a gyártó nagyon kevés figyelmet fordít rájuk. A nyelv unalmas, az IDE gyenge. Modernizációra szorulnak.
• Másrészről azok a fejlesztők, akik nem találnak szórakozást egy másik, általuk élvezett technológia használatában és elsajátításában, rossz fejlesztők. Panaszkodni fognak, és továbblépnek egy másik ökoszisztémába.
• Azok a munkaadók, akik nem engedik meg 1C specialistáiknak, hogy bármit is írjanak Pythonban, rossz munkaadók. Elveszítik a kíváncsi alkalmazottaikat, és helyükre majomkóderek jönnek, akik bár mindenbe beleegyeznek, a vállalati szoftvert a mocsárba rántják. Úgyis újra kell majd írni, szóval talán jobb lett volna egy kicsit korábban befektetni egy kicsit a Pythonba?
• Az 1C egy kereskedelmi vállalat, és kizárólag saját érdekei és célszerűsége alapján valósítja meg a funkciókat. Ezért nem lehet hibáztatni; a vállalkozásoknak a profitra kell gondolniuk; ilyen az élet.
• Az 1C üzleti problémákra kínál megoldásokat, nem pedig Vasya fejlesztő problémáira. Ez a két koncepció összefügg, de a prioritás pontosan az, amit említettem. Amikor Vasya fejlesztő hajlandó lesz fizetni az 1C: ReSharper személyes licencéért, az elég gyorsan megjelenik. A. Orefkov "ReSharper"-e erre bizonyíték. Ha a gyártó támogatná, ahelyett, hogy harcolna ellene, akkor kialakulhatna a fejlesztői szoftverek piaca. Jelenleg másfél szereplő van ezen a piacon, kétes eredményekkel, mindez azért, mert az IDE integráció gyenge, és mindent trükkösen csinálnak.
• A multitasking specialista gyakorlata a múlté lesz. A modern alkalmazások túl terjedelmesek ahhoz, hogy mind a kód, mind az üzleti oldalról megjegyezzük őket. Az 1C szerver is egyre összetettebbé válik, ami lehetetlenné teszi, hogy mindenféle szakértelmet egyetlen alkalmazottban befogadjanak. Ez a szakemberek iránti kereslet növekedéséhez vezethet, ami viszont vonzóbbá teszi az 1C szakmát, és magasabb fizetésekhez vezet. Ha korábban egy három az egyben Vasya dolgozott egy fizetésért, most két Vasyát kell felvenni, és a köztük lévő verseny növelheti az általános képzettségi szintjüket.

Következtetés

Az 1C egy nagyon jó termék. Nem ismerek hasonló termékeket az árkategóriájában. Kérlek, írjátok meg kommentben, ha tudtok róla. Azonban egyre észrevehetőbb a fejlesztők elvesztése az ökoszisztémából, és ez egyfajta "agyvándorlás", akárhonnan is nézzük. Az iparág kétségbeesetten vágyik a modernizációra.
Ha fejlesztő vagy, ne ragadj le az 1C-nél, és ne gondold, hogy minden varázslat más nyelveken. Amíg junior vagy, akár az is lehet. Amint valami nagyobb problémát kell megoldanod, tovább kell keresned a kész megoldásokat, és intenzívebben kell finomítanod azokat. Az építőelemek minőségét tekintve, amelyekből egy megoldást építhetsz, az 1C nagyon-nagyon jó.

És még valami: ha felvett egy 1C specialistát, magabiztosan előléptetheti vezető elemzővé. A feladat, a témakör megértése és a dekompozíciós készségei kiválóak. Biztos vagyok benne, hogy ez pontosan a DDD kötelező használatának köszönhető az 1C fejlesztésben. Arra vannak kiképezve, hogy elsősorban a feladat céljára és a témakörben lévő objektumok közötti kapcsolatokra gondoljanak, miközben technikai háttérrel is rendelkeznek az integrációs technológiák és az adatcsere-formátumok terén.

Légy tudatában annak, hogy nincs tökéletes keretrendszer, és vigyázz magadra.
Minden rendben!

Ui.: Nagyon szépen köszönöm speshurikus a cikk elkészítéséhez nyújtott segítségért.

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.

Van 1C a vállalkozásodban?

• 13,3%Egyáltalán nem.71

• 30,3%Igen, de csak valahol a könyvelési osztályon. A fő rendszerek más platformokon vannak. 162

• 41,4%Igen, a fő üzleti folyamatok rajta futnak221

• 15,0%Az 1C-nek meg kell halnia, a jövő a %technology_name%80-é

534 felhasználó szavazott. 99 felhasználó tartózkodott.

Forrás: will.com