Lagun eta lankideok, azkenaldian, Habré-ri buruzko artikuluak maizago agertu dira 1C garapen-plataforma gisa gorrotoarekin, eta haren defendatzaileen hitzaldiak. Artikulu hauek arazo larri bat identifikatu zuten: gehienetan, 1C-ko kritikoek "ez menperatzeko" jarreratik kritikatzen dute, de facto erraz konpontzen diren arazoak errieta eginez, eta, aitzitik, benetan garrantzitsuak diren, merezi duten arazoak ez ukituz. eztabaidatzen eta ez ditu saltzaileak konpontzen . Uste dut zentzuzkoa dela 1C plataformaren berrikuspen soila eta orekatua egitea. Zer egin dezakeena, zer ezin duena, zer egin behar duena baina ez duena, eta, postrerako, zer egiten duen kolpe batekin, eta %technology_name%-ko zure garatzaileek ehun urte egingo dituzte, botaz. urteko aurrekontu bat baino gehiago.
Ondorioz, zuk, kudeatzaile edo arkitekto gisa, argi ulertu ahal izango duzu zer zeregin onuragarria izango zaizun 1C erabiltzea eta non erre behar den plantxa bero batekin. "1C ez den" munduan garatzaile gisa, 1C-n zer dagoen ikusi ahal izango duzu zalaparta eragiten duena. Eta 1C garatzaile gisa, zure sistema beste hizkuntzetako ekosistemekin alderatu eta zure kokapena software garapenaren koordenatu sisteman ulertu ahal izango duzu.
Mozketaren azpian eraso lodi asko daude 1C-ren aurka, 1C-ren kritiken aurka, Java-ren, .NET-en eta orokorrean... Fana beteta dago, ongi etorri!
Niri buruz
2004tik gutxi gorabehera ezagutzen dut elkarrizketaren gaia. Ziurrenik 6 urte nituela programatzen ari naiz, Fortran irakasleari buruzko liburu bat jaso nuen momentutik katu, txolarre eta beldar bati buruzko komikiekin. Katuak liburuko irudietatik idatzitako programak aztertu eta zer egiten zuten jakin nuen. Eta bai, garai hartan ez nuen benetako ordenagailurik, baina liburuaren zabalkundean marrazki bat zegoen eta zintzotasunez sakatu nituen papereko botoiak, X katuari zelatatu nituen aginduak sartuz.
Gero BK0011 eta BASIC zeuden eskolan, C++ eta muntatzaileak unibertsitatean, gero 1C, eta gero beste hainbeste gauza, nagiegi nago gogoratzeko. Azken 15 urteotan 1C-n aritu naiz batez ere, ez kodifikazioari dagokionez bakarrik, 1C-n oro har. Zereginak, administrazioa eta devops hemen ezartzea. Azken 5 urteotan, 1C-ko beste erabiltzaile batzuen garapenerako eta automatizaziorako tresnak garatzeko, artikuluak eta liburuak idazten ari naiz sozialki baliagarriak diren jardueretan.
Erabaki dezagun eztabaidagaia
Lehenik eta behin, defini dezagun zertaz hitz egingo dugun, "1C" hizkiek gauza asko esan ditzakete eta. Kasu honetan, "1C" hizkiekin zortzigarren bertsio modernoaren "1C: Enterprise" garapen-esparrua esan nahi dugu soilik. Ez dugu asko hitz egingo fabrikatzaileaz eta bere politikez (baina pixka bat egin beharko dugu ez dugu marko hau erabiliz idatzitako aplikazio zehatzak eztabaidatuko). Teknologia bereizia da, aplikazioak edo konfigurazioak bereizita daude.
Goi-mailako arkitektura 1C: Enterprise
Ez da alferrik "esparru" hitza aipatzen dudana. Garatzaile baten ikuspuntutik, 1C plataforma marko bat da hain zuzen. Eta marko bat bezala tratatu behar duzu. Pentsa ezazu Spring edo ASP.NET gisa, exekuzio-denbora batzuek (JVM edo CLR hurrenez hurren). Gertatzen da ohiko programazioaren munduan (“ez 1C”) markoetan, makina birtualetan eta aplikazio zehatzetan banatzea naturala dela, osagai hauek fabrikatzaile ezberdinek garatu ohi dituztelako. 1C munduan, ez da ohikoa garapen-esparrua eta exekuzio-denbora bera esplizituki bereiztea, gainera, esparrua erabiliz idatzitako aplikazio espezifikoak ere 1Ck berak garatzen ditu. Ondorioz, nolabaiteko nahasmena sortzen da. Hori dela eta, artikuluaren esparruan, 1C aldi berean hainbat aldetatik kontuan hartu beharko dugu eta hainbat koordenatu ardatzetan sailkatu. Eta koordenatu-ardatz bakoitzean substantzia marroizko pala bat jarriko dugu eta dagoen soluzioaren ezaugarriak, abantailak eta desabantailak aztertuko ditugu.
1C-ko ikuspuntuak
1C eroslearentzat
Erosleak automatizazio-sistema bat erosten du eta horrekin bere negozioa automatizatzeko arazoak azkar konpondu ditzake. Negozio bat postu txiki bat izan daiteke, edo holding handi bat izan daiteke. Argi dago negozio horien beharrak desberdinak direla, baina biak plataforma kode-oinarri bakar batek onartzen ditu.
1C eroslearentzat hau merkaturatzeko denbora azkarra da. Azkar. Java, C# edo JS baino azkarragoa. Batez bestekoa. Ospitale inguruan. Argi dago React erabiltzen duen bisita-txartelen webgunea hobeto aterako dela, baina WMS sistema baten backend-a azkarrago abiaraziko da 1C-n.
1C tresna gisa
Soluzio teknologiko bakoitzak aplikagarritasun-mugak ditu. 1C ez da erabilera orokorreko hizkuntza bat, ez da bere esparrutik bereizita bizi. Behar duzunean 1C erabiltzea komeni da:
- zerbitzariaren aplikazioa
- finantzak agertzen diren aplikazioa
- prest egindako UI, ORM, Reporting, XML/JSON/COM/PDF/YourDataTransferingFormat-ekin
- atzeko prozesuetarako eta lanpostuetarako laguntzarekin
- roletan oinarritutako segurtasunarekin
- scriptable negozio-logika batekin
- prototipo bat azkar sortzeko gaitasunarekin eta merkaturatzeko denbora gutxirekin
Ez duzu 1C behar nahi baduzu:
- ikaskuntza automatikoa
- GPU kalkuluak
- ordenagailu grafikoak
- kalkulu matematikoak
- CAD sistema
- seinaleen prozesamendua (soinua, bideoa)
- karga handiko http deiak ehunka mila rps-ekin
1C fabrikazio-enpresa gisa
Merezi du ulertzea zein den 1C-ren negozioa software fabrikatzaile gisa. 1C konpainiak negozio-arazoetarako irtenbideak saltzen ditu automatizazio bidez. Negozio desberdinak, handiak edo txikiak, baina hori da saltzen duena. Helburu hori lortzeko bitartekoak negozio-aplikazioak dira. Kontabilitaterako, nominak egiteko, etab. Aplikazio hauek idazteko, enpresak bere negozio-aplikazioak garatzeko plataforma erabiltzen du. Negozio-aplikazio hauen ohiko zereginetarako bereziki egokitua:
- finantza kontabilitatea
- negozio-logikaren pertsonalizazio erraza
- integrazio aukera zabalak IT paisaia heterogeneoetan
Fabrikatzaile gisa, 1C-k uste du bazkide eta bezeroekin irabazi-irabazi moduan lan egiteko aukera ematen duen estrategia dela. Hori argudiatu dezakezu, baina hori da, gutxi gorabehera, nola sustatzen du konpainiak: negozio-arazoetarako prest dauden irtenbideak, bazkideek azkar pertsonaliza ditzaketen eta edozein IT panoraman integratzeko.
1C esparru gisa erreklamazio edo nahi guztiak prisma honen bidez soilik ikusi behar dira. "OOP 1C-n nahi dugu", diote garatzaileek. "Zenbat kostatuko zaigu plataforman OOP onartzea, honek kutxen salmentak handitzen lagunduko al digu?", dio 1C-k. Negozio-arazoei irtenbideak saltzeko bere "prisma" irekitzen du:
- Aizu, negozioa, nahi al duzu OOP zure 1C-n?
- Honek nire arazoak konpontzen lagunduko dit?
- Nork daki...
- Orduan ez dago beharrik
Ikuspegi hau ona edo txarra izan daiteke, begiratzen ari denaren arabera, baina horrela da. 1C-n X ezaugarririk ez dagoelari buruz hitz egitean, ulertu behar duzu ez dagoela arrazoi batengatik, baizik eta "inplementazio kostua vs irabazien zenbatekoa" aukeraren testuinguruan.
Sailkapen teknologikoa
“Izan ere, Odinesnikek ahal duten guztia egiten dute eredu onenak erabiltzeko, 1C plataformako metodologo eta garatzaileek arreta handiz aukeratutakoak.
Zure kode ergela idazten duzunean kudeatutako inprimaki soil baterako, benetan erabiltzen ari zara eredu-ikuspegi-kontrolatzailea с bide bikoitzeko datu-lotura в hiru geruzako datu-aplikazio-motorra, zaporetsua goi-mailako objektu-erlazio-mapaketa oinarrian metadatuen deskribapen deklaratiboaberea izatea plataformatik independentea den kontsulta-lengoaia, C datuetan oinarritutako erabiltzailearen interfaze deklaratiboa, serializazio garden osoa eta domeinuetara zuzendutako programa-lengoaia.1C garatzaileak Mendebaldeko lankideengandik desberdintzen diren tokian PR dago. Asko gustatzen zaie edozein zikinkeriari izen handia ematea eta harekin ibiltzea poltsa zikin bat bezala».
A. Orefkov
1C plataformak 3 mailatako arkitektura klasikoa du, eta horren erdian aplikazio zerbitzaria dago (edo bere emulazioa diru gutxigatik dendari txikientzat). MS SQL edo Postgres DBMS gisa erabiltzen da. Oracle eta IBM DB2-ren laguntza ere badago, baina hori nahiko esoterikoa da inork ez daki zer gertatuko den datu-base hauetan 1C karga ertain eta altuan ezartzen baduzu. Uste dut 1C-k berak ez duela hori ezagutzen.
Bezeroaren zatia erabiltzailearen makinan instalatutako bezero mehe bat edo web bezero bat da. Funtsezko ezaugarria da programatzaileek ez dutela 2 kode ezberdin idazten, aplikazio bat idazten dute, hizkuntza batean, eta arakatzailean bistaratu dezakezu nahia edo beharra izanez gero. Nork nahi zuen benetako pila osoa eta hizkuntza bakar bat aurrealdeko eta backend-erako, node.js? Ez zuten inoiz gauza bera egitea lortu amaierara arte. Benetako pila osoa existitzen da, baina 1C-n idatzi beharko duzu. Patuaren ironia, horrelakoak :)
Hodeiko SaaS irtenbide 1C:Fresh-ek arakatzaile moduan ere funtzionatzen du, eta bertan ezin duzu 1C erosi, baina datu-base txiki bat alokatu eta shawarma salmenten jarraipena egin. Nabigatzailean besterik ez, ezer instalatu edo konfiguratu gabe.
Horrez gain, ondarezko bezero bat dago, 1C-n "aplikazio arrunta" deitzen zaiona. Legacy ondarea da, ongi etorri aplikazioen mundura 2002an, baina oraindik ekosistemaren egungo egoeraz ari gara.
1C zerbitzariaren zatiak clustering-a eta eskalatzea onartzen du klusterera makina berriak gehituz. Hemen kopia asko apurtu dira eta honi buruzko artikuluan aparteko atal bat egongo da. Laburbilduz, hau ez da HAProxyren atzean kasu berdinen pare bat gehitzea.
Aplikazioak garatzeko esparruak bere programazio-lengoaia erabiltzen du, gutxi gorabehera errusierara itzulitako VB6 apur bat hobetu baten antza duena. Errusiar guztia gorroto duten pertsonentzat, "baldin" bezala itzultzen denik sinesten ez dutenentzat, bigarren sintaxi aukera eskaintzen da. Horiek. Nahi izanez gero, 1C-n idatz dezakezu VBtik bereizteko moduan.
Programazio-lengoaia hau bera da 1C goitizenek haien plataformaren aurka gorrotoaren arrazoi nagusia. Aitor dezagun, ez arrazoirik gabe. Hizkuntza ahalik eta sinpleena pentsatu zen, "GARATZAILEAK, GARATZAILEAK" mantra betetzeko diseinatua, gutxienez CISen. Irtenbide horren funtsa komertziala, nire ustez, argi ikusten da: garatzaile gehiago, merkatu-estaldura handiagoa. Hori egia bihurtu zen, hainbat kalkuluen arabera %45etik %95era. Berehala esango dut zuk uste duzun hizkuntzan idaztea benetan errazagoa dela. Eta programazio-lengoaia asko ezagutzen ditut.
Has gaitezen hizkuntzatik.
1C programazio-lengoaia
Aldi berean sistemaren puntu sendoa eta ahula. Sarrera erraza eta irakurgarritasuna eskaintzen du. Bestalde, 8an 2002. bertsioa kaleratu zenetik ez da eguneratu eta moralki zaharkituta dago. Norbaitek esango du "eragozpen nagusia OOP ez dagoela" eta oker egongo dira. Lehenik eta behin, PLOk ez ditu nuralievak ez ezik, torvaldek ere atsegin. Eta bigarrenik, OOP oraindik existitzen da.
Garatzailearen ikuspuntutik, DBMSan bistaratzen diren oinarrizko klaseak dituen esparru bat dauka eskura. Garatzaileak oinarrizko klasea "Directory" har dezake eta "Bezeroak" direktorioa heredatu. Klase-eremu berriak gehi diezazkioke, adibidez, INN eta Helbidea, eta, halaber, beharrezkoa izanez gero, oinarrizko klaseko metodoak gainidatzi ditzake, adibidez, OnWrite/AtRecord metodoa.
Esparrua oinordetza sakonagoa oso gutxitan behar den moduan diseinatuta dago, eta OOP-en murrizketak, nire ustez, zentzuzkoa du. 1C Domeinuak bultzatutako garapenean zentratzen da eta, lehenik eta behin, garatzen ari den soluzioaren gaiari buruz pentsatzen jartzen zaitu, eta hau ona da. Ez dago tentaziorik ez ezik, 10 DTO eta ViewModel desberdin idatzi beharrik ere ez dago domeinuko datu batzuk nonbait erakusteko. 1C garatzaileak beti entitate batekin funtzionatzen du, pertzepzioaren testuingurua nahastu gabe antzeko izenak dituzten dozena bat klaserekin, entitate bera ordezkatzen dutenak, baina beste alde batetik. Edozein .NET aplikazioak, adibidez, nahitaez bost edo bi ViewModel eta DTO edukiko ditu JSON-n serializatu eta bezerotik zerbitzarira datuak transferitzeko. Eta zure aplikazio-kodearen % 10-15 gutxi gorabehera klase batetik bestera datuak transferitzen gastatuko da AutoMapper bezalako boligrafoak edo makuluak erabiliz. Kode hori idatzi behar da eta programatzaileei ordaindu behar zaie sortu eta mantentzeko.
Ematen du 1C hizkuntza zaila dela hizkuntza nagusien mailara konplikatu gabe garatzea, horrela sinpletasunaren abantaila galduz. Zein da saltzailearen zeregina, funtsean, konpontzen ari dena: kalean harrapatutako edozein ikaslek behar den kalitate-mailarekin pertsonaliza dezakeen irtenbide estandar bat ematea (hau da, txosna batetik lantegi handi batera estaltzen den kasua osatzen da). Saltoki bat bazara, hartu ikasle bat lantegia bazara, hartu guru bat zure ezarpen-kidearengandik. Ezarpen-bazkideek ikasleak guru baten prezioan saltzea ez da markoaren arazoa. Arkitektura aldetik, esparruak bien arazoak konpondu behar ditu, konfigurazio estandarren kodea (enpresei saldu genien pertsonalizazioaren promesarekin) ikasle batek ulertzeko gai izan behar du, eta guru batek nahi duzuna ulertzeko gai izan behar du.
Nire ustez hizkuntzan benetan falta dena, ahal baino gehiago idaztera behartzen zaituena, bezeroak ordaindutako denbora galtzen duena da.
- Mailan idazteko aukera, adibidez, TypeScript (ondorioz, IDEan kodea aztertzeko tresna garatuagoak, refactoring, jamb iraingarri gutxiago)
Funtzioen erabilgarritasuna lehen mailako objektu gisa. Kontzeptu apur bat konplexuagoa, baina ohiko boilerplate-kode kopurua asko murriztu liteke. Ikasleak kodearen ulermena, IMHO, areagotu egingo litzateke bolumenaren murrizketa dela eta - Bilduma unibertsalaren literalak, hasieratzaileak. Gauza bera - zure begiekin idatzi eta/edo begiratu behar den kode kopurua murriztea. Bildumak betetzeak 9000C programazio denboraren % 1 baino gehiago hartzen du. Hau azukre sintaktikorik gabe idaztea luzea, garestia eta akatsetarako joera du. Orokorrean, 1C soluzioetako LOC-kopuruak pentsa daitezkeen muga guztiak gainditzen ditu eskuragarri dauden marko irekiekin eta, oro har, zure enpresa-Java guztiekin konparatuta. Lengoaia hitza da, eta hau datu kopuruan, memorian, IDE balaztak, denbora, dirua... endekatzen da.
- azkenik, eraikuntzak eraikuntza hau faltan dagoelako hipotesia daukat errusierara itzulpen arrakastatsurik aurkitu ez dutelako :)
- Datu mota propioak (OOP gabe), VB6 motaren analogoak. Egiturak ez idazteko aukera emango dizu BSPko iruzkinak erabiliz eta egitura horiek eraikitzen dituzten metodo magikoak. Lortzen dugu: kode gutxiago, puntu baten bidez iradokizun bat, arazoaren konponbide azkarragoa, akats gutxiago eta egituren propietate faltagatik. Orain, erabiltzaile-egituren idazketa azpisistema estandarraren liburutegiaren garapen-taldearen esku dago erabat, eta, bere onerako, arretaz idazten ditu gainditutako parametro-egituren espero diren propietateei buruzko iruzkinak.
- Ez dago azukrerik web bezeroan dei asinkronoekin lan egiten duzunean. Callback-hell ProcessingNotifications moduan nabigatzaile nagusien APIaren bat-bateko aldaketak eragindako aldi baterako makulua da, baina ezin duzu horrela bizi denbora guztian kode asinkronoaren "ikasleen ulermenaren" abantaila galtzen ari da Gero eta gehiago. Ez gehitu paradigma honen euskarririk IDE nagusian eta gauzak are okerrera egingo dute.
Hau da arazo larrietako bat, argi dago zerrenda askoz handiagoa izan daitekeela, baina ez dugu ahaztu behar oraindik ez dela erabilera orokorreko lengoaia bat, ez duela behar multithreading, lambda funtzioak, GPUrako sarbidea eta azkarra. koma mugikorreko kalkuluak. Hau negozio-logikako gidoi-lengoaia da.
Dagoeneko hizkuntza honekin asko lan egin duen programatzailea, js edo c#-ra begiratzen duena, aspertzen da hizkuntza honen esparruan. Gertaera bat da. Garapena behar du. Saltzailearen eskalaren beste aldean zehaztutako ezaugarriak ezartzearen kostua inplementatu ondoren diru-sarreren gehikuntzaren aldean dago. Hemen ez daukat enpresaren aurrean gaur egun gainditzen ari denari buruzko informaziorik.
Garapen ingurunea
Hemen ere gauzak ez doaz ondo. Bi garapen-ingurune daude. Lehenengoa entregan sartutako Konfiguratzailea da. Bigarrena, Enterprise Development Tools ingurunea, edo laburbilduz EDT, Eclipse-n oinarrituta garatutakoa da.
Konfiguratzaileak garapen-zeregin sorta osoa eskaintzen du, funtzio guztiak onartzen ditu eta merkatuko ingurune nagusia da. Era berean, moralki zaharkituta dago, ez garatzen, zurrumurruen arabera, bere baitan dagoen zor teknikoaren zenbatekoa dela eta. Egoera hobetu liteke barne API bat irekiz (adiskidetasun moduan A. Orefkova edo independentean), baina ez da horrela. Praktikak erakutsi du komunitateak bere ezaugarriak idatziko dituela IDEan, saltzaileak oztopatzen ez duen bitartean. Baina daukaguna daukagu. Konfiguratzailea bikaina zen 2004-2005 urteetan, garai haietako Visual Studio oso gogorarazten zuen, leku batzuetan are freskoagoa zen, baina garai haietan itsatsita zegoen.
Horrez gain, batez besteko soluzio estandarraren bolumena hainbat aldiz hazi da ordutik, eta gaur egun IDEak ezin du elikatzen duen kode kopuruari aurre egin. Erabilgarritasuna eta birfactoring gaitasunak ere ez dira zero, gorriz daude. Horrek guztiak ez die ilusiorik gehitzen garatzaileei eta amesten dute beste ekosistemetara mugitzea eta bertan kaka kodetzen jarraitzea, baina bere portaerarekin aurpegira tu egiten ez dizun ingurune atsegin batean.
Alternatiba gisa, hutsetik idatzitako IDE bat eskaintzen da, Eclipse-n eraikia. Bertan, iturriak, beste edozein softwaretan bezala, testu-fitxategi moduan bizi dira, GIT-en gordetzen dira, pull request adarrak, hau guztia. Alde txarrari dagokionez, duela urte asko ez du beta egoera utzi, nahiz eta bertsio bakoitzean hobetzen ari den. Ez dut EDTren desabantailei buruz idatziko, gaur minus bat da, bihar funtzio finko bat da. Deskribapen horren garrantzia azkar desagertuko da. Gaur egun, EDT-n garatzea posible da, baina ezohikoa da IDE akats kopuru jakin baterako prestatuta egotea.
Aipatutako “1C prismaren bitartez” egoera ikusten baduzu, honelako zerbait lortzen duzu: IDE berriaren kaleratzeak ez ditu kutxen salmentak handitzen, baina GARATZAILEen irteera murriztu daiteke. Zaila da esatea zer itxaroten duen ekosistema garatzaileen erosotasunari dagokionez, baina Microsoft-ek dagoeneko izorratu ditu mugikorreko garatzaileak bere zerbitzuak beranduegi eskainiz.
Garapenaren kudeaketa
Hemen dena nabarmen hobea da kodea idazten baino, batez ere duela gutxi, komunitatearen ahaleginak administrazioaren automatizazioaren arazoak azaleratu zituenean, 1C biltegia zaborrontzira botatzeko eta git erabiliz, errua azkarra, kodea-berrikustea eskatzen zuten prototipoak abiarazi zituen. , analisi estatikoa, hedapen automatikoa eta abar. Garapen-zereginen automatizazio-maila handitzen duten plataformari eginbide asko gehitu zaizkio. Hala ere, ezaugarri hauek guztiak gure produktu handien garapenerako bakarrik eta esklusiboki gehitu ziren, automatizaziorik gabe ezin genuela egin agerikoa zenean. Batze automatikoak zeuden, hiru norabideko konparaketa KDiff-ekin eta guzti. Github-en abiarazi da , egia esanda, ideologikoki proiektutik urrundu zuten , baina enpresa saltzaileen prozesuetara egokitzeko aldatua. Kode irekiko tipo burugogorrei esker, 1C-ko garapenaren automatizazioa martxan jarri zen. Konfiguratzailerako API ireki batek, IMHO, IDE nagusiaren atzerapen morala ere aldatuko luke.
Gaur egun, 1C iturriak git-en gordetzea Jira-n arazoei lotutako konpromisoekin, Crucible-n berrikuspenekin, Jenkins-en sakatu-botoia eta Allure-ren txostenak 1C-n kode-probari buruz eta are gehiago. - Albisteetatik urrun dago hau, 1C garapen handia duten enpresetan nagusiena baizik.
Administrazioa
Hemen asko dago esateko. Lehenik eta behin, hau zerbitzari bat da (1C zerbitzari-kluster). Gauza zoragarria, baina kutxa guztiz beltza dela eta, xehetasun nahikoz dokumentatua, baina modu zehatz batean - karga handiko moduan hainbat zerbitzaritan etenik gabeko funtzionamendua abian jartzea menderatzea da. domina “Gai teknologikoetan aditua” inskripzioarekin. Aipatzekoa da, printzipioz, 1C zerbitzari bat administratzea ez dela desberdina beste edozein zerbitzari administratzea. Sarean oinarritutako eta hari anitzeko aplikazio bat da, memoria, CPU eta disko baliabideak kontsumitzen dituena. Telemetria biltzeko eta diagnostikatzeko aukera zabalak eskaintzen ditu.
Hemen arazoa da saltzaileak ez duela ezer berezirik eskaintzen diagnostiko honetarako prest dauden irtenbideei dagokienez. Bai, badago 1C: Instrumentation and Control Center, nahiko onak ere badira, baina oso garestiak dira eta denek ez dituzte. Komunitatean garapen ugari daude Grafana, Zabbix, ELK eta beste gauza batzuk administratzaile estandarretik konektatzeko, baina ez dago gehiengoari egokituko zaion irtenbide bakarra. Zereginak bere heroiaren zain dago. Eta 1C kluster batean abiarazteko asmoa duen enpresa bat bazara, Aditu bat behar duzu. Zure barrutik edo kanpotik, baina behar duzu. Normala da zerbitzariaren funtzionamendurako gaitasunekin aparteko rol bat egotea, 1C erabiltzaile guztiek ez lukete hori jakin behar, rol hori beharrezkoa dela ulertu behar duzu. Har dezagun SAP adibidez. Bertan, programatzaile bat, ziurrenik, ez da bere aulkitik altxatuko ere aplikazioen zerbitzarian zerbait konfiguratzeko eskatzen badiote. Baliteke ergela izatea eta ez du lotsatuko. SAP metodologian langileen rol bereizia dago horretarako. Arrazoiren batengatik, 1C industrian uste da hau langile bakarrean konbinatu behar dela soldata berdinarekin. Eldarnio bat da.
1C zerbitzariaren desabantailak
Minus bat dago: fidagarritasuna. Edo, nahiago baduzu, ezustekoa. Zerbitzariaren bat-bateko jokaera arraroa dagoeneko hizpide bihurtu da. Erremedio unibertsala -zerbitzaria gelditzea eta cache guztiak garbitzea- ere deskribatzen da adituaren eskuliburuan, eta hori egiteko batch liburu bat ere gomendatzen da. Zure 1C sistema teorikoki egin behar ez lukeen zerbait egiten hasten bada, saioko datuen cachea garbitzeko garaia da. Nire kalkuluen arabera, herrialde osoan hiru pertsona baino ez daude 1C zerbitzari bat prozedura hori gabe funtzionatzen dakitenak eta ez dute sekreturik partekatzen, zeren... honetatik bizi dira. Beharbada haien sekretua da saioko datuak garbitzen dituztela, baina ez diotela inori esaten, lagun.
Bestela, 1C zerbitzaria beste edozein aplikazio bera da eta modu berean administratzen da, dokumentazioa irakurriz eta panderoa joz.
Docker
Produkzioan edukiontzidun 1C zerbitzari bat erabiltzearen erabilgarritasuna oraindik ez da frogatu. Zerbitzaria ez da multzokatzen orekatzailearen atzean nodoak gehituz, eta horrek ekoizpenaren edukiontziaren abantailak gutxienera murrizten ditu, eta karga handiko moduan edukiontzietan funtzionamendu arrakastatsua praktikatzea ez da ezarri. Ondorioz, garatzaileek soilik erabiltzen dute Docker+1C proba-inguruneak konfiguratzeko. Bertan oso erabilgarria da, aplikatua, teknologia modernoekin jolasteko eta konfiguratzailearen atsedenalditik atseden hartzeko aukera ematen du.
Osagai komertziala
Inbertsioaren ikuspuntutik, 1C-k negozio ideiak azkar abiarazteko arazoa konpontzeko aukera ematen du, aplikazio klaseen gaitasun zabalak direla eta. Kutxatik kanpo 1C-k Txostenak oso duinak ematen ditu, edozertarako integrazioa, web bezeroa, bezero mugikorra, aplikazio mugikorra, hainbat DBMSrako laguntza, barne. doakoa, plataforma anitzekoa, bai zerbitzariaren eta baita instalatutako bezeroaren zatiak. Bai, aplikazioen interfazea horia izango da, batzuetan hori ken bat da, baina ez beti.
1C aukeratuz, negozio batek software-soluzio multzo bat lortzen du, aplikazio sorta oso zabala eraikitzeko aukera ematen diena, baita javaistek baino diru gutxiago nahi duten eta, aldi berean, emaitzak azkarrago ekoizten dituzten merkatuko garatzaile asko ere.
Adibidez, bezero bati PDF faktura bidaltzeko zeregina ikasleen lan ordu batean konpon daiteke. .NET-en arazo bera liburutegi jabedun bat erosiz edo pare bat egun edo astez kodetuz konpon daiteke garatzaile zorrotz eta bizardun batek. Batzuetan, biak batera. Eta bai, PDF sorrerari buruz bakarrik ari nintzen. Ez dugu esan faktura hau nondik aterako den ere. Web frontender-ak inprimaki bat sortu behar du, non operadoreak datuak sartuko dituen, backender-ak JSON transferitzeko dto ereduak sortu beharko ditu, datu-basean gordetzeko ereduak, datu-basearen egitura bera, bertara migratzea, grafiko baten eraketa. Kontu honen bistaratzea, eta orduan bakarrik - PDF. 1C-n, zeregin osoa, hutsetik, ordubetean betetzen da.
Erosi/saldutako negozio-prozesu bakarra duen postu txiki baten kontabilitate-sistema osoa 3 ordutan egiten da salmenten txostenekin, salgaien erosketa-prezioen kontabilitatea, biltegiaren arabera banatuta, sarbide-eskubideen kontrola, web-bezeroa eta aplikazio mugikorrarekin. . Ados, aplikazioa ahaztu zait, aplikazioarekin ez 3 ordutan, sei barru.
Zenbat denbora beharko du zeregin honek .NET garatzaile batek ikus-estudioa ordenagailu garbi batean instalatzetik bezeroari erakusteko? Zer gertatzen da garapenaren kostuarekin? Gauza bera.
1C-ren indarguneak plataforma gisa
1C indartsua da, ez munduko onena den zerbait zehatza dagoelako. Aitzitik, banakako azpisistema bakoitzean analogo interesgarriago bat aurki dezakezu munduko softwarean. Hala ere, faktoreen konbinazioan oinarrituta, ez dut 1C-ren antzeko plataformarik ikusten. Hor dago arrakasta komertziala. Plataformaren abantailak bertan sakabanatuta daude eta hori beste plataforma batzuetan nola egiten den ikusten duzunean ikusten dira argien. Funtsean, hauek EZ dira ezaugarriak ere, aitzitik, ezaugarriak baztertzea paradigma zehatz baten alde. Adibide batzuk:
- Unicode. Zer demontre izan liteke sinpleagoa? Ez dago 2019an byte bakarreko ASCII kodeketak erabili beharrik (oinarrizko antzinakoekin integratzeko izan ezik). Inoiz ez. Baina ez. Dena den, taula bateko norbaitek byte bakarreko varchar bat erabiltzen du eta aplikazioak arazoak izango ditu kodeketekin. 2015ean, gitlab-en LDAP baimenak huts egin zuen kodeketekin lan okerrengatik JetBrains IDE-k oraindik ez du funtzionatzen zirilikoarekin fitxategi-izenetan. 1C-k kalitate handiko aplikazio-kodearen isolamendua eskaintzen du datu-basearen geruzatik. Bertan ezinezkoa da taulak maila baxuan idaztea eta datu-base mailan ezinezkoak dira junior ezgaien jambak bertan. Bai, baliteke beste arazo batzuk egotea junior ezgaiekin, baina arazoen barietatea askoz txikiagoa da. Orain esango didazu zure aplikazioa behar bezala diseinatuta dagoela eta datu-baserako sarbidea behar den moduan isolatuta dagoela. Eman beste begirada bat zure korporazioko Java aplikazio pertsonalizatuari. Gertutik eta zintzotasunez. Zure kontzientziak molestatzen zaitu? Orduan pozten naiz zuregatik.
- Dokumentuen/erreferentzia-liburuen zenbakitzea. 1C-n, zalantzarik gabe, ez da malguena eta ez onena. Baina banku-softwarean eta norberak idatzitako kontabilitate sistemetan egiten dutena - tira, iluntasuna besterik ez da. Edo identitatea itsatsita geratuko da (eta gero “oh, zergatik ditugu zuloak”), edo aitzitik, DBMS mailan blokeoarekin lan egiten duen sorgailu bat egingo dute (eta botila-lepo bihurtuko da). Izan ere, nahiko zaila da itxuraz sinplea den zeregin hori egitea: entitateen amaieratik amaierako zenbatzailea, gako multzo jakin batean oinarritutako berezitasun atala duena, aurrizkia, datu-basea blokeatu ez dezan datu paraleloan sartzean. .
- Datu-baseko erregistroen identifikatzaileak. 1C-k erabaki sendoa hartu zuen: esteka-identifikatzaile guztiak guztiz sintetikoak dira eta kitto. Eta datu-base eta truke banatuekin ez dago arazorik. Beste sistema batzuen garatzaileek identitate antzeko zerbait sortzen dute (motzagoa da!), arrastatu GUIra erlazionatutako hainbat instantzia sortzeko garaia iritsi arte (eta orduan deskubrituko dira). Ez al duzu hau? Egia esan?
- Zerrendak. 1C-k nahiko mekanismo arrakastatsuak ditu zerrendetan (handiak) orrialdean ibiltzeko eta horietan nabigatzeko. Utzidazu erreserba bat egin berehala - mekanismoaren erabilera zuzenarekin! Orokorrean, gaia nahiko desatsegina da, ezin da modu egokian konpondu: edo intuitiboa eta sinplea da (baina bezeroaren erregistro-multzo handiak izateko arriskua), edo orrialdea bihurgune bat edo bestekoa da. Orrialdeak egiten dituztenek oker egiten dute askotan. Desplazamendu-barra zintzoa egiten dutenek datu-base bat, kanal bat eta bezero bat gehitzen dituzte.
- Kudeatutako inprimakiak. Zalantzarik gabe, web bezeroan interfazeak ez du primeran funtzionatzen. Baina funtzionatzen du. Baina beste kontabilitate eta banku sistema askorentzat, urruneko lantokia sortzea enpresa mailako proiektu bat da. Oharra: zorionez, hasiera batean webean egin zutenentzat, honek ez du eraginik izango.
- Mugikorreko aplikazioa. Duela gutxi, mugikorreko aplikazioak ere idatzi ditzakezu ekosistema berean zaudela. Hemen web bezero batekin baino pixka bat konplikatuagoa da gailuen berezitasunak berariaz idaztera behartzen zaitu, baina, hala ere, ez duzu mugikorren garatzaile talde bat kontratatzen. Enpresa baten barneko beharretarako aplikazio bat behar baduzu (arazo korporatibo baten konponbide mugikorra UI diseinu horia baino garrantzitsuagoa denean), plataforma bera erabili besterik ez duzu.
- Txostenak ematea. Hitz honekin ez dut esan nahi big data eta ETL prozesuan atzerapena duen BI sistema bat. Honek kontabilitate-egoera hemen eta orain ebaluatzeko aukera ematen duten langile operatiboen txostenei egiten die erreferentzia. Balantzeak, elkarren arteko likidazioak, birkalifikazioak, etab. 1C kutxatik ateratzen da erabiltzailearen aldetik taldekatze, iragazkiak eta bistaratzeko ezarpen malguak dituen txosten sistema batekin. Bai, merkatuan analogo freskoagoak daude. Baina ez guzti-bateko soluzio baten esparruan eta, batzuetan, oso-osoko soluzio batek baino prezio handiagoan. Eta maizago ere alderantziz gertatzen da: salaketa soilik, baina plataforma osoa baino garestiagoa, eta kalitatez okerragoa.
- Inprimatzeko inprimakiak. Tira, erabili .NET langileei posta elektronikoz soldata-agiriak PDFan bidaltzearen arazoa konpontzeko. Eta orain fakturak inprimatzeko zeregina. Zer gertatzen da haien kopiak PDF berean gordetzea? 1C goitizenarentzat, edozein diseinu PDFra ateratzea kode-lerro +1 da. Horrek esan nahi du + 40 segundoko lanaldia, beste hizkuntza batean egun edo asteen ordez. 1C-n inprimatutako inprimakien diseinuak garatzeko oso errazak dira eta nahikoa indartsuak dira ordaindutako kontrakoekin lehiatzeko. Bai, ziurrenik, ez dago aukera interaktibo asko 1C kalkulu-orriko dokumentuetan ezin duzu azkar lortu 3D diagrama OpenGL erabiliz. Baina benetan beharrezkoa al da?
Adibide batzuk besterik ez dira, non funtzionaltasuna mugatzea edo konpromisoak ezartzea etorkizunean onura arkitektoniko garrantzitsua izango den. Nahiz eta konpromisoa edo ez aukera eraginkorrena - dagoeneko kutxan dago eta beretzat hartzen da. Haren inplementazio independentea ezinezkoa izango da (proiektuaren hasieran hartu behar direlako erabakiak, eta ez dago horretarako denborarik, eta ez dago inolako arkitektorik), edo hainbat iterazio garesti. Zerrendatutako puntu bakoitzean (eta hau ez da irtenbide arkitektonikoen zerrenda osoa), eskalatzea blokeatzen duten murrizketak izorratu eta sartu ditzakezu. Edonola ere, zuk, enpresari gisa, ziurtatu behar duzu zure programatzaileek, "hutsetik sistema" bat egiterakoan, esku zuzenak dituztela eta sistemaren arazo sotilak berehala ondo egingo dituztela.
Bai, beste edozein sistema konplexutan bezala, 1C-k berak ere baditu zenbait alderditan eskalatzea blokeatzen duten irtenbideak. Hala ere, errepikatzen dut, faktoreen konbinazioan, jabetza-kostuan eta aurrez konpondutako arazoen kopuruan oinarrituta, ez dut merkatuan lehiakide duin bat ikusten. Prezio berdinarekin, finantza-aplikazioen esparrua, klusteratutako zerbitzari orekatua, UI eta web interfazearekin, mugikorrentzako aplikazio batekin, txostenekin, integrazioarekin eta beste gauza askorekin lortzen duzu. Java munduan, front-end eta back-end talde bat kontratatzen duzu, etxean idatzitako zerbitzari-kodeen maila baxuko multzoak arazketa eta bereizita ordaintzen dituzu 2 mugikorretarako 2 aplikazio mugikorretarako.
Ez dut esaten 1C-k kasu guztiak konponduko dituenik, baina barneko aplikazio korporatibo baterako, interfazearen marka jarri beharrik ez dagoenean - zer gehiago behar da?
Pomada hegan
Seguruenik, 1C-k mundua salbatuko duela eta korporazio-sistema idazteko beste modu guztiak okerrak direla irudituko zaizu. Ez da batere horrela. Enpresaburuaren ikuspuntutik, 1C aukeratzen baduzu, merkaturatzeko denbora azkarraz gain, honako desabantaila hauek hartu behar dituzu kontuan:
- Zerbitzariaren fidagarritasuna. Benetan kalitate handiko espezialistak behar dira, bere etenik gabeko funtzionamendua ziurtatzeko. Ez dut ezagutzen saltzaileen espezialistentzako prestaturiko prestakuntza-programarik. Aditu azterketa prestatzeko ikastaroak daude, baina hau, nire ustez, ez da nahikoa.
- Laguntza. Ikus aurreko puntua. Saltzailearen laguntza izateko, erosi behar duzu. Zerbaitegatik ez da hori onartzen 1C industrian. Eta SAPekin, ia ezinbesteko erosketa da eta ez du inor molestatzen. Enpresen laguntzarik gabe eta langileen aditurik gabe, bakarrik gera zaitezke 1C akatsekin.
- Hala ere, ezin duzu dena egin 1C-rekin. Hau tresna bat da eta tresna guztiek bezala aplikagarritasun-mugak ditu. 1C paisaian, oso desiragarria da "1C ez den" sistemaren arkitekto bat izatea.
- 1C goitizen onak ez dira beste hizkuntza batzuetako programatzaile onak baino merkeagoak. Programatzaile txarrak kontratatzea garestia den arren, idazten duten hizkuntza edozein dela ere.
Puntu ditzagun puntuak
- 1C negozioetarako aplikazioen garapen azkarra (RAD) esparru bat da eta horretarako diseinatuta dago.
- Hiru mailatako esteka DBMS nagusien laguntzarekin, bezeroaren interfazea, ORM oso ona eta txostenak
- 1C-k ezin duena egin dezaketen sistemekin integratzeko aukera zabalak. Ikaskuntza automatikoa nahi baduzu, hartu Python eta bidali emaitza 1Cra http edo RabbitMQ bidez
- Ez dago 1C erabiliz dena egiten ahalegindu beharrik, bere indarguneak ulertu eta zure helburuetarako erabili behar dituzu.
- Esparru teknologikoko tramankuluetan murgiltzen eta N urtean behin motor berri batera diseinatzen duten garatzaileak aspertuta daude 1C-rekin. Han dena oso kontserbadorea da.
- Garatzaileak ere aspertuta daude fabrikatzailearengandik oso kezka gutxi daudelako. Hizkuntza aspergarria, IDE ahula. Modernizazioa eskatzen dute.
- Bestalde, gozatzen duten beste teknologia bat erabiliz eta ikasiz dibertigarria aurkitu ezin duten garatzaileak garatzaile txarrak dira. Irruka egingo dute eta beste ekosistema batera joango dira.
- 1C ezizenei Python-en zerbait idazten uzten ez dieten enpresaburuak enpresaburu txarrak dira. Adimen jakintsua duten langileak galduko dituzte, eta haien ordez tximino-kodetzaileak etorriko dira, denarekin ados dauden bitartean, software korporatiboa padurara arrastaka eramango dutenak. Oraindik berridatzi beharko da, beraz, agian hobe litzateke Python-en pixka bat lehenago inbertitzea?
- 1C merkataritza-enpresa bat da eta bere interesetan eta komenientzian oinarritutako funtzioak ezartzen ditu. Ezin diozu horren errua leporatu, negozioak irabazietan pentsatu behar du, hori da bizitza
- 1C-k dirua irabazten du negozio-arazoei irtenbideak salduz, ez Vasyaren garatzaileen arazoei. Bi kontzeptu hauek erlazionatuta daude, baina lehentasuna esan dudana da. Vasya garatzailea 1C: Resharper lizentzia pertsonal bat ordaintzeko prest dagoenean, nahiko azkar agertuko da, A. Orefkova-ren "Resharper" horren froga da. Saltzaileak onartzen bazuen, eta horren aurka borrokatuko ez balu, garatzaileentzako software merkatu bat agertuko litzateke. Orain jokalari bat eta erdi daude merkatu honetan emaitza zalantzagarriak dituztenak, eta guztia IDEarekin integrazioa negatiboa delako eta dena makuluekin egiten delako.
- Makina anitzeko operadorearen praktika ahanzturan desagertuko da. Aplikazio modernoak handiegiak dira bai kodearen aldetik bai negozioaren erabileraren aldetik gogoratzeko. 1C zerbitzaria ere gero eta konplexuagoa da, ezinezkoa izango da esperientzia mota guztiak edukitzea langile batean. Horrek espezialisten eskaria ekarri beharko luke, hau da, 1C lanbidearen erakargarritasuna eta soldaten igoera. Lehen Vasyak soldata baten truke hiru batean lan egiten bazuen, orain bi Vasya kontratatu behar dituzu eta Vasyasen arteko lehiak mailaren hazkunde orokorra bultzatu dezake.
Ondorioa
1C oso produktu merezi du. Nire prezioen tartean, ez dut analogikorik ezagutzen, idatzi iruzkinetan baldin badago. Hala ere, ekosistematik garatzaileen irteera gero eta nabarmenagoa da, eta hori “garunak ihesa” da, nola begiratu ere. Industria modernizatzeko gosea da.
Garatzailea bazara, ez zintzilikatu 1C-n eta ez pentsa dena magikoa denik beste hizkuntza batzuetan. Gaztetxoa zaren bitartean, agian. Zerbait handiagoa konpondu behar den bezain laster, prest dauden irtenbideak luzeago bilatu eta intentsiboago osatu beharko dira. Soluzio bat eraiki daitekeen "blokeen" kalitateari dagokionez, 1C oso-oso ona da.
Eta beste gauza bat: 1C ezizena kontratatzera etortzen bazaizu, orduan 1C ezizena segurtasunez izenda daiteke analista nagusien kargurako. Ataza, gai-arloa eta deskonposizio-trebetasunak ulertzea bikaina da. Ziur nago hori, hain zuzen, 1C garapenean DDD-ren erabilera behartua dela eta. Pertsona lehenik eta behin atazaren esanahia pentsatzeko trebatzen da, gai-arloko objektuen arteko loturei buruz, eta, aldi berean, integrazio-teknologietan eta datu-truke formatuetan aurrekari teknikoa du.
Kontuan izan esparru ideala ez dela existitzen eta zaindu zeure burua.
Onena!
PS: eskerrik asko artikulua prestatzen laguntzeko.
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
1C al duzu zure enpresan?
-
13,3%Batere ez.71
-
30,3%Bada, baina kontabilitate sailean bakarrik nonbait. Beste plataforma batzuetan oinarrizko sistemak162
-
41,4%Bai, negozio prozesu nagusiek horretan lan egiten dute221
-
15,0%1C hil behar da, etorkizuna %technology_name%80rena da
534 erabiltzailek eman dute botoa. 99 erabiltzaile abstenitu ziren.
Iturria: www.habr.com