1C - Goed en kwaad. Rangskikking van punte in holivars rondom 1C

Vriende en kollegas, onlangs was daar meer gereeld artikels oor Habré met haat teenoor 1C as 'n ontwikkelingsplatform, en toesprake deur sy verdedigers. Hierdie artikels het een ernstige probleem geïdentifiseer: kritici van 1C kritiseer dit meestal vanuit die posisie van "dit nie bemeester nie", skel probleme wat de facto maklik opgelos kan word, en, inteendeel, raak nie probleme aan wat werklik belangrik is, die moeite werd is nie. bespreek en word nie deur die verkoper opgelos nie. Ek glo dat dit sin maak om 'n nugter en gebalanseerde hersiening van die 1C-platform te doen. Wat dit kan doen, wat dit nie kan doen nie, wat dit moet doen maar nie doen nie, en, vir nagereg, wat dit met 'n knal doen, en jou ontwikkelaars by %technology_name% sal honderd jaar doen en dit weggooi meer as een jaarlikse begroting.

Gevolglik sal jy as bestuurder of argitek 'n duidelike begrip kan kry van watter taak dit vir jou voordelig sal wees om 1C te gebruik, en waar dit met 'n warm strykyster uitgebrand moet word. As 'n ontwikkelaar in die "nie-1C" wêreld, sal jy kan sien wat daar in 1C is wat ophef veroorsaak. En as 'n 1C-ontwikkelaar sal jy jou stelsel met die ekosisteme van ander tale kan vergelyk en jou ligging in die koördinaatstelsel van sagteware-ontwikkeling verstaan.

Onder die snit is daar baie dik aanvalle op 1C, op kritici van 1C, op Java, .NET en in die algemeen... Die waaier is vol, welkom!

About Me

Ek is sedert ongeveer 2004 vertroud met die onderwerp van gesprek. Ek programmeer seker al vandat ek 6 jaar oud was, van die oomblik dat ek 'n boek oor professor Fortran gekry het met strokiesprente oor 'n kat, 'n mossie en 'n ruspe. Ek het die programme wat die kat geskryf het uit die prente in die boek ontleed en uitgevind wat hulle gedoen het. En ja, ek het op daardie stadium nie 'n regte rekenaar gehad nie, maar daar was 'n tekening op die verspreiding van die boek en ek het eerlik op die papierknoppies gedruk en die opdragte ingevoer wat ek op die kat X gespioeneer het.

Dan was daar BK0011 en BASIC op skool, C++ en monteurs op universiteit, toe 1C, en dan soveel ander dinge wat ek te lui is om te onthou. Vir die laaste 15 jaar was ek hoofsaaklik betrokke by 1C, nie net wat kodering betref nie, maar by 1C in die algemeen. Opstel van take, administrasie en devops hier. Vir die laaste 5 jaar was ek besig met sosiaal nuttige aktiwiteite in terme van die ontwikkeling en outomatiseringsinstrumente vir ander 1C-gebruikers, die skryf van artikels en boeke.

Kom ons besluit oor die onderwerp van bespreking

