1C - E mira dhe e keqja. Rregullimi i pikave në holivare rreth 1C

Miq dhe kolegë, kohët e fundit ka pasur më shumë artikuj mbi Habré me urrejtje ndaj 1C si një platformë zhvillimi, dhe fjalime nga mbrojtësit e tij. Këta artikuj identifikuan një problem serioz: më shpesh, kritikët e 1C e kritikojnë atë nga pozicioni i "mos zotërimit të tij", duke qortuar problemet që de facto zgjidhen lehtësisht dhe, përkundrazi, duke mos prekur probleme që janë vërtet të rëndësishme, me vlerë. diskutohen dhe nuk zgjidhen nga shitësi . Unë besoj se ka kuptim të bëhet një rishikim i matur dhe i ekuilibruar i platformës 1C. Çfarë mund të bëjë, çfarë nuk mund të bëjë, çfarë duhet të bëjë por nuk bën dhe, për ëmbëlsirë, çfarë bën me një zhurmë, dhe zhvilluesit tuaj në %technology_name% do të bëjnë njëqind vjet, duke e hedhur tutje më shumë se një buxhet vjetor.

Si rezultat, ju, si menaxher ose arkitekt, do të jeni në gjendje të kuptoni qartë se çfarë detyre do të jetë e dobishme për ju të përdorni 1C dhe ku duhet të digjet me një hekur të nxehtë. Si një zhvillues në botën "jo-1C", do të mund të shihni se çfarë ka në 1C që po shkakton bujë. Dhe si një zhvillues 1C, do të jeni në gjendje të krahasoni sistemin tuaj me ekosistemet e gjuhëve të tjera dhe të kuptoni vendndodhjen tuaj në sistemin koordinativ të zhvillimit të softuerit.

Nën prerje ka shumë sulme të trasha në 1C, në kritikë të 1C, në Java, .NET dhe në përgjithësi... Fanti është plot, mirë se erdhe!

Rreth vetes sime

Unë jam njohur me temën e bisedës rreth vitit 2004. Unë kam programuar ndoshta që në moshën 6-vjeçare, që nga momenti kur mora një libër për Profesor Fortran me komike për një mace, një harabel dhe një vemje. Analizova programet që shkroi macja nga fotot në libër dhe zbulova se çfarë bënë. Dhe po, nuk kisha një kompjuter të vërtetë në atë kohë, por kishte një vizatim në shtrirjen e librit dhe shtypa me sinqeritet butonat e letrës, duke futur komandat që kisha spiunuar për macen X.

Më pas ishte BK0011 dhe BASIC në shkollë, C++ dhe assemblers në universitet, pastaj 1C, dhe më pas kaq shumë gjëra të tjera që jam shumë dembel t'i kujtoj. Në 15 vitet e fundit jam përfshirë kryesisht në 1C, jo vetëm në aspektin e kodimit, por me 1C në përgjithësi. Vendosja e detyrave, administrimit dhe zhvillimit këtu. Për 5 vitet e fundit kam qenë i angazhuar në aktivitete të dobishme shoqërore në drejtim të zhvillimit të mjeteve të zhvillimit dhe automatizimit për përdoruesit e tjerë të 1C, duke shkruar artikuj dhe libra.

Le të vendosim për temën e diskutimit

Së pari, le të përcaktojmë se për çfarë do të flasim, pasi shkronjat "1C" mund të nënkuptojnë shumë gjëra. Në këtë rast, me shkronjat "1C" do të nënkuptojmë ekskluzivisht kornizën e zhvillimit "1C: Ndërmarrja" e versionit modern, të tetë. Ne nuk do të flasim shumë për prodhuesin dhe politikat e tij (por do të duhet të bëjmë pak) Ne nuk do të diskutojmë aplikacione specifike të shkruara duke përdorur këtë kornizë. Teknologjia është e veçantë, aplikacionet e njohura si konfigurimet janë të ndara.

Arkitektura e nivelit të lartë 1C: Ndërmarrje

Jo më kot përmend fjalën "kornizë". Nga këndvështrimi i një zhvilluesi, platforma 1C është pikërisht një kornizë. Dhe ju duhet ta trajtoni atë saktësisht si një kornizë. Mendoni për atë si Spring ose ASP.NET, të ekzekutuar nga një kohë ekzekutimi (përkatësisht JVM ose CLR). Ndodh që në botën e programimit konvencional ("jo 1C"), ndarja në korniza, makina virtuale dhe aplikacione specifike është e natyrshme, për faktin se këta përbërës zakonisht zhvillohen nga prodhues të ndryshëm. Në botën 1C, nuk është zakon të dallosh në mënyrë eksplicite kornizën e zhvillimit dhe vetë kohën e ekzekutimit; përveç kësaj, aplikacione specifike të shkruara duke përdorur kornizën zhvillohen kryesisht nga vetë 1C. Si rezultat, lind një konfuzion. Prandaj, në kuadrin e artikullit, do të duhet të marrim parasysh 1C nga disa anë menjëherë dhe ta klasifikojmë atë përgjatë disa akseve koordinative. Dhe në çdo bosht koordinativ do të vendosim një lopatë me substancë kafe dhe do të shikojmë tiparet, avantazhet dhe disavantazhet e zgjidhjes ekzistuese.

Pikëpamjet në 1C

1C për blerësin

Blerësi blen një sistem automatizimi me të cilin mund të zgjidhë shpejt problemet e automatizimit të biznesit të tij. Një biznes mund të jetë një tezgë e vogël, ose mund të jetë një kompani e madhe mbajtëse. Është e qartë se nevojat e këtyre bizneseve janë të ndryshme, por të dyja mbështeten nga një bazë e vetme kodi platforme.

Për blerësin 1C, kjo është një kohë e shpejtë për në treg. Shpejt. Më shpejt se Java, C# ose JS. Mesatare. Rreth spitalit. Është e qartë se një uebsajt i kartës së biznesit duke përdorur React do të dalë më i mirë, por prapavija e një sistemi WMS do të nisë më shpejt në 1C.

1C si mjet

Çdo zgjidhje teknologjike ka kufijtë e zbatueshmërisë. 1C nuk është një gjuhë me qëllim të përgjithshëm; ajo nuk jeton veçmas nga korniza e saj. Këshillohet të përdorni 1C kur keni nevojë:

