1C - Bono kaj malbono. Aranĝo de punktoj en holivaroj ĉirkaŭ 1C

Amikoj kaj kolegoj, lastatempe estis pli oftaj artikoloj pri Habré kun malamo al 1C kiel evoluplatformo, kaj paroladoj de ĝiaj defendantoj. Tiuj ĉi artikoloj identigis unu gravan problemon: plej ofte, kritikistoj de 1C kritikas ĝin el la pozicio de "ne regi ĝin", riproĉi problemojn, kiuj estas fakte facile solvitaj, kaj, male, ne tuŝi problemojn kiuj estas vere gravaj, indaj. diskutante kaj ne estas solvitaj de la vendisto. Mi kredas, ke havas sencon fari sobran kaj ekvilibran revizion de la platformo 1C. Kion ĝi povas fari, kion ĝi ne povas fari, kion ĝi devus fari sed ne faras, kaj, kiel deserto, kion ĝi faras kun bruego, kaj viaj programistoj ĉe %technology_name% faros cent jarojn, forĵetante ĝin. pli ol unu jara buĝeto.

Kiel rezulto, vi, kiel administranto aŭ arkitekto, povos akiri klaran komprenon pri kia tasko estos utila por vi uzi 1C, kaj kie ĝi devas esti forbruligita per varma fero. Kiel programisto en la "ne-1C" mondo, vi povos vidi kio estas en 1C, kio kaŭzas tumulton. Kaj kiel programisto 1C, vi povos kompari vian sistemon kun la ekosistemoj de aliaj lingvoj kaj kompreni vian lokon en la koordinata sistemo de programaro.

Sub la tranĉo estas multaj dikaj atakoj kontraŭ 1C, kontraŭ kritikantoj de 1C, kontraŭ Java, .NET kaj ĝenerale... La ventumilo estas plena, bonvenon!

Pri mi

Mi konas la temon de konversacio ekde proksimume 2004. Mi programas verŝajne ekde mi 6-jara, ekde la sama momento mi ricevis libron pri profesoro Fortran kun bildstrioj pri kato, pasero kaj raŭpo. Mi analizis la programojn, kiujn la kato skribis el la bildoj en la libro kaj eksciis, kion ili faris. Kaj jes, mi tiam ne havis veran komputilon, sed estis desegnaĵo pri la disvastigo de la libro kaj mi sincere premis la paperajn butonojn, enigante la ordonojn, kiujn mi spionis al la kato X.

Poste estis BK0011 kaj BASIC en la lernejo, C++ kaj asembleroj en universitato, poste 1C, kaj tiam tiom da aliaj aferoj, kiujn mi tro mallabore memoras. Dum la lastaj 15 jaroj, mi ĉefe okupiĝas pri 1C, ne nur pri kodigo, sed pri 1C ĝenerale. Fiksante taskojn, administradon kaj devopojn ĉi tie. Dum la lastaj 5 jaroj mi okupiĝas pri socie utilaj agadoj koncerne evoluigadon kaj aŭtomatigajn ilojn por aliaj 1C-uzantoj, verkante artikolojn kaj librojn.

Ni decidu pri la temo de diskuto

Unue, ni difinu, pri kio ni parolos, ĉar la literoj "1C" povas signifi multajn aferojn. En ĉi tiu kazo, per la literoj "1C" ni signifos ekskluzive la disvolvan kadron "1C: Enterprise" de la moderna, oka versio. Ni ne multe parolos pri la fabrikanto kaj ĝiaj politikoj (sed ni devos fari iomete) Ni ne diskutos specifajn aplikojn skribitajn per ĉi tiu kadro. Teknologio estas aparta, aplikoj alinome agordoj estas apartaj.

Altnivela arkitekturo 1C: Enterprise

Ne vane mi mencias la vorton "kadro". De la vidpunkto de programisto, la platformo 1C estas ĝuste kadro. Kaj vi devas trakti ĝin ĝuste kiel kadro. Pensu pri ĝi kiel Spring aŭ ASP.NET, ekzekutita de iu rultempo (JVM aŭ CLR respektive). Okazas, ke en la mondo de konvencia programado ("ne 1C"), la divido en kadroj, virtualaj maŝinoj kaj specifaj aplikoj estas natura, pro la fakto, ke ĉi tiuj komponantoj estas kutime evoluigitaj de malsamaj fabrikantoj. En la 1C-mondo, estas ne kutime distingi la evoluokadron kaj rultempon mem; krome, specifaj aplikoj skribitaj uzante la kadron ankaŭ estas plejparte evoluigitaj fare de 1C mem. Kiel rezulto, iu konfuzo ekestas. Tial, en la kadro de la artikolo, ni devos konsideri 1C de pluraj flankoj samtempe kaj klasifiki ĝin laŭ pluraj koordinataj aksoj. Kaj en ĉiu koordinata akso ni metos ŝovelilon el bruna substanco kaj rigardos la trajtojn, avantaĝojn kaj malavantaĝojn de la ekzistanta solvo.

Vidpunktoj pri 1C

1C por la aĉetanto

La aĉetanto aĉetas aŭtomatigan sistemon, per kiu li povas rapide solvi la problemojn pri aŭtomatigo de sia propra komerco. Komerco povas esti malgranda budo, aŭ ĝi povas esti granda holdingo. Estas klare, ke la bezonoj de ĉi tiuj entreprenoj estas malsamaj, sed ambaŭ estas subtenataj de ununura platforma kodbazo.

Por la aĉetanto de 1C ĉi tio estas rapida merkata tempo. Rapide. Pli rapide ol Java, C# aŭ JS. Averaĝa. Ĉirkaŭ la hospitalo. Estas klare, ke vizitkarta retejo uzanta React pliboniĝos, sed la backend de WMS-sistemo lanĉos pli rapide sur 1C.

1C kiel ilo