Kom ons definieer eers waaroor ons gaan praat, aangesien die letters "1C" baie dinge kan beteken. In hierdie geval, met die letters "1C" bedoel ons uitsluitlik die ontwikkelingsraamwerk "1C: Enterprise" van die moderne, agtste weergawe. Ons sal nie veel oor die vervaardiger en sy beleid praat nie (maar ons sal 'n bietjie moet doen oor spesifieke toepassings wat met hierdie raamwerk geskryf is). Tegnologie is apart, toepassings aka konfigurasies is apart.

Hoëvlak argitektuur 1C: Onderneming

Dit is nie verniet dat ek die woord "raamwerk" noem nie. Vanuit 'n ontwikkelaar se oogpunt is die 1C-platform juis 'n raamwerk. En jy moet dit presies soos 'n raamwerk hanteer. Dink daaraan as Spring of ASP.NET, uitgevoer deur 'n sekere tyd (JVM of CLR onderskeidelik). Dit gebeur so dat in die wêreld van konvensionele programmering (“nie 1C nie”), die verdeling in raamwerke, virtuele masjiene en spesifieke toepassings natuurlik is, as gevolg van die feit dat hierdie komponente gewoonlik deur verskillende vervaardigers ontwikkel word. In die 1C-wêreld is dit nie gebruiklik om die ontwikkelingsraamwerk en looptyd self uitdruklik te onderskei nie, daarby word spesifieke toepassings wat met die raamwerk geskryf is, ook hoofsaaklik deur 1C self ontwikkel. As gevolg hiervan ontstaan ​​'n mate van verwarring. Daarom, binne die raamwerk van die artikel, sal ons 1C van verskeie kante tegelyk moet oorweeg en dit volgens verskeie koördinaat-asse klassifiseer. En in elke koördinaat-as sal ons 'n graaf bruin stof sit en kyk na die kenmerke, voordele en nadele van die bestaande oplossing.

Standpunte oor 1C

1C vir die koper

Die koper koop 'n outomatiseringstelsel aan waarmee hy vinnig die probleme van die outomatisering van sy eie besigheid kan oplos. 'n Besigheid kan 'n klein stalletjie wees, of dit kan 'n groot beheermaatskappy wees. Dit is duidelik dat die behoeftes van hierdie besighede verskil, maar albei word ondersteun deur 'n enkele platform-kodebasis.

Vir die 1C-koper is dit 'n vinnige tyd-tot-mark. Vinnig. Vinniger as Java, C# of JS. Gemiddeld. Rondom die hospitaal. Dit is duidelik dat 'n besigheidskaartjie-webwerf wat React gebruik, beter sal uitdraai, maar die agterkant van 'n WMS-stelsel sal vinniger op 1C begin.

1C as 'n hulpmiddel

Elke tegnologiese oplossing het limiete van toepaslikheid. 1C is nie 'n algemene doeltaal nie; dit leef nie apart van sy raamwerk nie. Dit is raadsaam om 1C te gebruik wanneer jy nodig het:

• bediener toepassing
• aansoek waar finansies verskyn
• met klaargemaakte UI, ORM, Reporting, XML/JSON/COM/PDF/YourDataTransferingFormat
• met ondersteuning vir agtergrondprosesse en werksgeleenthede
• met rolgebaseerde sekuriteit
• met skrifbare besigheidslogika
• met die vermoë om vinnig 'n prototipe te skep en 'n lae tyd-tot-mark

Jy het nie 1C nodig as jy wil nie:

• Masjienleer
• GPU-berekeninge
• rekenaargrafika
• wiskundige berekeninge
• CAD-stelsel
• seinverwerking (klank, video)
• hoëlaai http-oproepe met honderde duisende rps

1C as 'n vervaardigingsmaatskappy

Dit is die moeite werd om te verstaan ​​wat die besigheid van 1C as 'n sagtewarevervaardiger is. 1C-maatskappy verkoop oplossings vir besigheidsprobleme deur outomatisering. Verskillende besighede, groot of klein, maar dit is wat sy verkoop. Die manier om hierdie doel te bereik is besigheidstoepassings. Vir rekeningkunde, betaalstaatrekeningkunde, ens. Om hierdie aansoeke te skryf, gebruik die maatskappy sy eie besigheidstoepassingsontwikkelingsplatform. Spesiaal aangepas vir algemene take van dieselfde besigheidstoepassings:

• finansiële Rekeningkunde
• maklike aanpassing van besigheidslogika
• wye integrasiemoontlikhede in heterogene IT-landskappe

As vervaardiger glo 1C dat dit die strategie is wat jou in staat stel om met vennote en kliënte in 'n wen-wen-modus te werk. Jy kan hiermee argumenteer, maar dit is ongeveer hoe die maatskappy homself bevorder: klaargemaakte oplossings vir besigheidsprobleme wat vinnig deur vennote aangepas en in enige IT-landskap geïntegreer kan word.

Alle eise of wense vir 1C as 'n raamwerk moet uitsluitlik deur hierdie prisma beskou word. "Ons wil OOP in 1C hê," sê die ontwikkelaars. "Hoeveel sal dit ons kos om OOP op die platform te ondersteun, sal dit ons help om verkope van bokse te verhoog?" sê 1C. Maak sy "prisma" oop om oplossings vir besigheidsprobleme te verkoop:

- Haai, besigheid, wil jy OOP in jou 1C hê?
- Sal dit my help om my probleme op te los?
- Wie weet...
- Dan is dit nie nodig nie

Hierdie benadering kan goed of sleg wees, afhangende van wie daarna kyk, maar dit is net hoe dit is. As u praat oor die feit dat daar geen kenmerk X in 1C is nie, moet u verstaan ​​dat dit nie om 'n rede daar is nie, maar in die konteks van die keuse "implementeringskoste vs winsbedrag".

Tegnologiese klassifikasie

“Trouens, Odinesniks doen hul bes om die beste patrone te gebruik, noukeurig gekies deur sorgsame metodoloë en ontwikkelaars van die 1C-platform.
Wanneer jy jou dom kode vir 'n eenvoudige bestuurde vorm skryf, gebruik jy in werklikheid model-aansig-beheerder с dubbelrigting databinding в drie-laag-data-app-enjin, gegeur hoëvlak objek-verwantskap-kartering op die basis verklarende metadata beskrywingsy eie het platform-onafhanklike navraagtaal, C verklarende data-gedrewe gebruikerskoppelvlak, volledige deursigtige serialisering en domein-georiënteerde programtaal.

Waar 1C-ontwikkelaars van hul Westerse kollegas verskil, is in PR. Hulle hou daarvan om enige snert ’n groot naam te gee en daarmee rond te hardloop soos ’n vuil sak.”
A. Orefkov

Die 1C-platform het 'n klassieke 3-vlak argitektuur, in die middel daarvan is die toepassingsbediener (of die nabootsing daarvan vir min geld vir klein winkeliers). Óf MS SQL of Postgres word as 'n DBBS gebruik. Daar is ook ondersteuning vir Oracle en IBM DB2, maar dit is nogal esoteries, niemand weet wat sal gebeur as jy 1C op hierdie databasisse onder medium en hoë las implementeer nie. Ek glo dat 1C self dit nie weet nie.

Die kliëntdeel is óf 'n dun kliënt wat op die gebruiker se masjien geïnstalleer is óf 'n webkliënt. Die belangrikste kenmerk is dat programmeerders nie 2 verskillende kodes skryf nie, hulle skryf een toepassing, in een taal, en jy kan dit in die blaaier vertoon as daar 'n begeerte of behoefte is. Wie wou 'n ware volledige stapel en 'n enkele taal vir die voor- en agterkant, node.js, hê? Hulle het nooit reggekry om presies dieselfde ding te doen tot die einde toe nie. Daar is 'n regte volstapel, maar jy sal dit in 1C moet skryf. Die ironie van die noodlot, sulke dinge :)

Die wolk SaaS-oplossing 1C:Fresh werk ook in blaaiermodus, waarin jy nie 1C kan koop nie, maar ’n klein databasis kan huur en tred hou met shawarma-verkope daar. Net in die blaaier, sonder om iets te installeer of op te stel.

Daarbenewens is daar 'n nalatenskapkliënt, wat in 1C 'n "gereelde toepassing" genoem word. Nalatenskap is nalatenskap, welkom in die wêreld van toepassings in 2002, maar ons praat steeds oor die huidige toestand van die ekosisteem.

