Freonen en kollega's, koartlyn binne d'r faker artikels west oer Habré mei haat tsjin 1C as ûntwikkelingsplatfoarm, en taspraken fan har ferdigeners. Dizze artikels identifisearre ien serieus probleem: meastentiids kritisearje kritisy fan 1C it út 'e posysje fan "it net behearskje", skele problemen dy't de facto maklik oplost wurde, en, krekt oarsom, net oanreitsje op problemen dy't echt wichtich binne, wurdich besprekken en wurde net oplost troch de ferkeaper. Ik leau dat it sin is om in sobere en lykwichtige resinsje fan it 1C-platfoarm te fieren. Wat it kin dwaan, wat it net kin, wat it moat dwaan, mar net docht, en, as dessert, wat it docht mei in knal, en jo ûntwikkelders by %technology_name% sille hûndert jier dwaan, it fuortsmite mear as ien jierbudzjet.
As resultaat kinne jo, as manager of arsjitekt, in dúdlik begryp krije fan hokker taak it foardielich wêze sil foar jo om 1C te brûken, en wêr't it mei in waarm izer útbaarnd wurde moat. As ûntwikkelder yn 'e "non-1C" wrâld kinne jo sjen wat d'r is yn 1C dat opheft makket. En as 1C-ûntwikkelder sille jo jo systeem kinne fergelykje mei de ekosystemen fan oare talen en jo lokaasje begripe yn it koördinaatsysteem fan softwareûntwikkeling.
Under de besuniging binne der in soad dikke oanfallen op 1C, op kritisy fan 1C, op Java, .NET en yn it algemien... De fan is fol, wolkom!
Oer mysels
Ik bin sûnt likernôch 2004 bekend mei it ûnderwerp fan petear. Ik programmearje wierskynlik al sûnt ik 6 jier wie, fanôf it momint dat ik in boek krige oer professor Fortran mei stripferhalen oer in kat, in spear en in rups. Ik analysearre de programma's dy't de kat skreau út 'e plaatsjes yn it boek en fûn út wat se diene. En ja, ik hie op dat stuit gjin echte kompjûter, mar der wie in tekening op de fersprieding fan it boek en ik drukte earlik op de papieren knoppen, en fierde de kommando's yn dy't ik de kat X bispiede hie.
Dan wie der BK0011 en BASIC op skoalle, C++ en assemblers op universiteit, doe 1C, en dan safolle oare dingen dy't ik te lui bin om te ûnthâlden. Foar de lêste 15 jier bin ik benammen belutsen west by 1C, net allinich yn termen fan kodearring, mar yn 1C yn 't algemien. It ynstellen fan taken, administraasje en devops hjir. Foar de lêste 5 jier bin ik dwaande west mei maatskiplik nuttige aktiviteiten yn termen fan it ûntwikkeljen fan ûntwikkelings- en automatisearringsynstruminten foar oare 1C-brûkers, it skriuwen fan artikels en boeken.
Litte wy beslute oer it ûnderwerp fan diskusje
Litte wy earst definiearje wêr't wy oer sille prate, om't de letters "1C" in protte dingen kinne betsjutte. Yn dit gefal sille wy mei de letters "1C" allinich it ûntwikkelingskader "1C: Enterprise" fan 'e moderne, achtste ferzje betsjutte. Wy sille net folle prate oer de fabrikant en har belied (mar wy sille in bytsje moatte dwaan oer spesifike applikaasjes skreaun mei dit ramt). Technology is apart, applikaasjes aka konfiguraasjes binne apart.
Arsjitektuer op hege nivo 1C: Enterprise
It is net foar neat dat ik it wurd "kader" neam. Fanút it eachpunt fan in ûntwikkelder is it 1C-platfoarm krekt in ramt. En jo moatte it krekt as in ramt behannelje. Tink oan it as Spring of ASP.NET, útfierd troch wat runtime (JVM of CLR respektivelik). It bart sa dat yn 'e wrâld fan' e konvinsjonele programmearring ("net 1C") de ferdieling yn kaders, firtuele masines en spesifike applikaasjes natuerlik is, fanwege it feit dat dizze komponinten normaal ûntwikkele wurde troch ferskate fabrikanten. Yn 'e 1C-wrâld is it net gewoanlik om it ûntwikkelingskader en de runtime sels eksplisyt te ûnderskieden. Dêrtroch ûntstiet wat betizing. Dêrom, yn it ramt fan it artikel, wy sille moatte beskôgje 1C fan ferskate kanten tagelyk en klassifisearje it lâns ferskate koördinaat assen. En yn elke koördinateas sille wy in skouder fan brune stof sette en sjogge nei de funksjes, foardielen en neidielen fan 'e besteande oplossing.
Standpunten op 1C
1C foar de keaper
De keaper keapet in automatisearringssysteem wêrmei't hy de problemen fan it automatisearjen fan syn eigen bedriuw fluch oplosse kin. In bedriuw kin in lyts stâl wêze, of it kin in grut holdingbedriuw wêze. It is dúdlik dat de behoeften fan dizze bedriuwen oars binne, mar beide wurde stipe troch ien platfoarmkoadebasis.
Foar de 1C-keaper is dit in rappe time-to-market. Fluch. Sneller dan Java, C# of JS. Trochsneed. Om it sikehûs. It is dúdlik dat in webside foar visitekaarten dy't React brûke sil better útdraaie, mar de efterkant fan in WMS-systeem sil rapper starte op 1C.
1C as ark
Elke technologyske oplossing hat limiten fan tapassing. 1C is gjin taal foar algemien doel; it libbet net los fan har ramt. It is oan te rieden om 1C te brûken as jo nedich binne:
- tsjinner applikaasje
- applikaasje dêr't finânsjes ferskine
- mei klearmakke UI, ORM, Reporting, XML/JSON/COM/PDF/YourDataTransferingFormat
- mei stipe foar eftergrûnprosessen en banen
- mei rol-basearre feiligens
- mei skriptbere saaklike logika
- mei de mooglikheid om fluch meitsje in prototype en lege time-to-market
Jo hawwe gjin 1C nedich as jo wolle:
- masine learen
- GPU berekkeningen
- kompjûter graphics
- wiskundige berekkeningen
- CAD systeem
- sinjaalferwurking (lûd, fideo)
- heechladen http-oproppen mei hûnderttûzenen rps
1C as produksjebedriuw
It is it wurdich te begripen wat it bedriuw fan 1C as softwarefabrikant is. 1C bedriuw ferkeapet oplossingen foar saaklike problemen fia automatisearring. Ferskillende bedriuwen, grut as lyts, mar dat is wat se ferkeapet. De middels om dit doel te berikken binne saaklike applikaasjes. Foar boekhâlding, betellingsferkear, ensfh. Om dizze applikaasjes te skriuwen, brûkt it bedriuw in eigen bedriuwsapplikaasjeûntwikkelingsplatfoarm. Spesjaal ôfstimd foar mienskiplike taken fan deselde saaklike applikaasjes:
- finansjele boekhâlding
- maklike oanpassing fan saaklike logika
- brede yntegraasjemooglikheden yn heterogene IT-lânskippen
As fabrikant is 1C fan betinken dat dit de strategy is wêrmei jo kinne wurkje mei partners en kliïnten yn in win-win-modus. Jo kinne hjirmei argumearje, mar dit is rûchwei hoe't it bedriuw himsels befoarderet: klearmakke oplossingen foar saaklike problemen dy't fluch oanpast wurde kinne troch partners en yntegreare wurde yn elk IT-lânskip.
Alle oanspraken of winsken foar 1C as ramt moatte eksklusyf wurde besjoen fia dit prisma. "Wy wolle OOP yn 1C," sizze de ûntwikkelders. "Hoefolle sil it ús kostje om OOP op it platfoarm te stypjen, sil dit ús helpe om de ferkeap fan doazen te ferheegjen?" seit 1C. Iepenet syn "prisma" fan it ferkeapjen fan oplossingen foar saaklike problemen:
- Hey, bedriuw, wolle jo OOP yn jo 1C?
- Sil dit my helpe om myn problemen op te lossen?
- Wa wit...
- Dan hoecht it net
Dizze oanpak kin goed of min wêze ôfhinklik fan wa't der nei sjocht, mar dat is krekt sa. Sprekke oer it feit dat d'r gjin funksje X yn 1C is, moatte jo begripe dat it der net foar in reden is, mar yn 'e kontekst fan' e kar "útfieringskosten vs winstbedrach".
Technologyske klassifikaasje
"Eins dogge Odinesniks har bêst om de bêste patroanen te brûken, soarchfâldich selektearre troch soarchsume metodologen en ûntwikkelders fan it 1C-platfoarm.
As jo skriuwe jo domme koade foar in ienfâldige beheard foarm, yn werklikheid jo brûke model-view-controller с double-way data binding в trije-laach-data-app-motor, smaak hege nivo objekt-relaasje-mapping op 'e basis deklarative metadata beskriuwingsyn eigen hawwe platfoarm-ûnôfhinklike query taal, c deklarative data-oandreaune brûkersynterface, folsleine transparante serialisaasje en domein-rjochte programmataal.Wêr't 1C-ûntwikkelders ferskille fan har westerske kollega's is yn PR. Se hâlde derfan om elke rommel in grutte namme te jaan en dermei om te rinnen as in smoarge tas.’’
A. Orefkov
It 1C-platfoarm hat in klassike 3-tier-arsjitektuer, yn it sintrum dêrfan is de applikaasjetsjinner (as syn emulaasje foar lyts jild foar lytse winkellju). Of MS SQL of Postgres wurdt brûkt as DBMS. D'r is ek stipe foar Oracle en IBM DB2, mar dit is earder esoterysk, gjinien wit wat der barre sil as jo 1C op dizze databases ymplementearje ûnder medium en hege lading. Ik leau dat 1C sels dit net wit.
It clientdiel is of in tinne kliïnt ynstalleare op 'e masine fan 'e brûker as in webklient. De kaaifunksje is dat programmeurs gjin 2 ferskillende koades skriuwe, se skriuwe ien applikaasje, yn ien taal, en jo kinne it werjaan yn 'e browser as d'r in winsk of need is. Wa dêr woe in wiere folsleine stack en in inkele taal foar de foar- en efterkant, node.js? It slagge se nea om krekt itselde te dwaan oant de ein. In echte folsleine stapel bestiet, mar jo moatte it yn 1C skriuwe. De irony fan it lot, sokke dingen :)
De wolk SaaS-oplossing 1C:Fresh wurket ek yn browsermodus, wêryn jo 1C net kinne keapje, mar in lytse databank hiere en dêr de shawarma-ferkeap byhâlde. Gewoan yn 'e browser, sûnder wat te ynstallearjen of te konfigurearjen.
Derneist is d'r in legacy-kliïnt, dy't yn 1C in "gewoane applikaasje" hjit. Legacy is legacy, wolkom yn 'e wrâld fan tapassingen yn 2002, mar wy prate noch oer de hjoeddeistige steat fan it ekosysteem.
It 1C-tsjinnerdiel stipet klustering en skalen troch nije masines ta te foegjen oan it kluster. Hjir binne nochal in soad eksimplaren stikken en dêr komt in aparte paragraaf oer yn it artikel. Koartsein, dit is net krekt itselde as it tafoegjen fan in pear fan krekt deselde eksimplaren efter HAProxy.
It ramt foar applikaasjeûntwikkeling brûkt in eigen programmeartaal, dy't rûchwei liket op in wat ferbettere VB6 oerset yn it Russysk. Foar minsken dy't haatsje alles Russysk, dy't net leauwe dat "as" wurdt oerset as "as", de twadde syntaksis opsje oanbean. Dy. As jo wolle, kinne jo it skriuwe yn 1C op sa'n manier dat it net te ûnderskieden is fan VB.
Dizze tige programmeartaal is de wichtichste reden foar de haat fan 1C-bynammen tsjin har platfoarm. Lit ús face it, net sûnder reden. De taal waard sa ienfâldich mooglik betocht, ûntworpen om de mantra "DEVELOPERS, DEVELOPERS" te ferfoljen op in skaal op syn minst yn 'e CIS. De kommersjele essinsje fan sa'n oplossing is neffens my dúdlik sichtber: mear ûntwikkelders, gruttere merkdekking. Dat kaam wier, neffens ferskate skattings fan 45% oant 95%. Ik sil daliks sizze dat it skriuwen yn 'e taal dy't jo tinke echt makliker is. En ik kin nochal in protte programmeartalen.
Litte wy begjinne mei de taal.
1C programmeartaal
Tagelyk it sterke en swakke punt fan it systeem. Biedt maklike yngong en lêsberens. Oan 'e oare kant is it net bywurke sûnt de frijlitting fan ferzje 8 yn 2002 en is moreel ferâldere. Immen sil sizze "it wichtichste nadeel is dat der gjin OOP" en se sille wêze ferkeard. As earste hâldt de PLO net allinich Nuraliev, mar ek Torvalds. En twadde, OOP bestiet noch.
Fanút it eachpunt fan de ûntwikkelder hat hy in ramt ta syn beskikking mei basisklassen werjûn op it DBMS. De ûntwikkelder kin de basisklasse "Directory" nimme en de map "Clients" derfan erve. It kin tafoegje nije klasse fjilden oan it, Bygelyks, INN en Adres, en ek, as it nedich is, kin oerskriuwe (oerskriuwe) metoaden fan de basis klasse, Bygelyks, de OnWrite / AtRecord metoade.
It ramt is ûntwurpen op sa'n wize dat djipper erfskip is komselden nedich, en de beheining yn OOP, yn myn miening, makket sin. 1C rjochtet him op Domain Driven Development en lit jo earst tinke oer it fakgebiet fan 'e oplossing dy't wurdt ûntwikkele, en dit is goed. D'r is net allinich gjin ferlieding, mar ek net nedich om 10 ferskillende DTO's en ViewModels te skriuwen gewoan om wat gegevens fan it domein earne te sjen. De 1C-ûntwikkelder operearret altyd mei ien entiteit, sûnder de kontekst fan 'e persepsje te rommeljen mei in tsiental klassen mei ferlykbere nammen, dy't deselde entiteit fertsjintwurdigje, mar fan in oare kant. Elke .NET-applikaasje sil bygelyks fiif of twa ViewModels en DTO's befetsje foar serialisaasje yn JSON en gegevensferfier fan kliïnt nei tsjinner. En sawat 10-15% fan jo applikaasjekoade sil wurde bestege oan it oerdragen fan gegevens fan de iene klasse nei de oare mei pennen of krukken lykas AutoMapper. Dizze koade moat skreaun wurde en programmeurs moatte wurde betelle om it te meitsjen en te ûnderhâlden.
It docht bliken dat de 1C-taal dreech te ûntwikkeljen is sûnder it te komplisearjen nei it nivo fan 'e mainstream-talen, wêrtroch it foardiel fan ienfâld ferliest. Wat is de taak fan de ferkeaper yn essinsje wurdt oplost: in standert oplossing útjaan dy't elke studint dy't op 'e strjitte fongen is kin oanpasse mei it fereaske nivo fan kwaliteit (dat wol sizze, in saak dy't fan in stall nei in grut fabryk dekt is foltôge). As jo in stall binne, nim dan in studint as jo in fabryk binne, nim dan in guru fan jo útfierende partner. It feit dat útfierende partners studinten ferkeapje foar de priis fan in guru is gjin probleem mei it ramt. Arsjitektoanysk moat it ramt de problemen fan beide oplosse, de koade fan standert konfiguraasjes (dy't wy ferkocht oan bedriuwen mei de tasizzing fan maatwurk) moat wurde begrepen troch in studint, en in guru moat wêze kinne om te begripen wat jo wolle.
Wat neffens my eins mist yn de taal, wat jo twingt om mear te skriuwen as jo koenen, is wat tiid fergriemt dy't betelle wurdt troch de klant.
- Mooglikheid om te typen op it nivo, bygelyks TypeScript (as resultaat mear ûntwikkele ark foar koade-analyze yn 'e IDE, refactoring, minder offensive jambs)
Beskikberens fan funksjes as earste klasse objekten. In wat komplekser konsept, mar it bedrach fan typyske boilerplate-koade koe gâns fermindere wurde. It begryp fan 'e studint fan' e koade, IMHO, soe sels tanimme fanwegen de fermindering fan folume - Universele kolleksje literals, initializers. Itselde ding - it ferminderjen fan it bedrach fan koade dat moat wurde skreaun en / of besjoen mei jo eagen. It ynfoljen fan kolleksjes nimt mear as 9000% fan 'e 1C-programmearringstiid yn. Dit skriuwen sûnder syntaktyske sûker is lang, djoer en flaterberich. Yn 't algemien is it bedrach fan LOC yn 1C-oplossingen alle tinkbere grinzen grutter dan beskikbere iepen kaders en, yn' t algemien, al jo Enterprise Java's kombineare. De taal is verbose, en dit ûntaardet yn 'e hoemannichte gegevens, ûnthâld, IDE-remmen, tiid, jild ...
- úteinlik konstruksjes Ik haw in hypoteze dat dizze konstruksje ûntbrekt troch it feit dat se gjin suksesfolle oersetting fan it yn it Russysk fûnen :)
- Eigen gegevenstypen (sûnder OOP), analogen fan Type út VB6. It lit jo gjin struktueren typen mei opmerkings yn 'e BSP en magyske metoaden dy't dizze struktueren konstruearje. Wy krije: minder koade, in hint troch in puntsje, flugger oplossing foar it probleem, minder flaters troch typfouten en ûntbrekkende eigenskippen fan struktueren. No leit it typen fan brûkersstruktueren folslein by it ûntwikkelteam fan 'e Standard Subsystem Library, dy't, ta syn kredyt, soarchfâldich opmerkings skriuwt oer de ferwachte eigenskippen fan de trochjûne parameterstruktueren.
- Gjin sûker by it wurkjen mei asynchrone oproppen op 'e webclient. callback-hel yn 'e foarm fan ProcessingNotifications is in tydlike kruk feroarsake troch in hommelse feroaring yn' e API fan 'e haadbrowsers, mar jo kinne net altyd sa libje, it foardiel fan "learlingbegryp" fan asynchrone koade wurdt ferlern mear en mear. Foegje gjin stipe ta foar dit paradigma yn 'e wichtichste IDE en dingen wurde noch slimmer.
Dit is ien fan 'e driuwende problemen, it is dúdlik dat de list folle grutter kin wêze, mar wy moatte net ferjitte dat dit noch gjin algemiene doeltaal is, it fereasket gjin multithreading, lambda-funksjes, tagong ta de GPU en fluch driuwende-punt berekkeningen. Dit is in saaklike logika skripttaal.
In programmeur dy't al in soad mei dizze taal wurke hat, sjocht yn js of c#, ferfelt him yn it ramt fan dizze taal. It is in feit. Hy hat ûntwikkeling nedich. Oan 'e oare kant fan' e skaal foar de ferkeaper binne de kosten foar it ymplementearjen fan de spesifisearre funksjes fersus de tanimming fan ynkomsten nei har ymplemintaasje. Hjir haw ik gjin ynformaasje oer wat op it stuit yn 'e eagen fan it bedriuw opwicht is.
Untwikkeling omjouwing
It giet hjir ek net soepel. D'r binne twa ûntwikkelingsomjouwings. De earste is de konfigurator opnommen yn 'e levering. De twadde is de Enterprise Development Tools-omjouwing, of koartsein EDT, ûntwikkele op basis fan Eclipse.
De konfigurator leveret in folslein oanbod fan ûntwikkelingstaken, stipet alle funksjes en is de wichtichste omjouwing op 'e merke. It is ek moreel ferâldere, net ûntwikkeljen, neffens geroften - fanwege it bedrach fan technyske skuld yn himsels. De situaasje koe wurde ferbettere troch it iepenjen fan in ynterne API (yn 'e foarm fan freonskip mei A. Orefkova of op in ûnôfhinklike basis), mar dit is net it gefal. De praktyk hat sjen litten dat de mienskip har eigen funksjes yn 'e IDE sil skriuwe, salang't de ferkeaper net bemuoit. Mar wy hawwe wat wy hawwe. De konfigurator wie geweldich yn 2004-2005, tige tinken oan Visual Studio fan dy tiden, op guon plakken wie it noch koeler, mar it siet yn dy tiden fêst.
Derneist is it folume fan 'e gemiddelde standertoplossing sûnt dy tiid ferskate kearen groeid, en hjoed de dei kin de IDE gewoan net omgean mei it bedrach fan koade wêrmei't it wurdt fied. Usability en refactoring mooglikheden binne net iens nul, se binne yn it read. Dit alles foeget de ûntwikkelders net ta entûsjasme en se dreame fan ferhúzjen nei oare ekosystemen en trochgean mei koade stront dêr, mar yn in noflike omjouwing dy't jo net spuie mei har gedrach.
As alternatyf wurdt in IDE skreaun fanôf scratch, boud op Eclipse, oanbean. Dêr libje de boarnen, lykas yn elke oare software, yn 'e foarm fan tekstbestannen, wurde opslein yn GIT, lûke fersyktûken, dit alles. Oan 'e ûnderkant hat it no in protte jierren gjin beta-status ferlitten, hoewol it mei elke release better wurdt. Ik sil net skriuwe oer de neidielen fan EDT, hjoed is it in minus, moarn is it in fêste funksje. De relevânsje fan sa'n beskriuwing sil gau ferdwine. Tsjintwurdich is it mooglik om te ûntwikkeljen yn EDT, mar it is ûngewoan dat jo moatte wurde taret op in bepaald oantal IDE-bugs.
As jo nei de situaasje sjogge troch it neamde "1C-prisma", krije jo sa'n ding: de frijlitting fan 'e nije IDE fergruttet de ferkeap fan doazen net, mar de útstream fan DEVELOPERS kin wurde fermindere. It is lestich om te sizzen wat it ekosysteem wachtet yn termen fan ûntwikkelderskomfort, mar Microsoft hat mobile ûntwikkelders al opknappe troch har tsjinsten te let oan te bieden.
Untwikkelingsbehear
Alles is hjir signifikant better dan yn it skriuwen fan koade, foaral koartlyn, doe't de ynspanningen fan 'e mienskip de problemen fan administraasjeautomatisearring oan it ljocht brochten, prototypen lansearren dy't oproppen om it 1C-repository yn' e jiskefet te smiten en git te brûken, rappe skuld, koadebeoardieling , statyske analyze, auto-ynset en ensfh. In protte funksjes binne tafoege oan it platfoarm dy't it nivo fan automatisearring fan ûntwikkelingstaken ferheegje. Al dizze funksjes waarden lykwols allinich en eksklusyf tafoege foar de ûntwikkeling fan ús eigen grutte produkten, doe't it dúdlik waard dat wy net sûnder automatisearring koene. D'r wiene automatyske gearfoegingen, fergeliking yn trije manieren mei KDiff en dat alles. Lansearre op Github , dy't, earlik sein, ideologysk fuortsleept fan it projekt , mar oanpast om te passen by de prosessen fan it ferkeaperbedriuw. Mei tank oan de koppige jongens fan iepen boarne kaam ûntwikkelingsautomatisaasje yn 1C fan 'e grûn. In iepen API foar de konfigurator, IMHO, soe ek de morele efterstân fan 'e wichtichste IDE ferskowe.
Hjoed, it opslaan fan 1C-boarnen yn git mei commits keppele oan problemen yn Jira, beoardielingen yn Crucible, drukknop fan Jenkins en Allure rapporten oer koade testen yn 1C en sels - dit is fier fan nijs, mar earder de mainstream yn bedriuwen wêr't in protte 1C-ûntwikkeling is.
Bestjoer
Der is hjir in protte te sizzen. As earste is dit fansels in server (1C-serverkluster). In prachtich ding, mar troch it feit dat it in folslein swarte doaze is, dokuminteare yn genôch detail, mar op in spesifike manier - behearskjen fan de lansearring fan ûnûnderbrutsen operaasje yn hege loadmodus op ferskate servers is it lot fan in selekteare dy't in pear drage. medalje mei de ynskripsje "Expert op technologyske problemen". It is de muoite wurdich op te merken dat, yn prinsipe, it administrearjen fan in 1C-tsjinner net oars is as it administrearjen fan in oare server. It is in netwurk-basearre, multi-threaded applikaasje dy't verbruikt ûnthâld, CPU, en skiif boarnen. Biedt genôch kânsen foar sammeljen en diagnoaze fan telemetry.
It probleem hjir is dat de ferkeaper neat spesjaal biedt yn termen fan klearebare oplossingen foar dizze heul diagnostyk. Ja, d'r is 1C: Instrumentation and Control Center, se binne sels frij goed, mar se binne heul djoer en net elkenien hat se. D'r binne in oantal ûntwikkelingen yn 'e mienskip foar it ferbinen fan Grafana, Zabbix, ELK en oare dingen fan' e standert admin-set, mar d'r is gjin inkele oplossing dy't de mearderheid passe sil. De taak wachtet op syn held. En as jo in bedriuw binne dat fan plan is te lansearjen op in 1C-kluster, hawwe jo in Expert nedich. Jo eigen binnen of fan bûten, mar jo hawwe it nedich. It is normaal dat d'r in aparte rol is mei kompetinsjes foar serveroperaasje, net elke 1C-brûker moat dit witte, jo moatte gewoan begripe dat sa'n rol nedich is. Lit ús bygelyks SAP nimme. Dêr komt in programmeur nei alle gedachten net iens oerein fan syn stoel as er frege wurdt om wat op 'e applikaasjetsjinner te konfigurearjen. Hy kin gewoan dom wêze en hy sil him net skamje. Yn de SAP-metoade is dêr in aparte wurknimmerrol foar. Om ien of oare reden, yn 'e 1C-sektor wurdt leaud dat dit moat wurde kombinearre yn ien meiwurker foar itselde salaris. It is in waan.
Neidielen fan 1C tsjinner
D'r is krekt ien minus - betrouberens. Of, as jo leaver, ûnfoarspelberens. Ynienen frjemd gedrach fan de tsjinner is al it praat fan 'e stêd wurden. In universele remedie - de server stopje en alle caches wiskje - wurdt sels beskreaun yn it hânboek fan 'e saakkundige, en sels in batchboek wurdt oanrikkemandearre dat dit docht. As jo 1C-systeem wat begjint te dwaan dat it teoretysk net iens moat dwaan, is it tiid om de sesjegegevenscache te wiskjen. Neffens myn skatting binne d'r mar trije minsken yn it heule lân dy't witte hoe't se in 1C-tsjinner sûnder dizze proseduere kinne operearje en se diele gjin geheimen, om't ... hja libje hjirfan. Miskien is har geheim dat se sesjegegevens skjinmeitsje, mar se fertelle der gjinien oer, dude.
Oars is de 1C-tsjinner deselde applikaasje as elke oare en wurdt op in protte deselde manier beheard, troch de dokumintaasje te lêzen en op 'e tamboerine te klopjen.
Havenarbeider
It nut fan it brûken fan in containerisearre 1C-tsjinner yn produksje is noch net bewiisd. De tsjinner wurdt net klustere troch gewoan tafoegjen fan knooppunten efter de balancer, dy't de foardielen fan produksjekontenerisaasje ta in minimum ferminderet, en de praktyk fan suksesfolle operaasje yn konteners yn hege loadmodus is net fêststeld. As resultaat brûke allinich ûntwikkelders Docker + 1C om testomjouwings yn te stellen. Dêr is it heul nuttich, tapast, kinne jo spielje mei moderne technologyen en in skoft nimme fan 'e moedeloosheid fan' e konfigurator.
Kommersjele komponint
Ut in ynvestearring eachpunt, 1C kinne jo oplosse it probleem fan fluch lansearring saaklike ideeën fanwege de brede mooglikheden fan tapassing klassen. 1C út 'e doaze jout hiel fatsoenlik Reporting, yntegraasje mei alles, web client, mobile client, mobile applikaasje, stipe foar ferskate DBMSs, incl. fergees, cross-platfoarm sawol tsjinner en ynstallearre client dielen. Ja, de UI fan applikaasjes sil giel wêze, soms is dit in minus, mar net altyd.
Troch te kiezen foar 1C, krijt in bedriuw in set fan software-oplossings wêrtroch se in heul breed oanbod fan applikaasjes kinne bouwe, lykas ek in protte ûntwikkelders op 'e merke dy't minder jild wolle as Javaisten en tagelyk resultaten rapper produsearje.
Bygelyks, de taak fan it ferstjoeren fan in PDF-fakture nei in klant kin oplost wurde yn in oere studintewurk. Itselde probleem yn .NET kin oplost wurde troch it keapjen fan in proprietêre bibleteek, of in pear dagen of wiken fan kodearring troch in strange, burdûntwikkelder. Soms, beide tagelyk. En ja, ik hie it allinich oer PDF-generaasje. Wy hawwe net sein wêr't dizze rekken sels wei komme sil. De webfrontender moat in formulier meitsje wêr't de operator de gegevens sil ynfiere, de backender sil dto-modellen moatte oanmeitsje foar it oerdragen fan JSON, modellen foar opslaan yn 'e databank, de struktuer fan' e databank sels, migraasje nei it, de foarming fan in grafyske werjaan fan dit tige akkount, en allinich dan - PDF. Op 1C is de hiele taak, fan folslein ôf, yn krekt in oere foltôge.
In folweardich boekhâlding systeem foar in lyts stall mei ien saaklike proses kocht / ferkocht wurdt dien yn 3 oeren Mei ferkeap rapportaazje, boekhâlding fan guod by oankeap en ferkeap prizen, ferdield troch pakhús, tagongsrjochten kontrôle, web client en mobile applikaasje. . Okee, ik fergeat de applikaasje, mei de applikaasje net yn 3 oeren, yn seis.
Hoe lang sil dizze taak in .NET-ûntwikkelder nimme fan it ynstallearjen fan fisuele studio op in skjinne kompjûter oant it oan de klant demonstrearje? Wat oer de kosten fan ûntwikkeling? Itselde ding.
Sterkte fan 1C as platfoarm
1C is sterk net om't d'r wat spesifyk oer is dat de bêste fan 'e wrâld is. Krektoarsom, yn elke yndividuele subsysteem kinne jo in nijsgjirriger analoog fine yn 'e software fan' e wrâld. Lykwols, basearre op in kombinaasje fan faktoaren, Ik sjoch gjin platfoarm fergelykber mei 1C. Dit is wêr't kommersjeel súkses leit. De foardielen fan it platfoarm binne ferspraat oer it en binne it dúdlikst sichtber as jo sjogge hoe't dit dien wurdt yn oare platfoarms. Yn prinsipe binne dit NET sels funksjes, mar krekt oarsom - in ôfwizing fan funksjes yn it foardiel fan ien spesifyk paradigma. In pear foarbylden:
- Unicode. Wat de hel koe wêze ienfâldiger? D'r is gjin needsaak om single-byte ASCII-kodearrings te brûken yn 2019 (útsein foar yntegraasje mei âlde legacy). Nea. Mar nee. Hoe dan ek, immen yn guon tabel brûkt in single-byte varchar en de applikaasje sil hawwe problemen mei kodearring. Yn 2015 is de LDAP-autorisaasje fan gitlab mislearre troch ferkeard wurk mei kodearrings JetBrains IDE wurket noch altyd net mei Cyrillysk yn bestânsnammen. 1C leveret heechweardige isolaasje fan applikaasjekoade fan 'e databanklaach. Dêr is it ûnmooglik om tabellen op in leech nivo te typen en jambs fan ynkompetinte junioaren op it databanknivo binne dêr ûnmooglik. Ja, d'r kinne oare problemen wêze mei ynkompetinte junioaren, mar it ferskaat oan problemen is folle lytser. No sille jo my fertelle dat jo applikaasje goed is ûntworpen en dat de databank tagongslaach is isolearre sa't it moat wêze. Sjoch nochris nei jo bedriuw oanpaste Java-applikaasje. Nau en earlik. Pleatst dyn gewisse dy? Dan bin ik bliid foar dy.
- Nûmering fan dokuminten / referinsjeboeken. Yn 1C is it perfoarst net de meast fleksibele en net de bêste. Mar wat se dogge yn banksoftware en yn selsskreaune boekhâldingsystemen - goed, it is gewoan tsjuster. Of identiteit sil wurde fêst yn (en dan "oh, wêrom hawwe wy gatten"), of krekt oarsom, se sille meitsje in generator dy't wurket mei beskoattelje op it DBMS nivo (en sil wurden in knipepunt). Yn feite is it frij lestich om dizze skynber ienfâldige taak te dwaan - in ein-oan-ein enumerator fan entiteiten, mei in unykheid seksje basearre op in bepaalde set fan kaaien, prefiksaasje, sadat it de databank net blokkeart by parallelle gegevensynfier .
- Identifikaasjes fan records yn 'e databank. 1C makke in sterke wilsbeslút - alle keppelingsidentifikaasjes binne absolút syntetysk en dat is it. En d'r binne gjin problemen mei ferdielde databases en útwikselingen. Ûntwikkelers fan oare systemen koppich meitsje soksawat as identiteit (it is koarter!), Sleep se yn de GUI oant it is tiid om te meitsjen ferskate besibbe eksimplaren (en dan wurde se ûntdutsen). Hawwe jo dit net? Earlik sein?
- Listen. 1C hat frij suksesfolle meganismen om troch (grutte) listen te blêdzjen en troch har te navigearjen. Lit my direkt reservearje - mei it juste gebrûk fan it meganisme! Yn it algemien is it ûnderwerp frijwat onaangenaam, it kin net ideaal oplost wurde: it is of yntuïtyf en ienfâldich (mar it risiko fan enoarme recordsets op 'e kliïnt), of paging is fan ien of oare krom. Wa't paging docht, docht it faaks krom. Dejingen dy't in earlike rôlbalke meitsje, foegje in databank, in kanaal en in klant ta.
- Beheare formulieren. Gjin twifel, yn 'e webclient wurket de ynterface net perfekt. Mar it wurket. Mar foar in protte oare boekhâlding- en banksystemen is it meitsjen fan in wurkplak op ôfstân in projekt op ûndernimmingsnivo. Disclaimer: gelokkich foar dyjingen dy't it oarspronklik makke op it web, dit sil gjin ynfloed hawwe.
- Mobile app. Koartlyn kinne jo ek mobile applikaasjes skriuwe wylst jo yn itselde ekosysteem binne. It is hjir in bytsje komplisearre as mei in webklient, de spesifiken fan apparaten twinge jo om spesifyk foar har te skriuwen, mar jo hiere net in apart team fan mobile ûntwikkelders. As jo in applikaasje nedich binne foar de ynterne behoeften fan in bedriuw (as in mobile oplossing foar in bedriuwsprobleem wichtiger is dan in giel UI-ûntwerp), brûke jo gewoan itselde platfoarm út 'e doaze.
- Ferslachjouwing. Mei dit wurd bedoel ik net in BI-systeem mei grutte gegevens en in efterstân op it ETL-proses. Dit ferwiist nei operasjonele personielsrapporten wêrmei jo de steat fan boekhâlding hjir en no kinne beoardielje. Saldo's, ûnderlinge delsettings, re-grading, ensfh. 1C komt út it fak mei in rapportaazjesysteem mei fleksibele ynstellingen foar groepearrings, filters en fisualisaasje oan 'e brûkerskant. Ja, d'r binne koeler analogen op 'e merke. Mar net yn it ramt fan in alles-yn-ien-oplossing en foar in priis soms heger as in alles-yn-ien-oplossing. En faker is it sels ek oarsom: allinnich ferslach, mar djoerder as it hiele platfoarm, en minder fan kwaliteit.
- Printbere formulieren. No, brûk .NET om it probleem op te lossen fan it ferstjoeren fan salarisstroken yn PDF nei meiwurkers fia e-post. En no de taak fan it printsjen fan faktueren. Hoe sit it mei it bewarjen fan har kopyen op deselde PDF? Foar 1C bynamme, it útfieren fan elke yndieling nei PDF is +1 rigel fan koade. Dit betsjut + 40 sekonden wurktiid, ynstee fan dagen of wiken yn in oare taal. Printe formulierlayouts yn 1C binne ongelooflijk maklik te ûntwikkeljen en krêftich genôch om te konkurrearjen mei betelle tsjinhingers. Ja, wierskynlik binne d'r net folle ynteraktive kânsen yn 1C-spreadsheetdokuminten, jo kinne net fluch in 3D-diagram krije mei skaalfergrutting mei OpenGL. Mar is it echt nedich?
Dit binne mar in hantsjefol foarbylden wêr't it beheinen fan funksjonaliteit of it útfieren fan kompromissen in wichtich arsjitektoanysk foardiel yn 'e takomst blykt te wêzen. Sels in kompromis of net de meast effektive opsje - it is al yn 'e doaze en wurdt as fanselssprekkend nommen. De ûnôfhinklike ymplemintaasje dêrfan sil óf ûnmooglik wêze (om't sokke besluten moatte wurde makke oan it begjin fan it projekt, en d'r is gjin tiid foar dat, en d'r is hielendal gjin arsjitekt), of ferskate djoere iteraasjes. Yn elk fan 'e neamde punten (en dit is net in folsleine list fan arsjitektoanyske oplossingen), kinne jo beheine en ynfiere beheiningen dy't skaalfergrutting blokkearje. Yn alle gefallen moatte jo, as sakeman, derfoar soargje dat jo programmeurs, by it meitsjen fan in "systeem fanôf scratch", rjochte hannen hawwe en subtile systeemproblemen direkt goed sille dwaan.
Ja, lykas yn elk oar kompleks systeem, hat 1C sels ek oplossingen dy't skaalfergrutting yn bepaalde aspekten blokkearje. Ik werhelje lykwols, basearre op in kombinaasje fan faktoaren, de kosten fan eigendom, en it oantal problemen dy't al fan tefoaren oplost binne, sjoch ik gjin weardige konkurrint op 'e merk. Foar deselde priis krije jo in finansjeel tapassingskader, in klustere lykwichtige server, mei in UI en webynterface, mei in mobile applikaasje, mei rapportaazje, yntegraasje en in protte oare dingen. Yn 'e Java-wrâld hiere jo in front-end- en back-end-team, debuggen leech-nivo shoals fan thússkreaune serverkoade en betelje apart foar 2 mobile applikaasjes foar 2 mobile OS.
Ik sis net dat 1C alle gefallen sil oplosse, mar foar in ynterne bedriuwsapplikaasje, as it net nedich is om de UI te markearjen - wat is oars nedich?
Fly yn 'e sied
Jo hawwe wierskynlik de yndruk krigen dat 1C de wrâld sil rêde en dat alle oare manieren om bedriuwssystemen te skriuwen ferkeard binne. It is hielendal net sa. Fanút it eachpunt fan in sakeman, as jo kieze foar 1C, dan moatte jo neist de rappe tiid-to-merk rekken hâlde mei de folgjende neidielen:
- Tsjinner betrouberens. Echt heechweardige spesjalisten binne nedich dy't har ûnûnderbrutsen wurking garandearje kinne. Ik bin net bewust fan in ready-made training programma foar sokke spesjalisten út de ferkeaper. D'r binne kursussen om ta te rieden foar it Expert-eksamen, mar dit is neffens my net genôch.
- Stypje. Sjoch foarige paragraaf. Om stipe te hawwen fan 'e ferkeaper, moatte jo it keapje. Om ien of oare reden wurdt dit net akseptearre yn 'e 1C-sektor. En mei SAP is it hast in must-oankeap en it docht gjinien. Sûnder bedriuwsstipe en sûnder in ekspert op personiel, kinne jo allinich wurde litten mei 1C glitches.
- Dochs kinne jo net alles dwaan mei 1C. Dit is in ark en lykas elk ark hat it limiten fan tapassing. Yn it 1C-lânskip is it tige winsklik om in "net-1C" systeemarsjitekt te hawwen.
- Goede 1C bynammen binne net goedkeaper as goede programmeurs yn oare talen. Hoewol, minne programmeurs binne djoer om te hieren, nettsjinsteande de taal wêryn se skriuwe.
Lit ús stipje de stippen
- 1C is in ramt foar rappe applikaasjeûntwikkeling (RAD) foar bedriuw en is dêrfoar oanpast.
- Three-tier link mei stipe foar grutte DBMS's, client UI, in heul goede ORM en rapportaazje
- Wide mooglikheden foar yntegraasje mei systemen dy't dwaan kinne wat 1C net kin. As jo masine learen wolle, nim Python en stjoer it resultaat nei 1C fia http of RabbitMQ
- D'r is net nedich om te stribjen om alles te dwaan mei 1C, jo moatte har sterke punten begripe en se brûke foar jo eigen doelen
- Ûntwikkelers dy't gravitearje nei it graven yn technologyske ramtgadgets en elke N jier opnij ûntwerpe nei in nije motor, wurde ferfeeld mei 1C. Alles is dêr tige konservatyf.
- Untwikkelders binne ek ferfelen, om't d'r heul lyts soarch foar har is fan 'e fabrikant. Saai taal, swak IDE. Se fereaskje modernisearring.
- Oan 'e oare kant binne ûntwikkelders dy't gjin wille kinne fine troch it brûken en learen fan in oare technology dy't se genietsje binne minne ûntwikkelders. Se sille gûle en ferhúzje nei in oar ekosysteem.
- Wurkjouwers dy't harren 1C-bynammen net tastean wat yn Python te skriuwen binne minne wurkjouwers. Se sille meiwurkers ferlieze mei nijsgjirrige geasten, en yn har plak komme aapkodders dy't, wylst se mei alles iens binne, bedriuwssoftware yn 'e sompe sille slepe. It sil noch wol wer skreaun wurde moatte, dus miskien soe it better wêze om wat earder wat yn Python te ynvestearjen?
- 1C is in kommersjeel bedriuw en ymplementearret funksjes allinich basearre op har eigen belangen en doelmjittigens. Jo kinne har dit net skuldich meitsje, bedriuw moat tinke oan winst, dat is it libben
- 1C makket jild troch it ferkeapjen fan oplossingen foar saaklike problemen, net oan Vasya's ûntwikkeldersproblemen. Dizze twa begripen korrelearje, mar de prioriteit is krekt wat ik sei. As ûntwikkelder Vasya is ree om te beteljen foar in persoanlike lisinsje foar 1C: Resharper, sil ferskine frij fluch, "Resharper" troch A. Orefkova is bewiis fan dit. As de ferkeaper it stipe, en der net tsjin fjochte, soe in merk foar software foar ûntwikkelders ferskine. No binne d'r ien en in heale spilers op dizze merk mei twifele resultaten, en alles om't de yntegraasje mei de IDE negatyf is en alles wurdt dien op krûken.
- De praktyk fan in multi-masine operator sil ferdwine yn it ferjit. Moderne applikaasjes binne te grut om te ûnthâlden sawol fan 'e koadekant as fan' e kant fan 'e saaklike gebrûk. De 1C-tsjinner wurdt ek komplekser, it sil ûnmooglik wêze om alle soarten ekspertize yn ien meiwurker te hâlden. Dit moat in fraach nei spesjalisten befetsje, dat betsjut de oantreklikens fan it 1C-berop en in ferheging fan salarissen. As Vasya earder trije-yn-ien wurke foar ien salaris, no moatte jo twa Vasyas hiere en konkurrinsje tusken Vasyas kin de totale groei fan har nivo stimulearje.
konklúzje
1C is in heul wurdich produkt. Yn myn priisklasse wit ik hielendal gjin analogen, skriuw yn 'e kommentaren as d'r binne. De útstream fan ûntwikkelders út it ekosysteem wurdt lykwols mear en mear merkber, en dit is in "braindrain", hoe't jo it ek sjogge. De yndustry is hongerich foar modernisearring.
As jo in ûntwikkelder binne, hingje dan net oan 1C en tink net dat alles magysk is yn oare talen. Wylst jo in junior binne, miskien. Sadree't der wat grutters oplost wurde moat, sil der langer socht wurde moatte nei klearebare oplossingen en yntinsiver ôfmakke wurde. Wat de kwaliteit fan 'e "blokken" oanbelanget wêrfan in oplossing boud wurde kin, is 1C heul, heul goed.
En noch ien ding - as in 1C bynamme nei jo komt om te hieren, dan kin de 1C bynamme feilich beneamd wurde yn 'e posysje fan lead analysts. Har begryp fan 'e taak, fakgebiet en ûntbiningfeardigens is poerbêst. Ik bin der wis fan dat dit krekt komt troch it twongen gebrûk fan DDD yn 1C-ûntwikkeling. In persoan wurdt oplaat om te tinken oer de betsjutting fan in taak earst fan alle, oer de ferbinings tusken objekten fan it ûnderwerp gebiet, en tagelyk hat in technyske eftergrûn yn yntegraasje technologyen en data útwikseling formaten.
Wês bewust dat it ideale ramt net bestiet en soargje foar josels.
Alles goed!
PS: tige tank foar help by it tarieden fan it artikel.
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. , asjebleaft.
Hawwe jo 1C yn jo bedriuw?
-
13,3%Hielendal net.71
-
30,3%Der is, mar allinnich yn de boekhâlding ôfdieling earne. Kearnsystemen op oare platfoarms162
-
41,4%Ja, de wichtichste saaklike prosessen wurkje oan it221
-
15,0%1C moat stjerre, de takomst heart by %technology_name%80
534 brûkers stimden. 99 brûkers ûntholden har.
Boarne: www.habr.com