Ĉiu teknologia solvo havas limojn de aplikebleco. 1C ne estas ĝeneraluzebla lingvo; ĝi ne vivas aparte de sia kadro. Estas rekomendinde uzi 1C kiam vi bezonas:

• servila aplikaĵo
• aplikaĵo kie aperas financoj
• kun preta UI, ORM, Raportado, XML/JSON/COM/PDF/YourDataTransferingFormat
• kun subteno por fonaj procezoj kaj laboroj
• kun rol-bazita sekureco
• kun skribebla komerca logiko
• kun la kapablo rapide krei prototipon kaj malaltan tempo-merkatigon

Vi ne bezonas 1C se vi volas:

• maŝinlernado
• GPU-kalkuloj
• komputila grafiko
• matematikaj kalkuloj
• CAD-sistemo
• signal-prilaborado (sono, vidbendo)
• altŝarĝaj http-vokoj kun centoj da miloj da rps

1C kiel produktadfirmao

Indas kompreni, kio estas la komerco de 1C kiel fabrikanto de programaro. 1C-firmao vendas solvojn al komercaj problemoj per aŭtomatigo. Malsamaj entreprenoj, grandaj aŭ malgrandaj, sed tion ŝi vendas. La rimedoj por atingi ĉi tiun celon estas komercaj aplikoj. Por kontado, etata kontado, ktp. Por skribi ĉi tiujn aplikojn, la kompanio uzas sian propran komercan aplikaĵan evoluplatformon. Speciale tajlorita por oftaj taskoj de ĉi tiuj samaj komercaj aplikoj:

• financa kontado
• facila personigo de komerca logiko
• larĝaj integriĝaj eblecoj en heterogenaj IT-pejzaĝoj

Kiel fabrikanto, 1C kredas, ke ĉi tiu estas la strategio, kiu permesas vin labori kun partneroj kaj klientoj en gajna-gajna reĝimo. Vi povas argumenti pri tio, sed ĉi tio estas proksimume kiel la firmao promocias sin: pretaj solvoj al komercaj problemoj, kiuj povas esti rapide personecigitaj de partneroj kaj integritaj en ajnan IT-pejzaĝon.

Ĉiuj asertoj aŭ deziroj pri 1C kiel kadro devus esti rigardataj ekskluzive per ĉi tiu prismo. "Ni volas OOP en 1C," diras la programistoj. "Kiom kostos al ni subteni OOP en la platformo, ĉu ĉi tio helpos nin pliigi vendojn de skatoloj?" diras 1C. Malfermas sian "prismon" vendi solvojn al komercaj problemoj:

- Hej, komerco, ĉu vi volas OOP en via 1C?
- Ĉu ĉi tio helpos min solvi miajn problemojn?
- Kiu scias...
- Tiam ne necesas

Ĉi tiu aliro povas esti bona aŭ malbona depende de kiu rigardas ĝin, sed tiel ĝi estas. Parolante pri la fakto, ke ne ekzistas trajto X en 1C, vi devas kompreni, ke ĝi ne ekzistas pro kialo, sed en la kunteksto de la elekto "kosto de efektivigo kontraŭ profito kvanto".

Teknologia klasifiko

"Fakte, Odinesniks faras sian eblon por uzi la plej bonajn ŝablonojn, zorge elektitajn de zorgemaj metodistoj kaj programistoj de la platformo 1C.
Kiam vi skribas vian stultan kodon por simpla administrita formo, fakte vi uzas modelo-vido-regilo с dudirekta ligado de datumoj в tri-tavola-datuma-ap-motoro, gustigita altnivela objekto-rilato-mapado sur la bazo deklara priskribo de metadatenojhavanta sian propran platform-sendependa demandlingvo, c deklara uzantinterfaco de datumoj, kompleta travidebla seriigo kaj domajna programlingvo.

Kie 1C-programistoj diferencas de siaj okcidentaj kolegoj estas en PR. Ili amas doni al iu ajn fiaĵo grandan nomon kaj kuri kun ĝi kiel malpura sako."
A. Orefkov

La 1C-platformo havas klasikan 3-nivelan arkitekturon, en kies centro estas la aplikaĵoservilo (aŭ ĝia emulado por malmulte da mono por malgrandaj butikistoj). Aŭ MS SQL aŭ Postgres estas uzataj kiel DBMS. Ankaŭ ekzistas subteno por Oracle kaj IBM DB2, sed ĉi tio estas sufiĉe esotera; neniu scias, kio okazos se vi efektivigos 1C sur ĉi tiuj datumbazoj sub meza kaj alta ŝarĝo. Mi kredas, ke 1C mem ne scias ĉi tion.

La klientparto estas aŭ maldika kliento instalita sur la maŝino de la uzanto aŭ retkliento. La ĉefa funkcio estas, ke programistoj ne skribas 2 malsamajn kodojn, ili skribas unu aplikaĵon, en unu lingvo, kaj vi povas montri ĝin en la retumilo se estas deziro aŭ bezono. Kiu deziris veran plenan stakon kaj ununuran lingvon por la fronto kaj backend, node.js? Ili neniam sukcesis fari ĝuste la samon ĝis la fino. Vera plena stako ekzistas, sed vi devos skribi ĝin en 1C. La ironio de la sorto, tiaj aferoj :)

La nuba SaaS-solvo 1C:Fresh ankaŭ funkcias en retumila reĝimo, en kiu vi ne povas aĉeti 1C, sed lui malgrandan datumbazon kaj konservi trakon de shawarma vendo tie. Nur en la retumilo, sen instali aŭ agordi ion ajn.

Krome, ekzistas hereda kliento, kiu en 1C nomiĝas "regula aplikaĵo". Heredaĵo estas heredaĵo, bonvenon al la mondo de aplikaĵoj en 2002, sed ni ankoraŭ parolas pri la nuna stato de la ekosistemo.

La 1C servila parto subtenas clustering kaj skvamoj aldonante novajn maŝinojn al la areto. Sufiĉe multaj kopioj estas rompitaj ĉi tie kaj estos aparta sekcio en la artikolo pri tio. Resume, ĉi tio ne estas tute sama kiel aldoni kelkajn ekzakte la samajn okazojn malantaŭ HAProxy.