• aplikacioni i serverit
• aplikimi ku shfaqen financat
• me UI të gatshme, ORM, Raportim, XML/JSON/COM/PDF/Formati YourDataTransfering
• me mbështetje për proceset dhe punët në sfond
• me siguri të bazuar në role
• me logjikë biznesi të skriptueshme
• me aftësinë për të krijuar shpejt një prototip dhe kohë të ulët për në treg

Ju nuk keni nevojë për 1C nëse dëshironi:

• mësimi i makinës
• Llogaritjet e GPU
• grafika kompjuterike
• llogaritjet matematikore
• Sistemi CAD
• përpunimi i sinjalit (tingulli, video)
• ngarkoni thirrjet http me qindra mijëra rps

1C si një kompani prodhuese

Vlen të kuptohet se cili është biznesi i 1C si prodhues softuerësh. Kompania 1C shet zgjidhje për problemet e biznesit përmes automatizimit. Biznese të ndryshme, të mëdha apo të vogla, por kjo është ajo që ajo shet. Mjetet për të arritur këtë qëllim janë aplikimet e biznesit. Për kontabilitetin, kontabilitetin e listës së pagave, etj. Për të shkruar këto aplikacione, kompania përdor platformën e saj të zhvillimit të aplikacioneve të biznesit. Të përshtatura posaçërisht për detyrat e zakonshme të të njëjtave aplikacione biznesi:

• Kontabiliteti financiar
• përshtatje e lehtë e logjikës së biznesit
• mundësi të gjera integrimi në peizazhe heterogjene të TI-së

Si prodhues, 1C beson se kjo është strategjia që ju lejon të punoni me partnerët dhe klientët në një mënyrë fitimprurëse. Ju mund të debatoni me këtë, por përafërsisht kjo është mënyra se si kompania promovon veten: zgjidhje të gatshme për problemet e biznesit që mund të personalizohen shpejt nga partnerët dhe të integrohen në çdo peizazh IT.

Të gjitha pretendimet ose dëshirat për 1C si kornizë duhet të shihen ekskluzivisht përmes këtij prizmi. "Ne duam OOP në 1C," thonë zhvilluesit. "Sa do të na kushtojë të mbështesim OOP në platformë, a do të na ndihmojë kjo të rrisim shitjet e kutive?" thotë 1C. Hap "prizmin" e tij të shitjes së zgjidhjeve për problemet e biznesit:

- Hej, biznes, a do OOP në 1C tuaj?
- A do të më ndihmojë kjo të zgjidh problemet e mia?
- Kush e di...
- Atëherë nuk ka nevojë

Kjo qasje mund të jetë e mirë ose e keqe në varësi të asaj se kush po e shikon, por kjo është pikërisht kështu. Duke folur për faktin se nuk ka asnjë veçori X në 1C, duhet të kuptoni se nuk është atje për një arsye, por në kontekstin e zgjedhjes "kostoja e zbatimit kundrejt shumës së fitimit".

Klasifikimi teknologjik

“Në fakt, Odinesnikët bëjnë çmos për të përdorur modelet më të mira, të zgjedhura me kujdes nga metodologë të kujdesshëm dhe zhvillues të platformës 1C.
Kur shkruani kodin tuaj budalla për një formë të thjeshtë të menaxhuar, në realitet po përdorni model-pamje-kontrollues с lidhje e dyfishtë e të dhënave в tre-shtresa-data-app-motor, me aromë harta e marrëdhënieve të objektit të nivelit të lartë në bazë përshkrim deklarativ i meta të dhënaveduke pasur të vetat gjuha e pyetjes e pavarur nga platforma, C Ndërfaqja e përdoruesit deklarative e drejtuar nga të dhënat, serializimi i plotë transparent dhe gjuha e programit e orientuar nga domeni.

Aty ku zhvilluesit 1C ndryshojnë nga kolegët e tyre perëndimorë është në PR. Ata duan t'i vënë një emër të madh çdo budallallëku dhe të vrapojnë me të si një çantë e pistë."
A. Orefkov

Platforma 1C ka një arkitekturë klasike me 3 nivele, në qendër të së cilës është serveri i aplikacionit (ose emulimi i tij për pak para për shitësit e vegjël). Ose MS SQL ose Postgres përdoren si DBMS. Ekziston edhe mbështetje për Oracle dhe IBM DB2, por kjo është mjaft ezoterike; askush nuk e di se çfarë do të ndodhë nëse zbatoni 1C në këto baza të dhënash nën ngarkesë të mesme dhe të lartë. Unë besoj se vetë 1C nuk e di këtë.

Pjesa e klientit është ose një klient i hollë i instaluar në makinën e përdoruesit ose një klient web. Karakteristika kryesore është se programuesit nuk shkruajnë 2 kode të ndryshme, ata shkruajnë një aplikacion, në një gjuhë, dhe ju mund ta shfaqni atë në shfletues nëse ka dëshirë ose nevojë. Kush donte atje një grumbull të vërtetë të plotë dhe një gjuhë të vetme për pjesën e përparme dhe të pasme, node.js? Ata kurrë nuk arritën të bënin të njëjtën gjë deri në fund. Ekziston një pirg i vërtetë i plotë, por do t'ju duhet ta shkruani në 1C. Ironia e fatit, gjëra të tilla :)

Zgjidhja e cloud SaaS 1C:Fresh funksionon gjithashtu në modalitetin e shfletuesit, në të cilin nuk mund të blini 1C, por të merrni me qira një bazë të dhënash të vogël dhe të mbani gjurmët e shitjeve të shawarma atje. Vetëm në shfletues, pa instaluar ose konfiguruar asgjë.

Për më tepër, ekziston një klient i trashëguar, i cili në 1C quhet "aplikacion i rregullt". Trashëgimia është trashëgimi, mirë se vini në botën e aplikacioneve në 2002, por ne ende po flasim për gjendjen aktuale të ekosistemit.

Pjesa e serverit 1C mbështet grupimin dhe shkallëzimin duke shtuar makina të reja në grup. Shumë kopje janë thyer këtu dhe do të ketë një seksion të veçantë në artikull për këtë. Me pak fjalë, kjo nuk është plotësisht e njëjtë me shtimin e disa rasteve saktësisht të njëjta pas HAProxy.