Die 1C-bedienerdeel ondersteun groepering en skale deur nuwe masjiene by die groepering te voeg. Heelwat kopieë is hier gebreek en daar sal 'n aparte afdeling in die artikel hieroor wees. Kortom, dit is nie heeltemal dieselfde as om 'n paar presies dieselfde gevalle agter HAProxy by te voeg nie.

Die toepassingsontwikkelingsraamwerk gebruik sy eie programmeertaal, wat min of meer lyk soos 'n effens verbeterde VB6 wat in Russies vertaal is. Vir mense wat alles Russies haat, wat nie glo dat "as" as "as" vertaal word nie, word die tweede sintaksisopsie aangebied. Dié. As jy wil, kan jy dit in 1C skryf op so 'n manier dat dit nie van VB onderskei kan word nie.

Hierdie einste programmeertaal is die hoofrede vir die haat van 1C-byname teenoor hul platform. Kom ons erken dit, nie sonder rede nie. Die taal is so eenvoudig as moontlik bedink, ontwerp om die mantra "ONTWIKKELING, ONTWIKKELAAR" op 'n skaal ten minste in die GOS te vervul. Die kommersiële wese van so 'n oplossing is na my mening duidelik sigbaar: meer ontwikkelaars, groter markdekking. Dit het waar geword, volgens verskeie skattings van 45% tot 95%. Ek sal dadelik sê dat skryf in die taal wat jy dink regtig makliker is. En ek ken nogal baie programmeertale.

Kom ons begin by die taal.

1C programmeertaal

Terselfdertyd die sterk en swak punt van die stelsel. Bied maklike toegang en leesbaarheid. Aan die ander kant is dit nie opgedateer sedert die vrystelling van weergawe 8 in 2002 nie en is dit moreel verouderd. Iemand sal sê "die grootste nadeel is dat daar geen OOP is nie" en hulle sal verkeerd wees. Eerstens hou die PLO nie net van Nuraliev nie, maar ook van Torvalds. En tweedens, OOP bestaan ​​steeds.

Vanuit die ontwikkelaar se oogpunt het hy 'n raamwerk met basisklasse wat op die DBBS vertoon word, tot sy beskikking. Die ontwikkelaar kan die basisklas "Directory" neem en die "Clients"-gids daarvan erf. Dit kan nuwe klasvelde daarby voeg, byvoorbeeld INN en Address, en ook, indien nodig, kan dit metodes van die basisklas, byvoorbeeld die OnWrite/AtRecord-metode, ignoreer (oorskryf).

Die raamwerk is so ontwerp dat dieper oorerwing selde nodig is, en die beperking in OOP maak na my mening sin. 1C fokus op domeingedrewe ontwikkeling en laat jou eerstens dink oor die vakgebied van die oplossing wat ontwikkel word, en dit is goed. Daar is nie net geen versoeking nie, maar ook nie nodig om 10 verskillende DTO's en ViewModels te skryf net om 'n paar data van die domein iewers te wys nie. Die 1C-ontwikkelaar werk altyd met een entiteit, sonder om die konteks van persepsie te bemoei met 'n dosyn klasse met soortgelyke name, wat dieselfde entiteit verteenwoordig, maar van 'n ander kant. Enige .NET-toepassing sal byvoorbeeld noodwendig vyf of twee ViewModels en DTO's bevat vir serialisering in JSON en data-oordrag van kliënt na bediener. En ongeveer 10-15% van jou toepassingskode sal bestee word aan die oordrag van data van een klas na 'n ander met behulp van penne of krukke soos AutoMapper. Hierdie kode moet geskryf word en programmeerders moet betaal word om dit te skep en in stand te hou.

Dit blyk dat die 1C-taal moeilik is om te ontwikkel sonder om dit tot die vlak van hoofstroomtale te bemoeilik, en sodoende die voordeel van eenvoud verloor. Wat is die verkoper se taak wat in wese opgelos word: om 'n standaardoplossing uit te reik wat enige student wat op straat betrap word, kan aanpas met die vereiste vlak van kwaliteit (d.w.s. 'n saak wat van 'n stalletjie na 'n groot fabriek dek, word voltooi). As jy 'n stalletjie is, neem 'n student as jy 'n fabriek is, neem 'n guru van jou implementeringsvennoot. Die feit dat implementeringsvennote studente teen die prys van 'n guru verkoop, is nie 'n probleem met die raamwerk nie. Argitektonies moet die raamwerk albei se probleme oplos, die kode van standaardkonfigurasies (wat ons aan besighede verkoop het met die belofte van aanpassing) moet deur 'n student verstaan ​​kan word, en 'n ghoeroe moet kan verstaan ​​wat jy ook al wil hê.

Wat myns insiens werklik in die taal ontbreek, wat jou dwing om meer te skryf as wat jy kan, is wat tyd mors wat deur die kliënt betaal word.

• Moontlikheid om op die vlak te tik, byvoorbeeld TypeScript (as gevolg hiervan, meer ontwikkelde kode-analise-instrumente in die IDE, herfaktorering, minder aanstootlike jambs)
  Beskikbaarheid van funksies as eersteklas-objekte. 'n Effens meer komplekse konsep, maar die hoeveelheid tipiese boilerplate-kode kan aansienlik verminder word. Die student se begrip van die kode, IMHO, sou selfs toeneem as gevolg van die vermindering in volume