La aplikaĵa disvolva kadro uzas sian propran programlingvon, kiu proksimume similas iomete plibonigitan VB6 tradukitan en la rusan. Por homoj, kiuj malamas ĉion rusan, kiuj ne kredas, ke "se" estas tradukita kiel "se", la dua sintaksa opcio estas ofertita. Tiuj. Se vi deziras, vi povas skribi ĝin en 1C tiel, ke ĝi estas nedistingebla de VB.

Ĉi tiu mem programlingvo estas la ĉefa kialo de la malamo de 1C-moknomoj kontraŭ ilia platformo. Ni alfrontu ĝin, ne sen kialo. La lingvo estis konceptita kiel eble plej simpla, desegnita por plenumi la mantron "PROPLAĜISTOJ, PROGRAMAJ" en skalo almenaŭ en la CIS. La komerca esenco de tia solvo, laŭ mi, estas klare videbla: pli da programistoj, pli granda merkata kovrado. Ĉi tio realiĝis, laŭ diversaj taksoj de 45% ĝis 95%. Mi tuj diros, ke skribi en la lingvo, kiun vi opinias, estas vere pli facila. Kaj mi konas sufiĉe multajn programlingvojn.

Ni komencu per la lingvo.

1C programlingvo

Samtempe la forta kaj malforta punkto de la sistemo. Provizas facilan eniron kaj legeblecon. Aliflanke, ĝi ne estis ĝisdatigita ekde la publikigo de versio 8 en 2002 kaj estas morale malaktuala. Iu diros "la ĉefa malavantaĝo estas, ke ne ekzistas OOP" kaj ili malpravos. Unue, la OLP ne ŝatas ne nur Nuraliev, sed ankaŭ Torvalds. Kaj due, OOP ankoraŭ ekzistas.

El la vidpunkto de la programisto, li havas je sia dispono kadron kun bazaj klasoj montritaj sur la DBMS. La programisto povas preni la bazan klason "Adresaro" kaj heredi la dosierujon "Klientoj" de ĝi. Ĝi povas aldoni novajn klaskampojn al ĝi, ekzemple, INN kaj Adreso, kaj ankaŭ, se necese, ĝi povas anstataŭi (anstataŭigi) metodojn de la baza klaso, ekzemple, la OnWrite/AtRecord-metodo.

La kadro estas desegnita tiel ke pli profunda heredo malofte necesas, kaj la limigo en OOP, laŭ mi, havas sencon. 1C fokusiĝas al Domajna Disvolvita Disvolviĝo kaj igas vin pensi, antaŭ ĉio, pri la temo de la evoluiga solvo, kaj ĉi tio estas bona. Ne nur ne estas tento, sed ankaŭ ne necesas skribi 10 malsamajn DTO-ojn kaj ViewModelojn nur por montri iujn datumojn de la domajno ie. La programisto 1C ĉiam funkcias kun unu ento, sen malordigi la kuntekston de percepto kun dekduo da klasoj kun similaj nomoj, reprezentante la saman enton, sed de malsama flanko. Ajna aplikaĵo .NET, ekzemple, nepre enhavos kvin aŭ du VidModelojn kaj DTOojn por seriigo en JSON kaj transdono de datumoj de kliento al servilo. Kaj proksimume 10-15% de via aplika kodo estos elspezitaj por transloki datumojn de unu klaso al alia uzante plumojn aŭ lambastonojn kiel AutoMapper. Ĉi tiu kodo devas esti skribita kaj programistoj devas esti pagitaj por krei kaj konservi ĝin.

Montriĝas, ke la lingvo 1C malfacilas disvolvi sen kompliki ĝin al la nivelo de ĉefaj lingvoj, tiel perdante la avantaĝon de simpleco. Kio estas la tasko de la vendisto esence solvita: eldoni norman solvon, kiun ĉiu studento kaptita surstrate povas personecigi kun la bezonata kvalito-nivelo (t.e., kovrokovraĵo de budo ĝis granda fabriko estas kompletigita). Se vi estas budo, prenu studenton; se vi estas fabriko, prenu guruon de via efektiviga partnero. La fakto ke efektivigantaj partneroj vendas studentojn je la prezo de guruo ne estas problemo kun la kadro. Arkitekture, la kadro devas solvi la problemojn de ambaŭ, la kodo de normaj agordoj (kiun ni vendis al entreprenoj kun la promeso de personigo) devus povi esti komprenita de studento, kaj guruo devus povi kompreni kion ajn vi volas.

Kio, laŭ mi, vere mankas en la lingvo, kio devigas vin skribi pli ol vi povus, estas tio, kio malŝparas tempon pagatan de la kliento.

• Ebleco tajpi je la nivelo, ekzemple, TypeScript (kiel rezulto, pli evoluintaj kodaj analiziloj en la IDE, refactoring, malpli ofensivaj jamboj)
  Havebleco de funkcioj kiel unuaklasaj objektoj. Iomete pli kompleksa koncepto, sed la kvanto de tipa boilerplate-kodo povus esti tre reduktita. La kompreno de la studento pri la kodo, IMHO, eĉ pliiĝus pro la redukto de volumeno