Korniza e zhvillimit të aplikacionit përdor gjuhën e vet të programimit, e cila përafërsisht i ngjan një VB6 pak të përmirësuar të përkthyer në Rusisht. Për njerëzit që urrejnë gjithçka ruse, të cilët nuk besojnë se "nëse" përkthehet si "nëse", ofrohet opsioni i dytë i sintaksës. Ato. Nëse dëshironi, mund ta shkruani në 1C në mënyrë të tillë që të mos dallohet nga VB.

Pikërisht kjo gjuhë programimi është arsyeja kryesore e urrejtjes së pseudonimeve 1C ndaj platformës së tyre. Le ta pranojmë, jo pa arsye. Gjuha u konceptua sa më e thjeshtë që të ishte e mundur, e krijuar për të përmbushur mantrën "ZHVILLUES, ZHVILLUES" në një shkallë të paktën në CIS. Thelbi tregtar i një zgjidhjeje të tillë, për mendimin tim, është qartë i dukshëm: më shumë zhvillues, mbulim më i madh i tregut. Kjo u bë e vërtetë, sipas vlerësimeve të ndryshme nga 45% në 95%. Unë do të them menjëherë se shkrimi në gjuhën që ju mendoni është vërtet më i lehtë. Dhe unë di mjaft gjuhë programimi.

Le të fillojmë me gjuhën.

Gjuhë programimi 1C

Në të njëjtën kohë pika e fortë dhe e dobët e sistemit. Ofron hyrje të lehtë dhe lexueshmëri. Nga ana tjetër, ai nuk është përditësuar që nga lëshimi i versionit 8 në 2002 dhe është moralisht i vjetëruar. Dikush do të thotë "pengesa kryesore është se nuk ka OOP" dhe ata do të gabojnë. Së pari, PLO nuk i pëlqen jo vetëm Nuraliev, por edhe Torvalds. Dhe së dyti, OOP ekziston ende.

Nga këndvështrimi i zhvilluesit, ai ka në dispozicion një kornizë me klasa bazë të shfaqur në DBMS. Zhvilluesi mund të marrë klasën bazë "Directory" dhe të trashëgojë direktorinë "Klientët" prej saj. Mund të shtojë fusha të reja të klasës në të, për shembull, INN dhe Adresa, dhe gjithashtu, nëse është e nevojshme, mund të anashkalojë (të anashkalojë) metodat e klasës bazë, për shembull, metodën OnWrite/AtRecord.

Korniza është projektuar në atë mënyrë që trashëgimia më e thellë është e nevojshme rrallë, dhe kufizimi në OOP, për mendimin tim, ka kuptim. 1C përqendrohet në Zhvillimin e Drejtuar nga Domain dhe ju bën të mendoni, para së gjithash, për fushën e temës së zgjidhjes që po zhvillohet, dhe kjo është e mirë. Nuk ka jo vetëm tundim, por as nevojë për të shkruar 10 DTO të ndryshme dhe ViewModels vetëm për të treguar disa të dhëna nga domeni diku. Zhvilluesi 1C operon gjithmonë me një entitet, pa e rrëmuar kontekstin e perceptimit me një duzinë klasash me emra të ngjashëm, që përfaqësojnë të njëjtin entitet, por nga një anë tjetër. Çdo aplikacion .NET, për shembull, do të përmbajë domosdoshmërisht pesë ose dy ViewModels dhe DTO për serializimin në JSON dhe transferimin e të dhënave nga klienti në server. Dhe afërsisht 10-15% e kodit të aplikacionit tuaj do të shpenzohet duke transferuar të dhëna nga një klasë në tjetrën duke përdorur stilolapsa ose paterica si AutoMapper. Ky kod duhet të shkruhet dhe programuesit duhet të paguhen për ta krijuar dhe mirëmbajtur atë.

Rezulton se gjuha 1C është e vështirë të zhvillohet pa e komplikuar atë në nivelin e gjuhëve të zakonshme, duke humbur kështu avantazhin e thjeshtësisë. Cila është detyra e shitësit që po zgjidhet në thelb: të nxjerrë një zgjidhje standarde që çdo student i kapur në rrugë mund ta personalizojë me nivelin e kërkuar të cilësisë (d.m.th., një rast që mbulon nga një tezgë në një fabrikë të madhe është përfunduar). Nëse jeni një stallë, merrni një student; nëse jeni një fabrikë, merrni një mësues nga partneri juaj i zbatimit. Fakti që partnerët zbatues i shesin studentët me çmimin e një mësuesi nuk është problem me kornizën. Arkitekturisht, korniza duhet të zgjidhë problemet e të dyjave, kodi i konfigurimeve standarde (të cilin ua shitëm bizneseve me premtimin e personalizimit) duhet të jetë në gjendje të kuptohet nga një student, dhe një mësues duhet të jetë në gjendje të kuptojë gjithçka që dëshironi.

Ajo që, sipas meje, i mungon vërtet gjuhës, ajo që të detyron të shkruash më shumë se sa mundesh, është ajo që humbet kohën e paguar nga klienti.

• Mundësia e shtypjes në nivel, për shembull, TypeScript (si rezultat, mjete më të zhvilluara të analizës së kodit në IDE, rifaktorim, më pak bllokime fyese)
  Disponueshmëria e funksioneve si objekte të klasit të parë. Një koncept pak më kompleks, por sasia e kodit tipik të bojlerplate mund të reduktohet shumë. Kuptimi i studentit për kodin, IMHO, madje do të rritej për shkak të zvogëlimit të vëllimit