• Universele versameling letters, initialiseerders. Dieselfde ding - die vermindering van die hoeveelheid kode wat geskryf moet word en/of met jou oë gekyk moet word. Die vul van versamelings neem meer as 9000% van 1C-programmeringstyd in beslag. Om dit sonder sintaktiese suiker te skryf, is lank, duur en vatbaar vir foute. Oor die algemeen oorskry die hoeveelheid LOC in 1C-oplossings alle denkbare perke in vergelyking met beskikbare oop raamwerke en, in die algemeen, al jou ondernemings-Java's saam. Die taal is verbose, en dit ontaard in die hoeveelheid data, geheue, IDE-remme, tyd, geld ...
• uiteindelik konstruksies Ek het 'n hipotese dat hierdie konstruksie ontbreek as gevolg van die feit dat hulle nie 'n suksesvolle vertaling daarvan in Russies gevind het nie :)
• Eie datatipes (sonder OOP), analoë van Tipe van VB6. Dit sal jou toelaat om nie strukture te tik deur opmerkings in die BSP en towermetodes wat hierdie strukture konstrueer nie. Ons kry: minder kode, 'n wenk deur 'n kolletjie, vinniger oplossing vir die probleem, minder foute as gevolg van tikfoute en ontbrekende eienskappe van strukture. Nou berus die tik van gebruikerstrukture geheel en al by die ontwikkelingspan van die Standard Subsystem Library, wat, tot sy eer, sorgvuldig kommentaar skryf oor die verwagte eienskappe van die geslaagde parameterstrukture.
• Geen suiker wanneer u met asynchrone oproepe op die webkliënt werk nie. terugbel-hel in die vorm van ProcessingNotifications is 'n tydelike kruk wat veroorsaak word deur 'n skielike verandering in die API van die hoofblaaiers, maar jy kan nie heeltyd so leef nie, die voordeel van "studente-begrip" van asynchrone kode gaan verlore meer en meer. Voeg geen ondersteuning vir hierdie paradigma in die hoof-IDE by nie en dinge word nog erger.

Dit is een van die dringende probleme, dit is duidelik dat die lys baie groter kan wees, maar ons moet nie vergeet dat dit steeds nie 'n algemene doeltaal is nie, dit vereis nie multithreading, lambda-funksies, toegang tot die GPU en vinnig nie swaaipuntberekeninge. Dit is 'n besigheidslogika-skriptaal.

'n Programmeerder wat al baie met hierdie taal gewerk het, kyk na js of c#, raak verveeld binne die raamwerk van hierdie taal. Dit is 'n feit. Hy het ontwikkeling nodig. Aan die ander kant van die skaal vir die verkoper is die koste van die implementering van die gespesifiseerde kenmerke teenoor die toename in inkomste na die implementering daarvan. Hier het ek geen inligting oor wat tans swaarder weeg in die oë van die maatskappy nie.

Ontwikkelingsomgewing

Hier gaan dinge ook nie vlot nie. Daar is twee ontwikkelingsomgewings. Die eerste is die Configurator wat by die aflewering ingesluit is. Die tweede is die Enterprise Development Tools-omgewing, of kortweg EDT, wat op die basis van Eclipse ontwikkel is.