• Universalaj kolektaj literaloj, inicialigiloj. La sama afero - redukti la kvanton da kodo, kiun oni devas skribi kaj/aŭ rigardi per viaj okuloj. Plenigi kolektojn okupas pli ol 9000% de 1C-programa tempo. Skribi ĉi tion sen sintaksa sukero estas longa, multekosta kaj erarema. Ĝenerale, la kvanto de LOC en 1C-solvoj superas ĉiujn imageblajn limojn kompare kun disponeblaj malfermaj kadroj kaj, ĝenerale, ĉiuj viaj entreprenaj Javas kombinitaj. La lingvo estas multvorta, kaj ĉi tio degeneras en la kvanton de datumoj, memoro, IDE-bremsoj, tempo, mono...
• fine konstruojn mi havas hipotezon, ke tiu ĉi konstruo mankas pro tio, ke ili ne trovis sukcesan tradukon de ĝi en la rusan :)
• Propraj datumtipoj (sen OOP), analogoj de Tipo de VB6. Ĝi permesos al vi ne tajpi strukturojn uzante komentojn en la BSP kaj magiaj metodoj kiuj konstruas ĉi tiujn strukturojn. Ni ricevas: malpli da kodo, aludo tra punkto, pli rapida solvo de la problemo, malpli da eraroj pro mistajpoj kaj mankantaj ecoj de strukturoj. Nun la tajpado de uzantstrukturoj dependas tute de la disvolva teamo de la Norma Subsistema Biblioteko, kiu, laŭ sia kredito, zorge skribas komentojn pri la atendataj propraĵoj de la preterpasitaj parametraj strukturoj.
• Sen sukero kiam vi laboras kun nesinkronaj vokoj sur la retkliento. callback-hell en formo de ProcessingNotifications estas provizora lambastono kaŭzita de subita ŝanĝo en la API de la ĉefaj retumiloj, sed vi ne povas vivi tiel la tutan tempon; la avantaĝo de "studenta kompreno" de nesinkrona kodo perdiĝas. pli kaj pli. Aldonu neniun subtenon por ĉi tiu paradigmo en la ĉefa IDE kaj aferoj eĉ plimalboniĝos.

Ĉi tiu estas unu el la urĝaj problemoj, estas klare, ke la listo povus esti multe pli granda, sed ni ne devas forgesi, ke ĉi tio ankoraŭ ne estas ĝeneraluzebla lingvo, ĝi ne postulas multfadenadon, lambda funkciojn, aliron al la GPU kaj rapida. glitkomaj kalkuloj. Ĉi tio estas komerca logika skriptlingvo.

Programisto, kiu jam multe laboris kun ĉi tiu lingvo, rigardas js aŭ c#, enuiĝas kadre de ĉi tiu lingvo. Estas fakto. Li bezonas evoluon. Aliflanke de la skalo por la vendisto estas la kosto de efektivigo de la specifitaj funkcioj kontraŭ la pliiĝo de enspezo post ilia efektivigo. Ĉi tie mi ne havas informojn pri tio, kio nuntempe superas en la okuloj de la kompanio.

Disvolva medio

Ankaŭ ĉi tie aferoj ne iras glate. Estas du evolumedioj. La unua estas la Configurator inkluzivita en la transdono. La dua estas la medio de Enterprise Development Tools, aŭ mallonge EDT, evoluigita surbaze de Eclipse.

La agordilo disponigas plenan gamon da evoluaj taskoj, subtenas ĉiujn funkciojn kaj estas la ĉefa medio sur la merkato. Ĝi estas ankaŭ morale malnoviĝinta, ne evoluanta, laŭ onidiroj – pro la kvanto de teknika ŝuldo en si. La situacio povus esti plibonigita malfermante internan API (en la formo de amikeco kun Neĝulo A. Orefkova aŭ sur sendependa bazo), sed tio ne estas la kazo. Praktiko montris, ke la komunumo skribos siajn proprajn funkciojn en la IDE, kondiĉe ke la vendisto ne enmiksiĝas. Sed ni havas tion, kion ni havas. La agordilo estis bonega en 2004-2005, tre rememoriga pri Visual Studio de tiuj tempoj, en kelkaj lokoj ĝi estis eĉ pli malvarmeta, sed ĝi estis blokita en tiuj tempoj.

Krome, la volumeno de la averaĝa norma solvo kreskis plurajn fojojn ekde tiam, kaj hodiaŭ la IDE simple ne povas elteni la kvanton da kodo, per kiu ĝi estas nutrita. Uzebleco kaj refactoring kapabloj eĉ ne estas nul, ili estas en la ruĝa. Ĉio ĉi ne aldonas entuziasmon al la programistoj kaj ili revas translokiĝi al aliaj ekosistemoj kaj daŭre kodi fekon tie, sed en agrabla medio, kiu ne kraĉas en vian vizaĝon kun sia konduto.

Kiel alternativo, IDE skribita de nulo, konstruita sur Eclipse, estas ofertita. Tie, la fontoj, kiel en iu ajn alia programaro, vivas en formo de tekstaj dosieroj, estas konservitaj en GIT, tiras petajn branĉojn, ĉio ĉi. Male, ĝi ne forlasis beta-statuson dum multaj jaroj nun, kvankam ĝi pliboniĝas kun ĉiu eldono. Mi ne skribos pri la malavantaĝoj de EDT, hodiaŭ ĝi estas minuso, morgaŭ ĝi estas fiksa funkcio. La graveco de tia priskribo rapide malaperos. Hodiaŭ eblas disvolvi en EDT, sed ĝi estas nekutima; vi devas esti preta por certa nombro da IDE-eraroj.

Se vi rigardas la situacion per la menciita "1C-prismo", vi ricevas ion tian: la eldonado de la nova IDE ne pliigas vendojn de skatoloj, sed la elfluo de PROPLIANTOJ povas reduktiĝi. Estas malfacile diri, kio atendas la ekosistemon laŭ komforto de programistoj, sed Mikrosofto jam fuŝis poŝtelefonajn programistojn proponante al ili siajn servojn tro malfrue.

Disvolva administrado