• Literale të koleksionit universal, inicializues. E njëjta gjë - zvogëlimi i sasisë së kodit që duhet të shkruhet dhe/ose të shikohet me sytë tuaj. Mbushja e koleksioneve merr mbi 9000% të kohës së programimit 1C. Shkrimi i kësaj pa sheqer sintaksor është i gjatë, i shtrenjtë dhe i prirur ndaj gabimeve. Në përgjithësi, sasia e LOC në zgjidhjet 1C tejkalon të gjitha kufijtë e imagjinueshëm në krahasim me kornizat e hapura të disponueshme dhe, në përgjithësi, të gjitha Java-të e ndërmarrjes suaj të kombinuara. Gjuha është e folur, dhe kjo degjeneron në sasinë e të dhënave, kujtesës, frenave IDE, kohës, parave...
• më në fund ndërtime kam një hipotezë se ky ndërtim mungon për faktin se nuk gjetën një përkthim të suksesshëm të tij në Rusisht :)
• Llojet e të dhënave vetanake (pa OOP), analoge të tipit nga VB6. Kjo do t'ju lejojë të mos shkruani struktura duke përdorur komente në BSP dhe metoda magjike që ndërtojnë këto struktura. Ne marrim: më pak kod, një aluzion përmes një pike, zgjidhje më të shpejtë të problemit, më pak gabime për shkak të gabimeve shkrimore dhe veçorive të munguara të strukturave. Tani shtypja e strukturave të përdoruesve i takon tërësisht ekipit të zhvillimit të Bibliotekës Standarde të Nënsistemit, i cili, për meritë të tij, shkruan me kujdes komentet mbi vetitë e pritshme të strukturave të parametrave të kaluar.
• Pa sheqer kur punoni me thirrje asinkrone në klientin në internet. callback-helll në formën e ProcessingNotifications është një paterica e përkohshme e shkaktuar nga një ndryshim i papritur në API të shfletuesve kryesorë, por nuk mund të jetosh kështu gjatë gjithë kohës; avantazhi i "të kuptuarit nga studentët" të kodit asinkron po humbet. gjithnjë e më shumë. Mos shtoni asnjë mbështetje për këtë paradigmë në IDE-në kryesore dhe gjërat bëhen edhe më keq.

Ky është një nga problemet urgjente, është e qartë se lista mund të jetë shumë më e madhe, por nuk duhet të harrojmë se kjo nuk është ende një gjuhë me qëllim të përgjithshëm, nuk kërkon multithreading, funksione lambda, qasje në GPU dhe të shpejtë llogaritjet me pikë lundruese. Kjo është një gjuhë e skriptimit të logjikës së biznesit.

Një programues që tashmë ka punuar shumë me këtë gjuhë, shikon js ose c#, mërzitet brenda kornizës së kësaj gjuhe. Është një fakt. Ai ka nevojë për zhvillim. Në anën tjetër të shkallës për shitësin është kostoja e zbatimit të veçorive të specifikuara kundrejt rritjes së të ardhurave pas zbatimit të tyre. Këtu nuk kam asnjë informacion se çfarë po peshon aktualisht në sytë e kompanisë.

Mjedisi i zhvillimit

As këtu gjërat nuk po shkojnë mirë. Ka dy mjedise zhvillimi. I pari është Konfiguruesi i përfshirë në dorëzim. E dyta është mjedisi Enterprise Development Tools, ose shkurt EDT, i zhvilluar në bazë të Eclipse.

Konfiguruesi ofron një gamë të plotë detyrash zhvillimi, mbështet të gjitha veçoritë dhe është mjedisi kryesor në treg. Është gjithashtu moralisht i vjetëruar, nuk po zhvillohet, sipas thashethemeve - për shkak të sasisë së borxhit teknik brenda vetes. Situata mund të përmirësohet duke hapur një API të brendshme (në formën e miqësisë me Burrë dëbore A. Orefkova ose në baza të pavarura), por nuk është kështu. Praktika ka treguar se komuniteti do të shkruajë veçoritë e veta në IDE, për sa kohë që shitësi nuk ndërhyn. Por ne kemi atë që kemi. Konfiguruesi ishte i shkëlqyeshëm në 2004-2005, duke kujtuar shumë Visual Studio të atyre kohërave, në disa vende ishte edhe më i freskët, por ishte i mbërthyer në ato kohë.

Për më tepër, vëllimi i zgjidhjes standarde mesatare është rritur disa herë që atëherë, dhe sot IDE thjesht nuk mund të përballojë sasinë e kodit me të cilin ushqehet. Përdorshmëria dhe aftësitë e rifaktorimit nuk janë as zero, ato janë në të kuqe. E gjithë kjo nuk i shton entuziazmin zhvilluesve dhe ata ëndërrojnë të kalojnë në ekosisteme të tjera dhe të vazhdojnë të kodojnë shit atje, por në një mjedis të këndshëm që nuk të pështyn në fytyrë me sjelljen e tij.

Si alternativë, ofrohet një IDE e shkruar nga e para, e ndërtuar në Eclipse. Atje, burimet, si në çdo softuer tjetër, jetojnë në formën e skedarëve tekst, ruhen në GIT, degët e kërkesave të tërheqjes, e gjithë kjo. Nga ana negative, nuk e ka lënë statusin beta për shumë vite tani, megjithëse po përmirësohet me çdo lëshim. Unë nuk do të shkruaj për disavantazhet e EDT, sot është një minus, nesër është një veçori fikse. Rëndësia e një përshkrimi të tillë do të zhduket shpejt. Sot është e mundur të zhvillohet në EDT, por është e pazakontë; duhet të përgatiteni për një numër të caktuar gabimesh IDE.

Nëse e shikoni situatën përmes "prizmit 1C" të lartpërmendur, do të merrni diçka të tillë: lëshimi i IDE-së së re nuk rrit shitjet e kutive, por dalja e DEVELOPERS mund të zvogëlohet. Është e vështirë të thuash se çfarë e pret ekosistemin për sa i përket komoditetit të zhvilluesve, por Microsoft tashmë ka dështuar zhvilluesit e celularëve duke u ofruar atyre shërbimet e tij shumë vonë.

Menaxhimi i zhvillimit