Die konfigurator bied 'n volledige reeks ontwikkelingstake, ondersteun alle kenmerke en is die belangrikste omgewing op die mark. Dit is ook moreel uitgedien en ontwikkel nie, volgens gerugte nie – weens die hoeveelheid tegniese skuld in homself. Die situasie kan verbeter word deur 'n interne API (in die vorm van vriendskap met Sneeuman A. Orefkova of op 'n onafhanklike basis), maar dit is nie die geval nie. Die praktyk het getoon dat die gemeenskap sy eie kenmerke in die IDE sal skryf, solank die verkoper nie inmeng nie. Maar ons het wat ons het. Die konfigureerder was puik in 2004-2005, herinner baie aan Visual Studio van daardie tye, op sommige plekke was dit selfs koeler, maar dit het vasgehaak in daardie tye.

Daarbenewens het die volume van die gemiddelde standaardoplossing sedertdien verskeie kere gegroei, en vandag kan die IDE eenvoudig nie die hoeveelheid kode hanteer waarmee dit gevoer word nie. Bruikbaarheid en herfaktoreringsvermoëns is nie eens nul nie, hulle is in die rooi. Dit alles voeg nie entoesiasme by die ontwikkelaars nie en hulle droom daarvan om na ander ekosisteme te beweeg en daar voort te gaan om kak te kodeer, maar in 'n aangename omgewing wat nie in jou gesig spoeg met sy gedrag nie.

As alternatief word 'n IDE van nuuts af geskryf, gebou op Eclipse, aangebied. Daar, die bronne, soos in enige ander sagteware, leef in die vorm van tekslêers, word gestoor in GIT, trek versoek takke, dit alles. Aan die nadeel, dit het vir baie jare nie beta-status verlaat nie, hoewel dit met elke vrystelling beter word. Ek sal nie skryf oor die nadele van EDT nie, vandag is dit 'n minus, môre is dit 'n vaste kenmerk. Die relevansie van so 'n beskrywing sal vinnig verdwyn. Vandag is dit moontlik om in EDT te ontwikkel, maar dit is ongewoon dat jy voorbereid moet wees op 'n sekere aantal IDE-foute.

As jy na die situasie kyk deur die voorgenoemde "1C-prisma", kry jy iets soos hierdie: die vrystelling van die nuwe IDE verhoog nie die verkope van bokse nie, maar die uitvloei van ONTWIKKELAARS kan verminder word. Dit is moeilik om te sê wat op die ekosisteem wag in terme van ontwikkelaargerief, maar Microsoft het reeds mobiele ontwikkelaars opgefok deur hul dienste te laat aan te bied.

Ontwikkelingsbestuur

Alles hier is aansienlik beter as om kode te skryf, veral onlangs, toe die pogings van die gemeenskap die probleme van administrasie-outomatisering aan die lig gebring het, prototipes geloods het wat vra om die 1C-bewaarplek in die asblik te gooi en die gebruik van git, vinnige blaam, kode-hersiening , statiese analise, outo-ontplooiing en ens. Baie kenmerke is by die platform gevoeg wat die outomatiseringsvlak van ontwikkelingstake verhoog. Al hierdie kenmerke is egter slegs en eksklusief bygevoeg vir die ontwikkeling van ons eie groot produkte, toe dit duidelik geword het dat ons nie sonder outomatisering kan klaarkom nie. Daar was outomatiese samesmeltings, drierigtingvergelyking met KDiff en dit alles. Op Github bekendgestel gitconverter, wat eerlikwaar ideologies weggesleep is van die projek gitsync, maar aangepas om by die prosesse van die verkopermaatskappy te pas. Danksy die hardnekkige ouens van oopbron het ontwikkelingsoutomatisering in 1C van die grond af gekom. 'n Oop API vir die konfigureerder, IMHO, sal ook die morele agterstand van die hoof-IDE verskuif.

Vandag, stoor 1C-bronne in git met commits gekoppel aan kwessies in Jira, resensies in Crucible, drukknoppie van Jenkins en Allure verslae oor kodetoetsing in 1C en selfs statiese analise in SonarQube - dit is ver van nuus, maar eerder die hoofstroom in maatskappye waar daar baie 1C-ontwikkeling is.

administrasie

Hier is baie om te sê. Eerstens is dit natuurlik 'n bediener (1C-bedienerkluster). 'n Wonderlike ding, maar as gevolg van die feit dat dit 'n heeltemal swart boks is, gedokumenteer in voldoende detail, maar op 'n spesifieke manier - die bemeestering van die bekendstelling van ononderbroke werking in hoëladingsmodus op verskeie bedieners is die lot van 'n paar uitgesoekte wat 'n medalje met die inskripsie “Deskundige in Tegnologiese Aangeleenthede”. Dit is opmerklik dat die administrasie van 'n 1C-bediener in beginsel nie verskil van die administrasie van enige ander bediener nie. Dit is 'n netwerk-gebaseerde, multi-draad toepassing wat geheue, SVE en skyf hulpbronne verbruik. Bied ruim geleenthede vir telemetrie-insameling en diagnostiek.

Die probleem hier is dat die verkoper niks spesiaals bied in terme van klaargemaakte oplossings vir hierdie einste diagnostiese nie. Ja, daar is 1C: Instrumentation and Control Center, hulle is selfs redelik goed, maar hulle is baie duur en nie almal het dit nie. Daar is 'n aantal ontwikkelings in die gemeenskap om Grafana, Zabbix, ELK en ander dinge vanaf die standaard administrasiestel te verbind, maar daar is geen enkele oplossing wat die meerderheid sal pas nie. Die taak wag op sy held. En as jy 'n besigheid is wat beplan om op 'n 1C-groepering te begin, het jy 'n Deskundige nodig. Jou eie binne of van buite, maar jy het dit nodig. Dit is normaal dat daar 'n aparte rol is met bevoegdhede vir bedienerbedryf, nie elke 1C-gebruiker behoort dit te weet nie, jy moet net verstaan ​​dat so 'n rol nodig is. Kom ons neem SAP byvoorbeeld. Daar sal 'n programmeerder heel waarskynlik nie eers uit sy stoel opstaan ​​as hy gevra word om iets op die toepassingsbediener te konfigureer nie. Hy is dalk net dom en hy sal nie skaam wees nie. In die SAP-metodologie is daar 'n aparte werknemerrol hiervoor. Om een ​​of ander rede word daar in die 1C-bedryf geglo dat dit in een werknemer gekombineer moet word vir dieselfde salaris. Dit is 'n dwaling.

Nadele van 1C-bediener

Daar is presies een minus - betroubaarheid. Of, as jy verkies, onvoorspelbaarheid. Skielike vreemde gedrag van die bediener het reeds die praatjie van die dorp geword. 'n Universele middel - om die bediener te stop en alle kas skoon te maak - word selfs in die deskundige se handboek beskryf, en selfs 'n bondelboek word aanbeveel wat dit doen. As jou 1C-stelsel iets begin doen wat dit nie eers teoreties behoort te doen nie, is dit tyd om die sessiedatakas skoon te maak. Volgens my skatting is daar net drie mense in die hele land wat weet hoe om 'n 1C-bediener sonder hierdie prosedure te bedryf en hulle deel nie geheime nie, want... hulle leef hiervan. Miskien is hul geheim dat hulle sessiedata skoonmaak, maar hulle vertel niemand daarvan nie, ou.

Andersins is die 1C-bediener dieselfde toepassing as enige ander en word dit op baie dieselfde manier toegedien, deur die dokumentasie te lees en aan die tamboeryn te klop.

Docker

Die bruikbaarheid van die gebruik van 'n 1C-bediener in produksie is nog nie bewys nie. Die bediener word nie gegroepeer deur bloot nodusse agter die balanseerder by te voeg nie, wat die voordele van produksiehouerisering tot 'n minimum verminder, en die praktyk van suksesvolle werking in houers in hoëladingsmodus is nie vasgestel nie. Gevolglik gebruik slegs ontwikkelaars Docker+1C om toetsomgewings op te stel. Daar is dit baie nuttig, toegepas, laat jou toe om met moderne tegnologieë te speel en 'n breek te neem van die moedeloosheid van die konfigurator.

Kommersiële komponent

Vanuit 'n beleggingsoogpunt stel 1C jou in staat om die probleem op te los om sake-idees vinnig te loods as gevolg van die wye vermoëns van toepassingsklasse. 1C uit die boks gee baie ordentlike Verslaggewing, integrasie met enigiets, webkliënt, mobiele kliënt, mobiele toepassing, ondersteuning vir verskeie DBBS'e, insluitend. gratis, kruis-platform beide bediener en geïnstalleerde kliënt dele. Ja, die UI van toepassings sal geel wees, soms is dit 'n minus, maar nie altyd nie.
Deur 1C te kies, kry 'n besigheid 'n stel sagteware-oplossings wat hulle in staat stel om 'n baie wye reeks toepassings te bou, asook baie ontwikkelaars op die mark wat minder geld wil hê as Javaiste en terselfdertyd vinniger resultate lewer.

Byvoorbeeld, die taak om 'n PDF-faktuur aan 'n kliënt te stuur, kan in 'n uur se studentewerk opgelos word. Dieselfde probleem in .NET kan opgelos word deur 'n eie biblioteek te koop, of 'n paar dae of weke se kodering deur 'n streng, bebaarde ontwikkelaar. Soms, albei gelyktydig. En ja, ek het net gepraat van PDF-generering. Ons het nog nie gesê waar hierdie rekening eens vandaan sal kom nie. Die webfrontender moet 'n vorm skep waar die operateur die data sal invoer, die backender sal dto-modelle moet skep vir die oordrag van JSON, modelle om in die databasis te stoor, die struktuur van die databasis self, migrasie daarheen, die vorming van 'n grafiese vertoon van hierdie einste rekening, en eers dan - PDF. Op 1C word die hele taak, van nuuts af, in presies een uur voltooi.

'n Volwaardige rekeningkundige stelsel vir 'n klein stalletjie met een besigheidsproses gekoop/verkoop word in 3 uur gedoen. Met verkoopsverslagdoening, boekhouding van goedere teen koop- en verkooppryse, opgedeel volgens pakhuis, toegangsregtebeheer, webkliënt en mobiele toepassing. . Goed, ek het vergeet van die aansoek, met die aansoek nie oor 3 uur nie, in ses.

Hoe lank sal hierdie taak 'n .NET-ontwikkelaar neem van die installering van visuele ateljee op 'n skoon rekenaar om dit aan die kliënt te demonstreer? Wat van die koste van ontwikkeling? Dieselfde ding.

Sterkpunte van 1C as 'n platform

1C is sterk nie omdat daar iets spesifiek daaraan is wat die beste in die wêreld is nie. Inteendeel, in elke individuele substelsel kan jy 'n meer interessante analoog in die wêreld se sagteware vind. Op grond van 'n kombinasie van faktore sien ek egter nie 'n platform soortgelyk aan 1C nie. Dit is waar kommersiële sukses lê. Die voordele van die platform is daardeur versprei en is die duidelikste sigbaar as jy sien hoe dit in ander platforms gedoen word. Basies is dit NIE eers kenmerke nie, maar inteendeel – 'n verwerping van kenmerke ten gunste van een spesifieke paradigma. 'n Paar voorbeelde:

1. Unicode. Wat de hel kan eenvoudiger wees? Dit is nie nodig om enkelgreep ASCII-enkoderings in 2019 te gebruik nie (behalwe vir integrasie met antieke erfenisse). Nooit nie. Maar nee. In elk geval, iemand in een of ander tabel gebruik 'n enkelgreep-varchar en die toepassing sal probleme met enkoderings hê. In 2015 het gitlab se LDAP-magtiging misluk as gevolg van verkeerde werk met enkoderings, werk JetBrains IDE steeds nie oral met Cyrillies in lêername nie. 1C bied 'n hoë-gehalte isolasie van toepassing kode van die databasis laag. Daar is dit onmoontlik om tabelle op 'n lae vlak te tik en jambes van onbevoegde juniors op databasisvlak is onmoontlik daar. Ja, daar kan ander probleme met onbevoegde juniors wees, maar die verskeidenheid probleme is baie kleiner. Nou sal jy vir my sê dat jou toepassing korrek ontwerp is en die databasistoegangslaag is geïsoleer soos dit moet wees. Kyk weer na jou korporatiewe pasgemaakte Java-toepassing. Noukeurig en eerlik. Pla jou gewete jou? Dan is ek bly vir jou.
2. Nommering van dokumente/naslaanboeke. In 1C is dit beslis nie die mees buigsame en nie die beste nie. Maar wat hulle doen in banksagteware en in selfgeskrewe rekeningstelsels - wel, dit is net duisternis. Of identiteit sal vasgesteek word (en dan “o, hoekom het ons gate”), of inteendeel, hulle sal 'n kragopwekker maak wat met sluiting op die DBMS-vlak werk (en sal 'n bottelnek word). Trouens, dit is nogal moeilik om hierdie oënskynlik eenvoudige taak te doen - 'n end-tot-end opteler van entiteite, met 'n uniekheidsafdeling gebaseer op 'n sekere stel sleutels, voorvoegsel, sodat dit nie die databasis blokkeer tydens parallelle data-invoer .
3. Identifiseerders van rekords in die databasis. 1C het 'n sterk besluit geneem - alle skakel identifiseerders is absoluut sinteties en dit is dit. En daar is geen probleme met verspreide databasisse en uitruilings nie. Ontwikkelaars van ander stelsels skep hardnekkig iets soos identiteit (dit is korter!), sleep hulle na die GUI totdat dit tyd is om verskeie verwante gevalle te skep (en dan sal hulle ontdek word). Het jy dit nie? Eerlik?
4. Lyste. 1C het redelik suksesvolle meganismes om deur (groot) lyste te blaai en daardeur te navigeer. Laat ek dadelik 'n bespreking maak - met die korrekte gebruik van die meganisme! Oor die algemeen is die onderwerp nogal onaangenaam, dit kan nie ideaal opgelos word nie: dit is óf intuïtief en eenvoudig (maar die risiko van groot rekordstelle op die kliënt), óf blaai is van een of ander kromheid. Diegene wat blaai doen, doen dit dikwels skeef. Diegene wat 'n eerlike skuifbalk maak, voeg 'n databasis, 'n kanaal en 'n kliënt by.
5. Bestuurde vorms. Ongetwyfeld, in die webkliënt werk die koppelvlak nie perfek nie. Maar dit werk. Maar vir baie ander rekeningkundige en bankstelsels is die skep van 'n afgeleë werkplek 'n ondernemingsvlakprojek. Vrywaring: gelukkig vir diegene wat dit oorspronklik op die web gemaak het, sal dit nie affekteer nie.
6. Mobiele toepassing. Onlangs kan jy ook mobiele toepassings skryf terwyl jy in dieselfde ekosisteem is. Dit is 'n bietjie meer ingewikkeld hier as met 'n webkliënt, die besonderhede van toestelle dwing jou om spesifiek daarvoor te skryf, maar jy huur nietemin nie 'n aparte span mobiele ontwikkelaars nie. As jy 'n toepassing nodig het vir die interne behoeftes van 'n maatskappy (wanneer 'n mobiele oplossing vir 'n korporatiewe probleem belangriker is as 'n geel UI-ontwerp), gebruik jy eenvoudig dieselfde platform uit die boks.
7. Verslagdoening. Met hierdie woord bedoel ek nie 'n BI-stelsel met groot data en 'n vertraging op die ETL-proses nie. Dit verwys na operasionele personeelverslae wat jou toelaat om die stand van rekeningkunde hier en nou te assesseer. Saldo's, onderlinge skikkings, hergradering, ens. 1C kom uit die boks met 'n verslagdoeningstelsel met buigsame instellings vir groeperings, filters en visualisering aan die gebruikerskant. Ja, daar is koeler analoë op die mark. Maar nie binne die raamwerk van 'n alles-in-een-oplossing nie en teen 'n prys wat soms hoër is as 'n alles-in-een-oplossing. En meer dikwels is dit selfs andersom: slegs verslagdoening, maar duurder as die hele platform, en slegter in kwaliteit.
8. Drukbare vorms. Wel, gebruik .NET om die probleem op te los om salarisstrokies in PDF per e-pos aan werknemers te stuur. En nou die taak om fakture te druk. Wat van die stoor van hul kopieë in dieselfde PDF? Vir 1C-bynaam is die uitvoer van enige uitleg na PDF +1 reël kode. Dit beteken + 40 sekondes werkstyd, in plaas van dae of weke in 'n ander taal. Gedrukte vormuitlegte in 1C is ongelooflik maklik om te ontwikkel en kragtig genoeg om met betaalde eweknieë mee te ding. Ja, waarskynlik, daar is nie baie interaktiewe geleenthede in 1C-sigbladdokumente nie, jy kan nie vinnig 'n 3D-diagram met skaal met OpenGL kry nie. Maar is dit regtig nodig?