Ĉio ĉi tie estas signife pli bona ol en skribado de kodo, precipe lastatempe, kiam la klopodoj de la komunumo elmontris la problemojn de administrado-aŭtomatigo, lanĉis prototipojn postulantajn ĵeti la 1C-deponejon en la rubejon kaj uzi git, rapidan kulpigon, kodon-revizion. , senmova analizo, aŭtomata deplojo kaj ktp. Multaj funkcioj estis aldonitaj al la platformo, kiuj pliigas la nivelon de aŭtomatigo de evoluaj taskoj. Tamen, ĉiuj ĉi tiuj funkcioj estis aldonitaj nur kaj ekskluzive por la disvolviĝo de niaj propraj grandaj produktoj, kiam evidentiĝis, ke ni ne povas fari sen aŭtomatigo. Estis aŭtomate kunfandiĝoj, tridirekta komparo kun KDiff kaj ĉio tio. Lanĉite sur Github gitconverter, kiu, sincere, estis ideologie trenita for de la projekto gitsync, sed modifita por konveni la procezojn de la vendistofirmao. Dank' al la obstinaj uloj de malfermfonteco, disvolviĝo aŭtomatigo en 1C ekfunkciis. Malferma API por la agordilo, IMHO, ankaŭ ŝanĝus la moralan postrestantecon de la ĉefa IDE.

Hodiaŭ, stokante 1C-fontojn en git kun kommits ligitaj al problemoj en Jira, recenzoj en Crucible, prembutono de Jenkins kaj Allure-raportoj pri koda testado en 1C kaj eĉ senmova analizo en SonarQube - ĉi tio estas malproksime de novaĵo, sed prefere la ĉefa en kompanioj kie estas multe da 1C-disvolviĝo.

Administrado

Estas multo por diri ĉi tie. Unue, ĉi tio estas, kompreneble, servilo (1C servilo-grupo). Mirinda afero, sed pro tio, ke ĝi estas tute nigra skatolo, dokumentita sufiĉe detale, sed en specifa maniero - regi la lanĉon de seninterrompa operacio en alta ŝarĝa reĝimo sur pluraj serviloj estas la sorto de elektitaj malmultaj, kiuj portas. medalo kun la surskribo "Spertulo pri Teknologiaj Problemoj". Indas noti, ke, principe, administri 1C-servilon ne diferencas de administri ajnan alian servilon. Ĝi estas ret-bazita, plurfadena aplikaĵo, kiu konsumas memoron, CPU- kaj diskresursojn. Provizas ampleksajn ŝancojn por telemetria kolekto kaj diagnozo.

La problemo ĉi tie estas, ke la vendisto ofertas nenion specialan koncerne pretajn solvojn por ĉi tiu tre diagnozo. Jes, ekzistas 1C: Instrumentation and Control Center, ili estas eĉ sufiĉe bonaj, sed ili estas tre multekostaj kaj ne ĉiuj havas ilin. Estas kelkaj evoluoj en la komunumo por konekti Grafana, Zabbix, ELK kaj aliajn aferojn de la norma administranto, sed ne ekzistas ununura solvo, kiu konvenos al la plimulto. La tasko atendas sian heroon. Kaj se vi estas komerco, kiu planas lanĉi sur 1C-areto, vi bezonas Fakulon. Via propra ene aŭ de ekstere, sed vi bezonas ĝin. Estas normale, ke ekzistas aparta rolo kun kompetentecoj por servila funkciado, ne ĉiu 1C-uzanto devus scii ĉi tion, vi nur bezonas kompreni, ke tia rolo estas necesa. Ni prenu SAP ekzemple. Tie, programisto, plej verŝajne, eĉ ne leviĝos de sia seĝo, se oni petas lin agordi ion en la aplikaĵoservilo. Li povas nur esti stulta kaj li ne hontos. En la SAP-metodaro ekzistas aparta dungita rolo por tio. Ial, en la industrio 1C oni kredas, ke ĉi tio devus esti kombinita en unu dungito por la sama salajro. Estas iluzio.

Malavantaĝoj de 1C-servilo

Estas ĝuste unu minus - fidindeco. Aŭ, se vi preferas, neantaŭvidebleco. Subita stranga konduto de la servilo jam fariĝis la parolado de la urbo. Universala rimedo - haltigi la servilon kaj purigi ĉiujn kaŝmemorojn - eĉ estas priskribita en la manlibro de la fakulo, kaj eĉ gruplibro estas rekomendita kiu faras tion. Se via 1C-sistemo komencas fari ion, kion ĝi eĉ teorie ne devus fari, estas tempo forigi la seandatumkaŝmemoron. Laŭ mia takso, estas nur tri homoj en la tuta lando, kiuj scipovas funkciigi 1C-servilon sen ĉi tiu proceduro kaj ili ne dividas sekretojn, ĉar... ili vivas de ĉi tio. Eble ilia sekreto estas, ke ili purigas kunsidantajn datumojn, sed ili diras al neniu pri tio, ulo.

Alie, la 1C-servilo estas la sama aplikaĵo kiel iu ajn alia kaj estas administrita en la sama maniero, legante la dokumentaron kaj frapante la tamburinon.

Docker

La utileco uzi konteneritan 1C-servilon en produktado ankoraŭ ne estis pruvita. La servilo ne estas amasigita per simple aldonado de nodoj malantaŭ la balancilo, kio reduktas la avantaĝojn de produktadkontenigo al minimumo, kaj la praktiko de sukcesa operacio en ujoj en altaŝarĝa reĝimo ne estis establita. Kiel rezulto, nur programistoj uzas Docker+1C por agordi testajn mediojn. Tie ĝi estas tre utila, aplikata, permesas vin ludi kun modernaj teknologioj kaj ripozi de la senkuraĝigo de la agordilo.

Komerca komponanto

De investa vidpunkto, 1C permesas vin solvi la problemon rapide lanĉi komercajn ideojn pro la larĝaj kapabloj de aplikaj klasoj. 1C el la skatolo donas tre decan Raportadon, integriĝon kun io ajn, TTT-kliento, movebla kliento, movebla aplikaĵo, subteno por diversaj DBMSoj, inkl. senpaga, transplatforma kaj servilo kaj instalitaj klientpartoj. Jes, la UI de aplikoj estos flava, foje ĉi tio estas minuso, sed ne ĉiam.
Elektante 1C, komerco ricevas aron da programaraj solvoj, kiuj permesas al ili konstrui tre larĝan gamon da aplikoj, kaj ankaŭ multajn programistojn sur la merkato, kiuj volas malpli da mono ol javaistoj kaj samtempe produktas rezultojn pli rapide.