Gjithçka këtu është dukshëm më mirë sesa në shkrimin e kodit, veçanërisht kohët e fundit, kur përpjekjet e komunitetit nxorrën në dritë problemet e automatizimit të administrimit, lançuan prototipe që kërkonin hedhjen e depove 1C në grumbullin e plehrave dhe përdorimin e git, fajësimin e shpejtë, rishikimin e kodit , analiza statike, vendosje automatike etj. Në platformë janë shtuar shumë veçori që rrisin nivelin e automatizimit të detyrave të zhvillimit. Sidoqoftë, të gjitha këto veçori u shtuan vetëm dhe ekskluzivisht për zhvillimin e produkteve tona të mëdha, kur u bë e qartë se nuk mund të bënim pa automatizim. Kishte bashkime automatike, krahasim me tre drejtime me KDiff dhe gjithçka. Nisur në Github gitconverter, i cili, sinqerisht, u tërhoq ideologjikisht nga projekti gitsync, por modifikuar për t'iu përshtatur proceseve të kompanisë shitëse. Falë djemve kokëfortë nga burimi i hapur, automatizimi i zhvillimit në 1C doli nga terreni. Një API e hapur për konfiguruesin, IMHO, do të zhvendoste gjithashtu prapambetjen morale të IDE kryesore.

Sot, ruajtja e burimeve 1C në git me angazhime të lidhura me çështjet në Jira, rishikimet në Crucible, butoni i shtypjes nga Jenkins dhe raportet Allure mbi testimin e kodit në 1C dhe madje analiza statike në SonarQube - kjo është larg lajmeve, por më tepër e zakonshme në kompanitë ku ka shumë zhvillim 1C.

administratë

Këtu ka shumë për të thënë. Së pari, ky është, natyrisht, një server (grup serveri 1C). Një gjë e mrekullueshme, por për faktin se është një kuti krejtësisht e zezë, e dokumentuar në detaje të mjaftueshme, por në një mënyrë specifike - zotërimi i nisjes së funksionimit të pandërprerë në modalitetin e ngarkesës së lartë në disa serverë është pjesa e disa të zgjedhurve që veshin një medalje me mbishkrimin “Ekspert për Çështjet Teknologjike”. Vlen të përmendet se, në parim, administrimi i një serveri 1C nuk është i ndryshëm nga administrimi i ndonjë serveri tjetër. Është një aplikacion i bazuar në rrjet, me shumë fije që konsumon memorie, CPU dhe burime të diskut. Ofron mundësi të shumta për mbledhjen dhe diagnostikimin e telemetrisë.

Problemi këtu është se shitësi nuk ofron asgjë të veçantë për sa i përket zgjidhjeve të gatshme për këtë diagnostikim. Po, ekziston 1C: Qendra e Instrumentimit dhe Kontrollit, madje janë mjaft të mira, por janë shumë të shtrenjta dhe jo të gjithë i kanë. Ka një sërë zhvillimesh në komunitet për lidhjen e Grafana, Zabbix, ELK dhe gjëra të tjera nga grupi standard i administratorit, por nuk ka asnjë zgjidhje të vetme që do t'i përshtatet shumicës. Detyra pret heroin e saj. Dhe nëse jeni një biznes që planifikon të nisë në një grup 1C, ju duhet një Ekspert. E juaja brenda ose nga jashtë, por ju duhet. Është normale që ka një rol të veçantë me kompetencat për funksionimin e serverit, jo çdo përdorues i 1C duhet ta dijë këtë, thjesht duhet të kuptoni se një rol i tillë është i nevojshëm. Le të marrim SAP për shembull. Atje, një programues, ka shumë të ngjarë, as nuk do të ngrihet nga karrigia e tij nëse i kërkohet të konfigurojë diçka në serverin e aplikacionit. Ai mund të jetë thjesht budalla dhe nuk do të turpërohet. Në metodologjinë SAP ka një rol të veçantë punonjësi për këtë. Për disa arsye, në industrinë 1C besohet se kjo duhet të kombinohet në një punonjës për të njëjtën pagë. Është një iluzion.

Disavantazhet e serverit 1C

Ekziston saktësisht një minus - besueshmëria. Ose, nëse preferoni, paparashikueshmëria. Sjellja e papritur e çuditshme e serverit tashmë është bërë folja e qytetit. Një ilaç universal - ndalimi i serverit dhe pastrimi i të gjitha cache-ve - përshkruhet madje në manualin e ekspertit, dhe madje rekomandohet një libër grupi që e bën këtë. Nëse sistemi juaj 1C fillon të bëjë diçka që nuk duhet ta bëjë as teorikisht, është koha të pastroni cache-in e të dhënave të sesionit. Sipas vlerësimit tim, janë vetëm tre persona në të gjithë vendin që dinë të përdorin një server 1C pa këtë procedurë dhe nuk ndajnë sekrete, sepse... ata jetojnë nga kjo. Ndoshta sekreti i tyre është se ata pastrojnë të dhënat e sesionit, por nuk i tregojnë askujt për këtë, mik.

Përndryshe, serveri 1C është i njëjti aplikacion si çdo tjetër dhe administrohet pothuajse në të njëjtën mënyrë, duke lexuar dokumentacionin dhe duke trokitur në dajre.

prerës

Dobia e përdorimit të një serveri 1C të kontejneruar në prodhim nuk është provuar ende. Serveri nuk grumbullohet thjesht duke shtuar nyje pas balancuesit, gjë që redukton në minimum përfitimet e kontejnerizimit të prodhimit dhe praktika e funksionimit të suksesshëm në kontejnerë në modalitetin e ngarkesës së lartë nuk është krijuar. Si rezultat, vetëm zhvilluesit përdorin Docker+1C për të vendosur mjedise testimi. Atje është shumë e dobishme, e aplikuar, ju lejon të luani me teknologji moderne dhe të bëni një pushim nga dëshpërimi i konfiguruesit.

Komponent komercial

Nga pikëpamja e investimeve, 1C ju lejon të zgjidhni problemin e nisjes së shpejtë të ideve të biznesit për shkak të aftësive të gjera të klasave të aplikimit. 1C jashtë kutisë jep Raportim shumë të mirë, integrim me çdo gjë, klient në internet, klient celular, aplikacion celular, mbështetje për DBMS të ndryshme, përfshirë. falas, ndër-platformë si pjesë të serverit ashtu edhe të klientit të instaluar. Po, UI e aplikacioneve do të jetë e verdhë, ndonjëherë kjo është një minus, por jo gjithmonë.
Duke zgjedhur 1C, një biznes merr një sërë zgjidhjesh softuerësh që i lejojnë ata të ndërtojnë një gamë shumë të gjerë aplikacionesh, si dhe shumë zhvillues në treg që duan më pak para se Javaistët dhe në të njëjtën kohë prodhojnë rezultate më shpejt.