Hierdie is slegs 'n handjievol voorbeelde waar die beperking van funksionaliteit of die implementering van kompromieë 'n belangrike argitektoniese voordeel in die toekoms blyk te wees. Selfs 'n kompromie of nie die mees doeltreffende opsie nie - dit is reeds in die boks en word as vanselfsprekend aanvaar. Die onafhanklike implementering daarvan sal óf onmoontlik wees (omdat sulke besluite aan die begin van die projek geneem moet word, en daar is nie tyd daarvoor nie, en daar is geen argitek nie), óf verskeie duur iterasies. In elk van die punte wat gelys is (en dit is nie 'n volledige lys van argitektoniese oplossings nie), kan jy opskroef en beperkings instel wat skaal blokkeer. In elk geval, jy, as 'n sakeman, moet seker maak dat jou programmeerders, wanneer jy 'n "stelsel van nuuts af" maak, reguit hande het en subtiele stelselkwessies dadelik goed sal doen.

Ja, soos in enige ander komplekse stelsel, het 1C self ook oplossings wat skaal in sekere aspekte blokkeer. Ek herhaal egter, op grond van 'n kombinasie van faktore, die koste van eienaarskap en die aantal probleme wat reeds vooraf opgelos is, sien ek nie 'n waardige mededinger op die mark nie. Vir dieselfde prys kry jy 'n finansiële toepassingsraamwerk, 'n gegroepeerde gebalanseerde bediener, met 'n UI en webkoppelvlak, met 'n mobiele toepassing, met verslagdoening, integrasie en 'n klomp ander dinge. In die Java-wêreld huur jy 'n front-end en back-end span, ontfout laevlak skole van tuisgeskrewe bedienerkode en betaal afsonderlik vir 2 mobiele toepassings vir 2 mobiele bedryfstelsels.