Ekzemple, la tasko sendi PDF-fakturon al kliento povas esti solvita en horo da studenta laboro. La sama problemo en .NET povas esti solvita aĉetante proprietan bibliotekon, aŭ kelkajn tagojn aŭ semajnojn da kodigo de severa, barba programisto. Foje, ambaŭ samtempe. Kaj jes, mi nur parolis pri PDF-generacio. Ni eĉ ne diris de kie venos ĉi tiu fakturo. La interreta transisto devas krei formon, kie la operatoro enmetos la datumojn, la backender devos krei dto-modelojn por transloki JSON, modelojn por konservi en la datumbazo, la strukturon de la datumbazo mem, migrado al ĝi, la formado de grafikaĵo. montro de tiu ĉi konto mem, kaj nur tiam - PDF. Sur 1C, la tuta tasko, de nulo, estas finita en ekzakte unu horo.

Plenrajta kontada sistemo por malgranda budo kun unu komerca procezo aĉetita/vendita estas farita en 3 horoj. Kun venda raportado, kontado de varoj ĉe aĉeto kaj vendoprezoj, disrompita laŭ magazeno, alirrajta kontrolo, retkliento kaj movebla aplikaĵo. . Bone, mi forgesis pri la aplikaĵo, kun la aplikaĵo ne en 3 horoj, en ses.

Kiom longe ĉi tiu tasko daŭros al .NET-programisto de instali vidan studion sur pura komputilo ĝis pruvi ĝin al la kliento? Kio pri la kosto de disvolviĝo? Sama afero.

Fortoj de 1C kiel platformo

1C estas forta ne ĉar estas io specifa pri ĝi, kio estas la plej bona en la mondo. Male, en ĉiu individua subsistemo oni povas trovi pli interesan analogon en la monda programaro. Tamen, surbaze de kombinaĵo de faktoroj, mi ne vidas platformon similan al 1C. Ĉi tie kuŝas komerca sukceso. La avantaĝoj de la platformo estas disigitaj tra ĝi kaj estas plej klare videblaj kiam vi vidas kiel tio estas farita en aliaj platformoj. Esence, ĉi tiuj NE estas eĉ trajtoj, sed male - malakcepto de trajtoj favore al unu specifa paradigmo. Kelkaj ekzemploj:

1. Unikodo. Kio diable povus esti pli simpla? Ne necesas uzi unubajtajn ASCII-kodigojn en 2019 (krom integriĝo kun antikvaj heredaĵoj). Neniam. Sed ne. Ĉiuokaze, iu en iu tabelo uzas unu-bajtan varchar kaj la aplikaĵo havos problemojn kun kodigoj. En 2015, la LDAP-rajtigo de gitlab malsukcesis pro malĝusta laboro kun kodigoj; JetBrains IDE ankoraŭ ne funkcias kun Cyrillic en dosiernomoj ĉie. 1C provizas altkvalitan izolitecon de aplika kodo de la datumbazo. Tie estas neeble tajpi tabelojn je malalta nivelo kaj jamboj de nekompetentaj junuloj je la datumbaza nivelo estas neeblaj tie. Jes, povas esti aliaj problemoj kun nekompetentaj junuloj, sed la vario de problemoj estas multe pli malgranda. Nun vi diros al mi, ke via aplikaĵo estas ĝuste desegnita kaj la datumbaza alirtavolo estas izolita kiel ĝi devus esti. Rigardu vian kompanian kutiman Java-aplikaĵon. Proksime kaj honeste. Ĉu via konscienco ĝenas vin? Tiam mi estas feliĉa por vi.
2. Numerado de dokumentoj/referencaj libroj. En 1C ĝi certe ne estas la plej fleksebla kaj ne la plej bona. Sed kion ili faras en banka programaro kaj en memskribitaj kontadaj sistemoj - nu, estas nur mallumo. Aŭ identeco estos blokita (kaj tiam "ho, kial ni havas truojn"), aŭ male, ili faros generatoron kiu funkcias kun ŝlosado ĉe la DBMS-nivelo (kaj fariĝos botelo). Fakte, estas sufiĉe malfacile fari ĉi tiun ŝajne simplan taskon - fin-al-fina listigilo de entoj, kun unikecsekcio bazita sur certa aro de ŝlosiloj, prefiksado, por ke ĝi ne bloku la datumbazon dum paralela enigo de datumoj. .
3. Identigiloj de rekordoj en la datumbazo. 1C faris fortvolan decidon - ĉiuj ligilidentigiloj estas absolute sintezaj kaj jen ĝi. Kaj ne estas problemoj kun distribuitaj datumbazoj kaj interŝanĝoj. Programistoj de aliaj sistemoj obstine kreas ion kiel identeco (ĝi estas pli mallonga!), trenu ilin en la GUI ĝis estas tempo krei plurajn rilatajn okazojn (kaj tiam ili estos malkovritaj). Ĉu vi ne havas ĉi tion? Ĉu sincere?
4. Listoj. 1C havas sufiĉe sukcesajn mekanismojn por paĝigi (grandajn) listojn kaj navigi tra ili. Mi tuj faru rezervon - kun la ĝusta uzo de la mekanismo! Ĝenerale, la temo estas sufiĉe malagrabla, ĝi ne povas esti solvita ideale: ĝi estas aŭ intuicia kaj simpla (sed la risko de grandegaj rekordaroj ĉe la kliento), aŭ paĝigo estas de unu aŭ alia malrekteco. Tiuj, kiuj faras paĝigon, ofte faras ĝin malrekte. Tiuj, kiuj faras honestan rulstangon, aldonas datumbazon, kanalon kaj klienton.
5. Administritaj formoj. Sendube, en la retkliento la interfaco ne funkcias perfekte. Sed ĝi funkcias. Sed por multaj aliaj kontadaj kaj bankaj sistemoj, krei malproksiman laborejon estas entrepren-nivela projekto. Malgarantio: feliĉe por tiuj, kiuj origine faris ĝin en la reto, ĉi tio ne influos.
6. Poŝtelefona aplikaĵo. Lastatempe, vi ankaŭ povas skribi moveblajn aplikojn dum en la sama ekosistemo. Ĉi tie estas iom pli komplika ol kun retkliento; la specifaĵoj de aparatoj devigas vin skribi specife por ili, sed, tamen, vi ne dungas apartan teamon de moveblaj programistoj. Se vi bezonas aplikaĵon por la internaj bezonoj de firmao (kiam movebla solvo al kompania problemo estas pli grava ol flava UI-dezajno), vi simple uzas la saman platformon el la skatolo.
7. Raportado. Per ĉi tiu vorto mi ne celas BI-sistemon kun grandaj datumoj kaj malfruo en la ETL-procezo. Ĉi tio rilatas al operaciaj raportoj, kiuj ebligas al vi taksi la staton de kontado ĉi tie kaj nun. Ekvilibroj, reciprokaj kompromisoj, re-gradado, ktp. 1C eliras el la skatolo kun raporta sistemo kun flekseblaj agordoj por grupiĝoj, filtriloj kaj vidado ĉe la uzanto-flanko. Jes, ekzistas pli malvarmetaj analogoj sur la merkato. Sed ne en la kadro de ĉio-en-unu solvo kaj je prezo foje pli alta ol ĉio-en-unua solvo. Kaj pli ofte estas eĉ inverse: nur raportado, sed pli multekosta ol la tuta platformo, kaj pli malbona en kvalito.
8. Preseblaj formoj. Nu, uzu .NET por solvi la problemon sendi salajrajn biletojn en PDF al dungitoj retpoŝte. Kaj nun la tasko presi fakturojn. Kio pri konservado de iliaj kopioj al la sama PDF? Por 1C kromnomo, eligi ajnan aranĝon al PDF estas +1 linio de kodo. Ĉi tio signifas + 40 sekundojn da labortempo, anstataŭ tagojn aŭ semajnojn en alia lingvo. Presitaj formularoj en 1C estas nekredeble facile disvolveblaj kaj sufiĉe potencaj por konkuri kun pagitaj ekvivalentoj. Jes, verŝajne, ne estas multaj interagaj ŝancoj en 1C kalkultabelaj dokumentoj; vi ne povas rapide akiri 3D-diagramon kun skalo uzante OpenGL. Sed ĉu vere necesas?