Për shembull, detyra e dërgimit të një faturë PDF te një klient mund të zgjidhet në një orë punë studentore. I njëjti problem në .NET mund të zgjidhet duke blerë një bibliotekë të pronarit, ose disa ditë ose javë kodimi nga një zhvillues i ashpër dhe me mjekër. Ndonjëherë, të dyja përnjëherë. Dhe po, po flisja vetëm për gjenerimin e PDF-ve. Nuk kemi thënë se nga do të vijë kjo faturë. Përfaqësuesi i uebit duhet të krijojë një formë ku operatori do të futë të dhënat, mbështetësi do të duhet të krijojë modele dto për transferimin e JSON, modele për ruajtjen në bazën e të dhënave, strukturën e vetë bazës së të dhënave, migrimin në të, formimin e një grafiku shfaqja e kësaj llogarie, dhe vetëm atëherë - PDF. Në 1C, e gjithë detyra, nga e para, përfundon saktësisht në një orë.

Një sistem kontabiliteti i plotë për një tezgë të vogël me një proces biznesi blerë/shitur bëhet në 3 orë.Me raportimin e shitjeve, kontabilitetin e mallrave me çmimet e blerjes dhe shitjes, të ndara sipas magazinës, kontrolli i të drejtave të aksesit, klienti në internet dhe aplikacioni celular . Mirë, e harrova aplikimin, me aplikimin jo në 3 orë, në gjashtë.

Sa kohë do t'i duhet kësaj detyre një zhvilluesi .NET nga instalimi i studios vizuale në një kompjuter të pastër deri në demonstrimin e saj te klienti? Po në lidhje me koston e zhvillimit? E njejta gje.

Forcat e 1C si platformë

1C është i fortë jo sepse ka diçka specifike për të që është më e mira në botë. Përkundrazi, në çdo nënsistem individual mund të gjeni një analog më interesant në softuerin botëror. Sidoqoftë, bazuar në një kombinim faktorësh, nuk shoh një platformë të ngjashme me 1C. Këtu qëndron suksesi tregtar. Përparësitë e platformës janë të shpërndara në të dhe janë më qartë të dukshme kur shihni se si bëhet kjo në platforma të tjera. Në thelb, këto NUK janë as veçori, por përkundrazi - një refuzim i veçorive në favor të një paradigme specifike. Disa shembuj:

1. Unicode. Çfarë dreqin mund të jetë më e thjeshtë? Nuk ka nevojë të përdorni kodime ASCII me një bajt në 2019 (përveç integrimit me ato të vjetra të trashëgimisë). kurrë. Por jo. Gjithsesi, dikush në një tabelë përdor një varchar me një bajt dhe aplikacioni do të ketë probleme me kodimet. Në 2015, autorizimi LDAP i gitlab dështoi për shkak të punës së gabuar me kodimet; JetBrains IDE ende nuk funksionon me cirilik në emrat e skedarëve kudo. 1C siguron izolim me cilësi të lartë të kodit të aplikacionit nga shtresa e bazës së të dhënave. Atje është e pamundur të shtypësh tabela në një nivel të ulët dhe bllokimet e të rinjve të paaftë në nivelin e bazës së të dhënave janë të pamundura atje. Po, mund të ketë probleme të tjera me të rinj të paaftë, por shumëllojshmëria e problemeve është shumë më e vogël. Tani do të më thoni që aplikacioni juaj është projektuar saktë dhe shtresa e aksesit në bazën e të dhënave është e izoluar ashtu siç duhet. Hidhini një sy tjetër aplikacionit tuaj të personalizuar Java të korporatës. Afërsisht dhe sinqerisht. A ju shqetëson ndërgjegjja? Atëherë unë jam i lumtur për ju.
2. Numërimi i dokumenteve/librave të referencës. Në 1C nuk është padyshim më fleksibil dhe jo më i miri. Por ajo që ata bëjnë në softuerin bankar dhe në sistemet e kontabilitetit të shkruara vetë - mirë, është thjesht errësirë. Ose identiteti do të ngecë brenda (dhe pastaj "oh, pse kemi vrima"), ose përkundrazi, ata do të bëjnë një gjenerator që funksionon me kyçje në nivelin DBMS (dhe do të bëhet një pengesë). Në fakt, është mjaft e vështirë të bësh këtë detyrë në dukje të thjeshtë - një numërues nga fundi në fund të entiteteve, me një seksion unike të bazuar në një grup të caktuar çelësash, parashtesim, në mënyrë që të mos bllokojë bazën e të dhënave gjatë futjes paralele të të dhënave. .
3. Identifikuesit e të dhënave në bazën e të dhënave. 1C mori një vendim me dëshirë të fortë - të gjithë identifikuesit e lidhjeve janë absolutisht sintetikë dhe kjo është ajo. Dhe nuk ka probleme me bazat e të dhënave të shpërndara dhe shkëmbimet. Zhvilluesit e sistemeve të tjera krijojnë me kokëfortësi diçka si identitet (është më i shkurtër!), i tërhiqni në GUI derisa të vijë koha për të krijuar disa instanca të lidhura (dhe më pas ato do të zbulohen). Nuk e keni këtë? Sinqerisht?
4. Listat. 1C ka mekanizma mjaft të suksesshëm për pagimin nëpër lista (të mëdha) dhe lundrimin nëpër to. Më lejoni të bëj një rezervim menjëherë - me përdorimin e duhur të mekanizmit! Në përgjithësi, tema është mjaft e pakëndshme, ajo nuk mund të zgjidhet në mënyrë ideale: është ose intuitive dhe e thjeshtë (por rreziku i grupeve të mëdha të regjistrimeve për klientin), ose pagimi është i një shtrembërimi. Ata që bëjnë paging shpesh e bëjnë atë në mënyrë të shtrembër. Ata që bëjnë një shirit lëvizës të ndershëm shtojnë një bazë të dhënash, një kanal dhe një klient.
5. Format e menaxhuara. Pa dyshim, në klientin në internet ndërfaqja nuk funksionon në mënyrë perfekte. Por funksionon. Por për shumë sisteme të tjera të kontabilitetit dhe bankar, krijimi i një vendi pune të largët është një projekt i nivelit të ndërmarrjes. Mohim përgjegjësie: për fat të mirë për ata që e bënë fillimisht në ueb, kjo nuk do të ndikojë.
6. Aplikacioni celular. Kohët e fundit, mund të shkruani edhe aplikacione celulare ndërsa jeni në të njëjtin ekosistem. Është pak më e komplikuar këtu sesa me një klient në internet; specifikat e pajisjeve ju detyrojnë të shkruani posaçërisht për ta, por, megjithatë, nuk punësoni një ekip të veçantë zhvilluesish celularë. Nëse keni nevojë për një aplikacion për nevojat e brendshme të një kompanie (kur një zgjidhje celulare për një problem të korporatës është më e rëndësishme se një dizajn i verdhë UI), thjesht përdorni të njëjtën platformë jashtë kutisë.
7. Raportimi. Me këtë fjalë nuk nënkuptoj një sistem BI me të dhëna të mëdha dhe një vonesë në procesin ETL. Kjo i referohet raporteve të stafit operacional që ju lejojnë të vlerësoni gjendjen e kontabilitetit këtu dhe tani. Bilancet, shlyerjet e ndërsjella, rigradimi, etj. 1C del nga kutia me një sistem raportimi me cilësime fleksibël për grupimet, filtrat dhe vizualizimin në anën e përdoruesit. Po, ka analoge më të ftohta në treg. Por jo brenda kornizës së një zgjidhjeje gjithëpërfshirëse dhe me një çmim ndonjëherë më të lartë se një zgjidhje gjithëpërfshirëse. Dhe më shpesh është edhe anasjelltas: vetëm raportim, por më i shtrenjtë se e gjithë platforma dhe më keq në cilësi.
8. Forma të printueshme. Epo, përdorni .NET për të zgjidhur problemin e dërgimit të faturave të pagave në PDF për punonjësit me email. Dhe tani detyra e printimit të faturave. Po në lidhje me ruajtjen e kopjeve të tyre në të njëjtin PDF? Për pseudonimin 1C, nxjerrja e çdo paraqitjeje në PDF është +1 rresht kodi. Kjo do të thotë + 40 sekonda kohë pune, në vend të ditëve ose javëve në një gjuhë tjetër. Paraqitjet e formularëve të printuar në 1C janë tepër të lehta për t'u zhvilluar dhe mjaft të fuqishme për të konkurruar me homologët me pagesë. Po, me siguri, nuk ka shumë mundësi ndërvepruese në dokumentet e tabelave 1C; nuk mund të merrni shpejt një diagram 3D me shkallëzim duke përdorur OpenGL. Por a është vërtet e nevojshme?