Ek sê nie dat 1C alle gevalle sal oplos nie, maar vir 'n interne korporatiewe toepassing, wanneer dit nie nodig is om die UI te merk nie, wat is nog nodig?

'n Lepel teer

Jy het waarskynlik die indruk gekry dat 1C die wêreld sal red en dat alle ander maniere om korporatiewe stelsels te skryf verkeerd is. Dit is glad nie so nie. Vanuit 'n sakeman se oogpunt, as jy 1C kies, moet jy benewens vinnige tyd-tot-mark die volgende nadele in ag neem:

• Bediener betroubaarheid. Werklike hoëgehalte spesialiste word vereis wat die ononderbroke werking daarvan kan verseker. Ek is nie bewus van 'n klaargemaakte opleidingsprogram vir sulke spesialiste van die verkoper nie. Daar is kursusse om voor te berei vir die Deskundige-eksamen, maar dit is na my mening nie genoeg nie.
• Ondersteuning. Sien vorige punt. Om ondersteuning van die verkoper te hê, moet jy dit koop. Om een ​​of ander rede word dit nie in die 1C-bedryf aanvaar nie. En met SAP is dit amper 'n moet-aankoop en pla dit niemand nie. Sonder korporatiewe ondersteuning en sonder 'n deskundige op personeel, kan jy alleen gelaat word met 1C-foute.
• Tog kan jy nie absoluut alles met 1C doen nie. Dit is 'n instrument en soos elke instrument het dit limiete van toepaslikheid. In die 1C-landskap is dit baie wenslik om 'n "nie-1C"-stelselargitek te hê.
• Goeie 1C-byname is nie goedkoper as goeie programmeerders in ander tale nie. Alhoewel slegte programmeerders duur is om te huur, ongeag die taal waarin hulle skryf.