Ĉi tiuj estas nur kelkaj ekzemploj, kie limigi funkciecon aŭ efektivigi kompromisojn montriĝas grava arkitektura avantaĝo en la estonteco. Eĉ kompromiso aŭ ne la plej efika opcio - ĝi jam estas en la skatolo kaj estas konsiderata. Ĝia sendependa efektivigo estos aŭ neebla (ĉar tiaj decidoj devas esti faritaj komence de la projekto, kaj ne estas tempo por tio, kaj tute ne estas arkitekto), aŭ pluraj multekostaj ripetoj. En ĉiu el la listigitaj punktoj (kaj ĉi tio ne estas kompleta listo de arkitekturaj solvoj), vi povas malŝprucigi kaj enkonduki limigojn, kiuj blokas skalon. Ĉiukaze, vi, kiel komercisto, devas certigi, ke viaj programistoj, kiam ili faras "sistemon de nulo", havas rektajn manojn kaj tuj bone faros subtilajn sistemajn aferojn.

Jes, kiel en iu ajn alia kompleksa sistemo, 1C mem ankaŭ havas solvojn, kiuj blokas skalon en iuj aspektoj. Tamen, mi ripetas, surbaze de kombinaĵo de faktoroj, la kosto de posedo, kaj la nombro da problemoj jam solvitaj anticipe, mi ne vidas indan konkuranton sur la merkato. Por la sama prezo, vi ricevas financan aplikaĵan kadron, amasigitan ekvilibran servilon, kun UI kaj retinterfaco, kun movebla aplikaĵo, kun raportado, integriĝo kaj amaso da aliaj aferoj. En la Ĝava mondo, vi dungas antaŭan kaj malantaŭan teamon, vi elpurigas malaltnivelajn amasojn de hejmaj servilkodoj kaj pagas aparte por 2 moveblaj aplikoj por 2 movebla OS.

Mi ne diras, ke 1C solvos ĉiujn kazojn, sed por interna kompania aplikaĵo, kiam ne necesas marki la UI - kio alia necesas?

Kulero da gudro

Vi verŝajne havas la impreson, ke 1C savos la mondon kaj ke ĉiuj aliaj manieroj verki kompaniajn sistemojn estas malĝustaj. Tute ne estas tia. El la vidpunkto de komercisto, se vi elektas 1C, tiam krom rapida tempo-merkatiĝo, vi devas konsideri la jenajn malavantaĝojn:

• Servila fidindeco. Vere altkvalitaj specialistoj estas bezonataj, kiuj povas certigi ĝian seninterrompan funkciadon. Mi ne scias pri preta trejna programo por tiaj specialistoj de la vendisto. Estas kursoj por prepari la Fakan ekzamenon, sed tio, miaopinie, ne sufiĉas.
• Subteno. Vidu antaŭan punkton. Por havi subtenon de la vendisto, vi devas aĉeti ĝin. Ial ĉi tio ne estas akceptita en la 1C-industrio. Kaj kun SAP, ĝi estas preskaŭ nepra aĉeto kaj ĝi ne ĝenas iun ajn. Sen kompania subteno kaj sen fakulo pri dungitaro, vi povas resti sola kun 1C-problemoj.
• Tamen, vi ne povas fari absolute ĉion kun 1C. Ĉi tio estas ilo kaj kiel ĉiu ilo ĝi havas limojn de aplikebleco. En la 1C pejzaĝo, estas tre dezirinde havi "ne-1C" sisteman arkitekton.
• Bonaj 1C kromnomoj ne estas pli malmultekostaj ol bonaj programistoj en aliaj lingvoj. Kvankam malbonaj programistoj estas multekostaj dungi, sendepende de la lingvo en kiu ili skribas.