Këta janë vetëm një pjesë e vogël e shembujve ku kufizimi i funksionalitetit ose zbatimi i kompromiseve rezulton të jetë një përfitim i rëndësishëm arkitektonik në të ardhmen. Edhe një kompromis apo jo opsioni më efektiv - ai është tashmë në kuti dhe merret si i mirëqenë. Zbatimi i pavarur i tij ose do të jetë i pamundur (sepse vendime të tilla duhet të merren në fillim të projektit dhe nuk ka kohë për këtë dhe nuk ka fare arkitekt), ose disa përsëritje të shtrenjta. Në secilën nga pikat e listuara (dhe kjo nuk është një listë e plotë e zgjidhjeve arkitekturore), mund të prishni dhe të vendosni kufizime që bllokojnë shkallëzimin. Në çdo rast, ju, si biznesmen, duhet të siguroheni që programuesit tuaj, kur bëjnë një "sistem nga e para", të kenë duar të drejta dhe të bëjnë menjëherë mirë çështjet delikate të sistemit.

Po, si në çdo sistem tjetër kompleks, vetë 1C gjithashtu ka zgjidhje që bllokojnë shkallëzimin në aspekte të caktuara. Megjithatë, e përsëris, bazuar në një kombinim faktorësh, koston e pronësisë dhe numrin e problemeve tashmë të zgjidhura paraprakisht, nuk shoh një konkurrent të denjë në treg. Për të njëjtin çmim, ju merrni një kornizë aplikimi financiar, një server të balancuar të grupuar, me një ndërfaqe UI dhe uebfaqe, me një aplikacion celular, me raportim, integrim dhe një mori gjërash të tjera. Në botën e Java-s, ju punësoni një ekip të nivelit të përparëm dhe të fundit, korrigjoni gabimet e nivelit të ulët të kodit të serverit të shkruar në shtëpi dhe paguani veçmas për 2 aplikacione celulare për 2 OS celular.

Nuk po them që 1C do të zgjidhë të gjitha rastet, por për një aplikacion të brendshëm të korporatës, kur nuk ka nevojë të markoni UI - çfarë tjetër nevojitet?

Fluturoni në vaj

Ju ndoshta keni përshtypjen se 1C do të shpëtojë botën dhe se të gjitha mënyrat e tjera të shkrimit të sistemeve të korporatave janë të gabuara. Nuk është aspak kështu. Nga këndvështrimi i një biznesmeni, nëse zgjidhni 1C, atëherë përveç kohës së shpejtë në treg, duhet të merrni parasysh edhe disavantazhet e mëposhtme:

• Besueshmëria e serverit. Kërkohen specialistë vërtet të cilësisë së lartë, të cilët mund të sigurojnë funksionimin e saj të pandërprerë. Unë nuk jam në dijeni të një programi të gatshëm trajnimi për specialistë të tillë nga shitësi. Ka kurse për t'u përgatitur për provimin e Ekspertit, por kjo, për mendimin tim, nuk mjafton.
• Mbështetje. Shih paragrafin e mëparshëm. Për të pasur mbështetje nga shitësi, duhet ta blini atë. Për disa arsye kjo nuk pranohet në industrinë 1C. Dhe me SAP, është pothuajse një blerje e domosdoshme dhe nuk shqetëson askënd. Pa mbështetjen e korporatës dhe pa një ekspert në staf, mund të mbeteni vetëm me defektet 1C.
• Megjithatë, nuk mund të bësh absolutisht gjithçka me 1C. Ky është një mjet dhe si çdo mjet ka kufijtë e zbatueshmërisë. Në peizazhin 1C, është shumë e dëshirueshme të kesh një arkitekt të sistemit "jo-1C".
• Pseudonimet e mira 1C nuk janë më të lira se programuesit e mirë në gjuhë të tjera. Megjithëse, programuesit e këqij janë të shtrenjtë për t'u punësuar, pavarësisht nga gjuha në të cilën shkruajnë.