Kom ons stippel die kolletjies

• 1C is 'n vinnige toepassingsontwikkeling (RAD) raamwerk vir besigheid en is aangepas hiervoor.
• Drievlakskakel met ondersteuning vir groot DBBS'e, kliënt-UI, 'n baie goeie ORM en verslagdoening
• Wye moontlikhede vir integrasie met stelsels wat kan doen wat 1C nie kan nie. As jy masjienleer wil hê, neem Python en stuur die resultaat na 1C via http of RabbitMQ
• Jy hoef nie daarna te streef om alles met 1C te doen nie, jy moet die sterk punte daarvan verstaan ​​en dit vir jou eie doeleindes gebruik
• Ontwikkelaars wat daarop aandring om in tegnologiese raamwerktoestelle te delf en elke N jaar na 'n nuwe enjin te herontwerp, is verveeld met 1C. Alles is baie konserwatief daar.
• Ontwikkelaars is ook verveeld omdat daar baie min kommer vir hulle van die vervaardiger is. Vervelige taal, swak IDE. Hulle benodig modernisering.
• Aan die ander kant, ontwikkelaars wat nie pret kan vind deur 'n ander tegnologie te gebruik en te leer wat hulle geniet nie, is slegte ontwikkelaars. Hulle sal kerm en na 'n ander ekosisteem beweeg.
• Werkgewers wat nie toelaat dat hul 1C-byname iets in Python skryf nie, is slegte werkgewers. Hulle sal werknemers met nuuskierige verstand verloor, en in hul plek sal aapkodeerders kom wat, terwyl hulle met alles saamstem, korporatiewe sagteware in die moeras sal sleep. Dit sal nog oorgeskryf moet word, so miskien sal dit beter wees om 'n bietjie vroeër 'n bietjie in Python te belê?
• 1C is 'n kommersiële maatskappy en implementeer kenmerke uitsluitlik gebaseer op sy eie belange en doeltreffendheid. Jy kan haar nie hiervoor blameer nie, besigheid moet aan wins dink, dis die lewe
• 1C maak geld deur oplossings vir besigheidsprobleme te verkoop, nie vir Vasya se ontwikkelaarprobleme nie. Hierdie twee konsepte korreleer, maar die prioriteit is presies wat ek gesê het. Wanneer ontwikkelaar Vasya gereed is om te betaal vir 'n persoonlike lisensie vir 1C: Resharper, sal dit redelik vinnig verskyn, "Resharper" deur A. Orefkova is 'n bewys hiervan. As die verkoper dit ondersteun en nie daarteen veg nie, sal 'n mark vir sagteware vir ontwikkelaars verskyn. Nou is daar een en 'n half spelers in hierdie mark met twyfelagtige resultate, en dit alles omdat die integrasie met die IDE negatief is en alles op krukke gedoen word.
• Die praktyk van 'n multi-masjien operateur sal in die vergetelheid verdwyn. Moderne toepassings is te groot om beide van die kode-kant en van die besigheidsgebruik-kant te onthou. Die 1C-bediener word ook meer kompleks dit sal onmoontlik wees om alle soorte kundigheid in een werknemer te hou. Dit behoort 'n aanvraag na spesialiste te behels, wat die aantreklikheid van die 1C-professie en 'n verhoging in salarisse beteken. As Vasya voorheen drie-in-een vir een salaris gewerk het, moet jy nou twee Vasyas aanstel en mededinging tussen Vasyas kan die algehele groei van hul vlak aanspoor.

Gevolgtrekking

1C is 'n baie waardige produk. In my prysklas ken ek glad nie enige analoë nie, skryf in die kommentaar as daar enige is. Die uitvloei van ontwikkelaars uit die ekosisteem word egter al hoe meer opvallend, en dit is 'n "brein drein", maak nie saak hoe jy daarna kyk nie. Die bedryf is honger vir modernisering.
As jy 'n ontwikkelaar is, moenie vashou aan 1C nie en moenie dink dat alles magies is in ander tale nie. Terwyl jy 'n junior is, miskien. Sodra iets groters opgelos moet word, sal daar langer na klaargemaakte oplossings gesoek en meer intensief afgehandel moet word. In terme van die kwaliteit van die “blokke” waaruit 'n oplossing gebou kan word, is 1C baie, baie goed.

En nog een ding - as 'n 1C-bynaam na jou toe kom om te huur, dan kan die 1C-bynaam veilig in die posisie van hoofontleders aangestel word. Hulle begrip van die taak, vakgebied en ontbindingsvaardighede is uitstekend. Ek is seker dat dit juis te wyte is aan die gedwonge gebruik van DDD in 1C-ontwikkeling. 'n Persoon word opgelei om eerstens na te dink oor die betekenis van 'n taak, oor die verbande tussen voorwerpe van die vakgebied, en het terselfdertyd 'n tegniese agtergrond in integrasietegnologieë en data-uitruilformate.

Wees bewus daarvan dat die ideale raamwerk nie bestaan ​​nie en sorg vir jouself.
Goed vir almal!

PS: baie dankie speshuries vir hulp met die voorbereiding van die artikel.

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.

Het jy 1C in jou onderneming?

• 13,3%Glad nie.71

• 30,3%Daar is, maar net in die rekeningkundige afdeling iewers. Kernstelsels op ander platforms162

• 41,4%Ja, die hoofbesigheidsprosesse werk daarop221

• 15,0%1C moet sterf, die toekoms behoort aan %technology_name%80

534 gebruikers het gestem. 99 gebruikers het buite stemming gebly.

Bron: will.com