Ni punktu la punktojn

• 1C estas rapida aplikaĵa evoluo (RAD) kadro por komerco kaj estas adaptita por tio.
• Trinivela ligo kun subteno por ĉefaj DBMSoj, klienta UI, tre bona ORM kaj raportado
• Vastaj eblecoj por integriĝo kun sistemoj kiuj povas fari tion, kion 1C ne povas. Se vi volas maŝinlernadon, prenu Python kaj sendu la rezulton al 1C per http aŭ RabbitMQ
• Ne necesas strebi fari ĉion uzante 1C, vi devas kompreni ĝiajn fortojn kaj uzi ilin por viaj propraj celoj.
• Programistoj, kiuj gravitas al fosado en teknologiajn kadrajn aparatojn kaj restrukturi ĉiujn N jarojn al nova motoro, enuiĝas pri 1C. Ĉio estas tre konservativa tie.
• Programistoj ankaŭ enuas ĉar estas tre malmulte da zorgo por ili de la fabrikanto. Enuiga lingvo, malforta IDE. Ili postulas modernigon.
• Aliflanke, programistoj, kiuj ne povas trovi amuzon per uzado kaj lernado de alia teknologio, kiun ili ĝuas, estas malbonaj programistoj. Ili ĝemos kaj moviĝos al alia ekosistemo.
• Dungantoj, kiuj ne permesas siajn 1C-alnomojn skribi ion en Python, estas malbonaj dungantoj. Ili perdos dungitojn kun scivolaj mensoj, kaj anstataŭ ili venos simiokodistoj, kiuj, konsentante pri ĉio, trenos kompanian programaron en la marĉon. Ĝi ankoraŭ devos esti reverkita, do eble estus pli bone investi iom en Python iom pli frue?
• 1C estas komerca firmao kaj efektivigas funkciojn nur bazitajn sur siaj propraj interesoj kaj oportuneco. Vi ne povas kulpigi ŝin pri tio, komerco devas pensi pri profito, tio estas vivo
• 1C gajnas monon vendante solvojn al komercaj problemoj, ne al la programistoj de Vasya. Ĉi tiuj du konceptoj korelacias, sed la prioritato estas ĝuste tio, kion mi diris. Kiam la programisto Vasya pretas pagi personan permesilon por 1C: Resharper, ĝi aperos sufiĉe rapide, "Resharper" de A. Orefkova estas pruvo de tio. Se la vendisto subtenis ĝin, kaj ne batalis kontraŭ ĝi, aperus merkato por programaro por programistoj. Nun estas unu kaj duono ludantoj en ĉi tiu merkato kun dubindaj rezultoj, kaj ĉio ĉar la integriĝo kun la IDE estas negativa kaj ĉio estas farita per lambastonoj.
• La praktiko de plurmaŝina funkciigisto malaperos en forgeson. Modernaj aplikoj estas tro grandaj por memori kaj de la koda flanko kaj de la komerca uzo. La 1C-servilo ankaŭ fariĝas pli kompleksa; estos neeble teni ĉiujn specojn de kompetenteco en unu dungito. Ĉi tio devus kunporti postulon de specialistoj, kio signifas la allogecon de la profesio 1C kaj plialtigon de salajroj. Se antaŭe Vasya laboris tri-en-unu por unu salajro, nun vi devas dungi du Vasyas kaj konkuro inter Vasyas povas stimuli la ĝeneralan kreskon de ilia nivelo.

konkludo

1C estas tre inda produkto. En mia prezo, mi tute ne konas analogojn, skribu en la komentoj se ekzistas. Tamen, la elfluo de programistoj el la ekosistemo fariĝas pli kaj pli rimarkebla, kaj ĉi tio estas "cerbo elfluo", negrave kiel vi rigardas ĝin. La industrio malsatas je modernigo.
Se vi estas programisto, ne pendiĝu pri 1C kaj ne pensu, ke ĉio estas magia en aliaj lingvoj. Dum vi estas juna, eble. Tuj kiam io pli granda bezonos esti solvita, pretaj solvoj devos esti serĉataj pli longe kaj pli intense kompletigitaj. Koncerne la kvaliton de la "blokoj" el kiuj solvo povas esti konstruita, 1C estas tre, tre bona.

Kaj ankoraŭ unu afero - se 1C-alnomo venas al vi por dungi, tiam la 1C-alnomo povas esti sekure nomumita al la pozicio de ĉefaj analizistoj. Ilia kompreno de la tasko, temo, kaj malkomponaj kapabloj estas bonegaj. Mi certas, ke ĉi tio estas ĝuste pro la devigita uzo de DDD en 1C-disvolviĝo. La persono estas trejnita por pensi pri la signifo de la tasko antaŭ ĉio, pri la ligoj inter objektoj de la temo, kaj samtempe havas teknikan fonon en integrigaj teknologioj kaj datumŝanĝaj formatoj.

Konsciu, ke la ideala kadro ne ekzistas kaj zorgu pri vi.
Bonan al ĉiuj!

PS: koran dankon speŝuriko por helpo en la preparado de la artikolo.

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Ĉu vi havas 1C en via entrepreno?

• 13,3%Tute ne.71

• 30,3%Estas, sed nur en la kontada fako ie. Kernsistemoj sur aliaj platformoj162

• 41,4%Jes, la ĉefaj komercaj procezoj funkcias sur ĝi221

• 15,0%1C devas morti, la estonteco apartenas al %technology_name%80

534 uzantoj voĉdonis. 99 uzantoj sindetenis.

fonto: www.habr.com