Le të vendosim pikat

• 1C është një kornizë e zhvillimit të shpejtë të aplikacioneve (RAD) për biznesin dhe është përshtatur për këtë.
• Lidhje me tre nivele me mbështetje për DBMS-të kryesore, ndërfaqen e klientit, një ORM dhe raportim shumë të mirë
• Mundësi të gjera për integrim me sisteme që mund të bëjnë atë që 1C nuk mundet. Nëse dëshironi të mësuarit e makinës, merrni Python dhe dërgoni rezultatin në 1C përmes http ose RabbitMQ
• Nuk ka nevojë të përpiqeni të bëni gjithçka duke përdorur 1C, ju duhet të kuptoni pikat e forta të tij dhe t'i përdorni ato për qëllimet tuaja
• Zhvilluesit që gravitojnë drejt gërmimit në pajisjet e kornizës teknologjike dhe ridizajnimit çdo N vjet në një motor të ri janë të mërzitur me 1C. Gjithçka është shumë konservatore atje.
• Zhvilluesit janë gjithashtu të mërzitur sepse ka shumë pak shqetësim për ta nga prodhuesi. Gjuhë e mërzitshme, IDE e dobët. Ata kërkojnë modernizim.
• Nga ana tjetër, zhvilluesit që nuk mund të argëtohen duke përdorur dhe mësuar një teknologji tjetër që u pëlqen, janë zhvillues të këqij. Ata do të ankohen dhe do të kalojnë në një ekosistem tjetër.
• Punëdhënësit që nuk lejojnë pseudonimet e tyre 1C të shkruajnë diçka në Python janë punëdhënës të këqij. Ata do të humbasin punonjës me mendje kureshtare dhe në vend të tyre do të vijnë kodues majmunësh, të cilët, ndonëse janë dakord me gjithçka, do të tërheqin softuerin e korporatës në moçal. Do të duhet ende të rishkruhet, kështu që ndoshta do të ishte më mirë të investonim pak në Python pak më herët?
• 1C është një kompani tregtare dhe zbaton veçori bazuar vetëm në interesat dhe përshtatshmërinë e saj. Ju nuk mund ta fajësoni atë për këtë, biznesi duhet të mendojë për fitimin, kjo është jeta
• 1C fiton para duke shitur zgjidhje për problemet e biznesit, jo për problemet e zhvilluesve të Vasya. Këto dy koncepte lidhen, por përparësia është pikërisht ajo që thashë. Kur zhvilluesi Vasya është gati të paguajë për një licencë personale për 1C: Resharper, do të shfaqet mjaft shpejt, "Resharper" nga A. Orefkova është dëshmi e kësaj. Nëse shitësi do ta mbështeste atë dhe nuk do të luftonte kundër tij, do të shfaqej një treg për softuer për zhvilluesit. Tani ka një lojtar e gjysmë në këtë treg me rezultate të dyshimta, dhe gjithçka sepse integrimi me IDE është negativ dhe gjithçka bëhet me paterica.
• Praktika e një operatori me shumë makineri do të zhduket në harresë. Aplikacionet moderne janë shumë të mëdha për t'u mbajtur mend si nga ana e kodit ashtu edhe nga ana e përdorimit të biznesit. Serveri 1C po bëhet gjithashtu më kompleks; do të jetë e pamundur të mbash të gjitha llojet e ekspertizës në një punonjës. Kjo duhet të sjellë një kërkesë për specialistë, që do të thotë atraktivitetin e profesionit 1C dhe një rritje të pagave. Nëse më parë Vasya punonte tre në një për një pagë, tani ju duhet të punësoni dy Vasya dhe konkurrenca midis Vasyas mund të nxisë rritjen e përgjithshme të nivelit të tyre.

Përfundim

1C është një produkt shumë i denjë. Në gamën time të çmimeve, nuk di fare analoge, shkruani në komente nëse ka. Sidoqoftë, dalja e zhvilluesve nga ekosistemi po bëhet gjithnjë e më e dukshme, dhe kjo është një "ikje truri", pavarësisht se si e shikoni. Industria është e uritur për modernizim.
Nëse jeni një zhvillues, mos u mbyllni në 1C dhe mos mendoni se gjithçka është magjike në gjuhë të tjera. Ndërsa ju jeni një i ri, ndoshta. Sapo diçka më e madhe duhet të zgjidhet, zgjidhjet e gatshme do të duhet të kërkohen më gjatë dhe të plotësohen më intensivisht. Për sa i përket cilësisë së "blloqeve" nga të cilat mund të ndërtohet një zgjidhje, 1C është shumë, shumë e mirë.

Dhe një gjë tjetër - nëse një pseudonim 1C ju vjen për të punësuar, atëherë pseudonimi 1C mund të emërohet me siguri në pozicionin e analistëve kryesorë. Kuptimi i tyre i detyrës, fushës së lëndës dhe aftësive të dekompozimit është i shkëlqyer. Jam i sigurt se kjo është pikërisht për shkak të përdorimit të detyruar të DDD në zhvillimin e 1C. Personi është i trajnuar të mendojë për kuptimin e detyrës para së gjithash, për lidhjet midis objekteve të fushës lëndore, dhe në të njëjtën kohë ka një sfond teknik në teknologjitë e integrimit dhe formatet e shkëmbimit të të dhënave.

Jini të vetëdijshëm se korniza ideale nuk ekziston dhe kujdesuni për veten.
Të gjitha të mirë!

PS: faleminderit shumë speshurike për ndihmë në përgatitjen e artikullit.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, te lutem

A keni 1C në ndërmarrjen tuaj?

• 13,3%Aspak.71

• 30,3%Ka, por vetëm në departamentin e kontabilitetit diku. Sistemet bazë në platforma të tjera162

• 41,4%Po, proceset kryesore të biznesit punojnë në të221

• 15,0%1C duhet të vdesë, e ardhmja i përket %technology_name%80

534 përdorues kanë votuar. 99 përdorues abstenuan.

Burimi: www.habr.com