🥇1С - Gott og illt. Staðsetning punkta í holivar um 1C

Vinir og félagar, undanfarið hafa verið tíðari greinar um Habré með hatri á 1C sem þróunarvettvangi og ræður frá verjendum þess. Þessar greinar bentu á eitt alvarlegt vandamál: oftast gagnrýna gagnrýnendur 1C það út frá þeirri stöðu að „ráða það ekki“, skamma vandamál sem eru í raun auðveldlega leyst, og þvert á móti, snerta ekki vandamál sem eru virkilega mikilvæg, þess virði. ræða og eru ekki leyst af seljanda. Ég tel að það sé skynsamlegt að framkvæma edrú og yfirvegaða endurskoðun á 1C pallinum. Hvað það getur gert, hvað það getur ekki gert, hvað það ætti að gera en gerir ekki, og, í eftirrétt, hvað það gerir með hvelli, og þróunaraðilar þínir hjá %technology_name% munu gera í hundrað ár og henda því í burtu fleiri en ein árleg fjárhagsáætlun.

Fyrir vikið munt þú, sem stjórnandi eða arkitekt, geta fengið skýran skilning á því hvaða verkefni það er gagnlegt fyrir þig að nota 1C og hvar þarf að brenna það út með heitu járni. Sem verktaki í „non-1C“ heiminum muntu geta séð hvað er í 1C sem veldur læti. Og sem 1C verktaki muntu geta borið saman kerfið þitt við vistkerfi annarra tungumála og skilið staðsetningu þína í hnitakerfi hugbúnaðarþróunar.

Undir niðurskurðinum eru margar þykkar árásir á 1C, á gagnrýnendur 1C, á Java, .NET og almennt... Aðdáandinn er fullur, velkominn!

Um mig

Ég hef verið kunnugur umræðuefninu síðan um það bil 2004. Ég hef verið að forrita sennilega síðan ég var 6 ára, alveg frá því ég fékk bók um prófessor Fortran með myndasögum um kött, spörfugl og maðk. Ég greindi forritin sem kötturinn skrifaði út frá myndunum í bókinni og komst að því hvað þau gerðu. Og já, ég var ekki með alvöru tölvu á þeim tíma, en það var teikning á útbreiðslu bókarinnar og ég ýtti heiðarlega á pappírshnappana og sló inn skipunum sem ég hafði njósnað um köttinn X.

Svo var BK0011 og BASIC í skólanum, C++ og assemblers í háskólanum, svo 1C, og svo margt annað sem ég er of latur til að muna. Síðustu 15 ár hef ég aðallega tekið þátt í 1C, ekki bara hvað varðar kóðun, heldur í 1C almennt. Setja verkefni, stjórna og devops hér. Síðustu 5 ár hef ég tekið þátt í félagslega gagnlegri starfsemi hvað varðar þróun þróunar- og sjálfvirkniverkfæra fyrir aðra 1C notendur, skrifa greinar og bækur.

Við skulum ákveða umræðuefnið

Í fyrsta lagi skulum við skilgreina hvað við ætlum að tala um, þar sem stafirnir „1C“ geta þýtt ýmislegt. Í þessu tilviki, með stöfunum „1C“ er eingöngu átt við þróunarramma „1C: Enterprise“ í nútímalegu, áttundu útgáfunni. Við munum ekki tala mikið um framleiðandann og stefnu hans (en við verðum að gera svolítið við munum ekki ræða sérstök forrit sem eru skrifuð með þessum ramma). Tæknin er aðskilin, forrit aka stillingar eru aðskilin.

Háþróaður arkitektúr 1C: Enterprise

Það er ekki fyrir neitt sem ég nefni orðið „rammi“. Frá sjónarhóli þróunaraðila er 1C vettvangurinn einmitt rammi. Og þú þarft að meðhöndla það nákvæmlega eins og ramma. Hugsaðu um það sem Spring eða ASP.NET, keyrt af einhverjum keyrslutíma (JVM eða CLR í sömu röð). Það vill svo til að í heimi hefðbundinnar forritunar („ekki 1C“) er skiptingin í ramma, sýndarvélar og sértæk forrit eðlileg, vegna þess að þessir íhlutir eru venjulega þróaðir af mismunandi framleiðendum. Í 1C heiminum er ekki venjan að greina beinlínis á þróunarrammanum og keyrslutímanum sjálfum auk þess sem sérstök forrit sem skrifuð eru með rammanum eru einnig aðallega þróuð af 1C sjálfu. Fyrir vikið skapast einhver ruglingur. Þess vegna, innan ramma greinarinnar, verðum við að íhuga 1C frá nokkrum hliðum í einu og flokka það eftir nokkrum hnitaásum. Og í hverjum hnitaás munum við setja skóflu af brúnu efni og skoða eiginleika, kosti og galla núverandi lausnar.

Sjónarmið um 1C

1C fyrir kaupanda

Kaupandi kaupir sjálfvirknikerfi sem hann getur fljótt leyst vandamálin við sjálfvirknivæðingu eigin fyrirtækis. Fyrirtæki getur verið lítið sölubás, eða það getur verið stórt eignarhaldsfélag. Það er ljóst að þarfir þessara fyrirtækja eru mismunandi, en báðar eru studdar af einum vettvangskóðagrunni.

Fyrir 1C kaupandann er þetta fljótur tími á markað. Hratt. Hraðari en Java, C# eða JS. Meðaltal. Í kringum sjúkrahúsið. Það er ljóst að nafnspjaldavefsíða sem notar React mun reynast betri, en bakendi WMS kerfis mun ræsa hraðar á 1C.

1C sem tæki

Hver tæknilausn hefur takmörk fyrir nothæfi. 1C er ekki almennt tungumál það lifir ekki aðskilið frá ramma þess. Það er ráðlegt að nota 1C þegar þú þarft:

netþjónsforrit
umsókn þar sem fjármál koma fram
með tilbúnu notendaviðmóti, ORM, skýrslugerð, XML/JSON/COM/PDF/YourDataTransferingFormat
með stuðningi við bakgrunnsferli og störf
með hlutverkamiðuðu öryggi
með scriptable viðskiptarökfræði
með getu til að búa til frumgerð á fljótlegan hátt og lítinn tíma á markað

Þú þarft ekki 1C ef þú vilt:

vélanám
GPU útreikningar
tölvugrafík
stærðfræðilega útreikninga
CAD kerfi
merkjavinnsla (hljóð, myndband)
háhlaða http símtöl með hundruðum þúsunda rps

1C sem framleiðslufyrirtæki

Það er þess virði að skilja hver viðskipti 1C sem hugbúnaðarframleiðanda eru. 1C fyrirtæki selur lausnir á viðskiptavandamálum með sjálfvirkni. Mismunandi fyrirtæki, stór sem smá, en það er það sem hún selur. Leiðin til að ná þessu markmiði eru viðskiptaforrit. Fyrir bókhald, launabókhald o.fl. Til að skrifa þessar umsóknir notar fyrirtækið sinn eigin viðskiptaforritaþróunarvettvang. Sérstaklega sniðin fyrir algeng verkefni þessara sömu viðskiptaforrita:

fjárhagsbókhald
auðveld aðlögun viðskiptarökfræði
breiðir samþættingarmöguleikar í ólíku upplýsingatæknilandslagi

Sem framleiðandi telur 1C að þetta sé stefnan sem gerir þér kleift að vinna með samstarfsaðilum og viðskiptavinum í win-win ham. Þú getur rökrætt þetta, en þetta er í grófum dráttum hvernig fyrirtækið kynnir sjálft sig: tilbúnar lausnir á viðskiptavandamálum sem samstarfsaðilar geta fljótt aðlagast og samþætta inn í hvaða upplýsingatæknilandslag sem er.

Allar kröfur eða óskir um 1C sem ramma ætti að skoða eingöngu í gegnum þetta prisma. „Við viljum OOP í 1C,“ segja teymið. „Hvað mun það kosta okkur að styðja OOP á pallinum, mun þetta hjálpa okkur að auka sölu á kössum?“ segir 1C. Opnar „prisma“ hans um að selja lausnir á viðskiptavandamálum:

- Hæ, fyrirtæki, viltu OOP í 1C þinn?
- Mun þetta hjálpa mér að leysa vandamálin mín?
- Hver veit...
— Þá er óþarfi

Þessi nálgun getur verið góð eða slæm eftir því hver er að skoða hana, en svona er þetta bara. Talandi um þá staðreynd að það er enginn eiginleiki X í 1C, þá þarftu að skilja að hann er ekki til staðar af ástæðu, heldur í samhengi við valið „framkvæmdarkostnaður vs hagnaðarupphæð“.

Tækniflokkun

„Í raun gera Odinesniks sitt besta til að nota bestu mynstrin, vandlega valin af umhyggjusömum aðferðafræðingum og þróunaraðilum 1C vettvangsins.
Þegar þú skrifar heimskulega kóðann þinn fyrir einfalt stýrt form, ertu í raun að nota módel-skoða-stýring с tvíhliða gagnabindingu в þriggja laga-gagna-app-vél, bragðbætt kortlagning á háu stigi hluttengsla á grunni lýsandi lýsigagnalýsinghafa sína eigin vettvangsóháð fyrirspurnartungumál, C yfirlýsandi gagnadrifið notendaviðmót, algjörlega gagnsæ raðgreining og lénsmiðað forritamál.

Þar sem 1C þróunaraðilar eru frábrugðnir vestrænum samstarfsmönnum sínum er í PR. Þeir elska að gefa hvaða kjaftæði sem er stórt nafn og hlaupa um með það eins og óhreinn poki.“
A. Orefkov

1C pallurinn er með klassískan 3-flokka arkitektúr, í miðju hans er forritaþjónninn (eða eftirlíking hans fyrir lítinn pening fyrir litla verslunareigendur). Annaðhvort MS SQL eða Postgres er notað sem DBMS. Það er líka stuðningur fyrir Oracle og IBM DB2, en þetta er frekar dulspekilegt, enginn veit hvað gerist ef þú innleiðir 1C á þessum gagnagrunnum undir miðlungs og miklu álagi. Ég tel að 1C sjálft viti þetta ekki.

Biðlarahlutinn er annað hvort þunnur biðlari uppsettur á vél notandans eða vefbiðlari. Lykilatriðið er að forritarar skrifa ekki 2 mismunandi kóða, þeir skrifa eitt forrit, á einu tungumáli, og þú getur birt það í vafranum ef það er vilji eða þörf. Hver þar vildi sannan fullan stafla og eitt tungumál fyrir fram- og bakenda, node.js? Þeir náðu aldrei að gera nákvæmlega það sama fyrr en undir lokin. Raunverulegur fullur stafli er til, en þú verður að skrifa hann í 1C. Kaldhæðni örlaganna, svona hlutir :)

Ský SaaS lausnin 1C:Fresh virkar líka í vafraham þar sem ekki er hægt að kaupa 1C heldur leigja lítinn gagnagrunn og fylgjast með sölu shawarma þar. Bara í vafranum, án þess að setja upp eða stilla neitt.

Að auki er til eldri viðskiptavinur, sem í 1C er kallaður „venjulegur umsókn“. Arfleifð er arfleifð, velkomin í heim umsókna árið 2002, en við erum enn að tala um núverandi ástand vistkerfisins.

1C miðlarahlutinn styður klasa og mælikvarða með því að bæta nýjum vélum við klasann. Hér hafa verið brotin töluvert mörg eintök og verður sérstakur kafli í greininni um þetta. Í stuttu máli er þetta ekki alveg það sama og að bæta við nokkrum nákvæmlega sömu tilvikum á bak við HAProxy.

Umgjörð forritaþróunar notar sitt eigið forritunarmál, sem líkist í grófum dráttum örlítið endurbættri VB6 þýdd á rússnesku. Fyrir fólk sem hatar allt rússneskt, sem trúir ekki að „ef“ sé þýtt sem „ef“, er annar setningafræðivalkosturinn í boði. Þeir. Ef þú vilt geturðu skrifað það í 1C á þann hátt að það sé óaðgreinanlegt frá VB.

Þetta forritunarmál er aðalástæðan fyrir hatri 1C gælunöfna á vettvang þeirra. Við skulum horfast í augu við það, ekki að ástæðulausu. Tungumálið var hugsað eins einfalt og hægt var, hannað til að uppfylla möntruna „ÞRÓNARAR, ÞRÓNARAR“ á mælikvarða að minnsta kosti í CIS. Viðskiptakjarni slíkrar lausnar er að mínu mati greinilega sýnilegur: fleiri verktaki, meiri markaðsumfjöllun. Þetta rættist samkvæmt ýmsum áætlunum frá 45% til 95%. Ég segi strax að það er mjög auðveldara að skrifa á því tungumáli sem þú heldur. Og ég kann ansi mörg forritunarmál.

Byrjum á tungumálinu.

1C forritunarmál

Á sama tíma er sterkur og veiki punktur kerfisins. Veitir auðveldan aðgang og læsileika. Aftur á móti hefur það ekki verið uppfært síðan útgáfu 8 kom út árið 2002 og er siðferðilega úrelt. Einhver mun segja "helsti gallinn er að það er engin OOP" og þeir munu hafa rangt fyrir sér. Í fyrsta lagi líkar PLO ekki aðeins við Nuraliev heldur líka Torvalds. Og í öðru lagi, OOP er enn til.

Frá sjónarhóli framkvæmdaraðila hefur hann yfir að ráða ramma með grunnflokkum sem sýndir eru á DBMS. Framkvæmdaraðilinn getur tekið grunnflokkinn „Directory“ og erft „Clients“ möppuna úr honum. Það getur bætt nýjum flokkareitum við það, til dæmis, INN og Address, og einnig, ef nauðsyn krefur, getur það hnekkt (hnekt) aðferðum grunnklasans, til dæmis OnWrite/AtRecord aðferðina.

Umgjörðin er þannig hönnuð að sjaldnast þarf dýpri arfleifð og takmörkunin í OOP er að mínu mati skynsamleg. 1C einbeitir sér að Domain Driven Development og fær þig til að hugsa fyrst og fremst um efnissvið lausnarinnar sem verið er að þróa og þetta er gott. Það er ekki bara engin freisting heldur líka engin þörf á að skrifa 10 mismunandi DTOs og ViewModels bara til að sýna gögn frá léninu einhvers staðar. 1C verktaki starfar alltaf með einni einingu, án þess að klúðra samhengi skynjunar með tugi flokka með svipuðum nöfnum, sem tákna sömu eininguna, en frá annarri hlið. Sérhvert .NET forrit, til dæmis, mun endilega innihalda fimm eða tvö ViewModels og DTOs fyrir raðsetningar í JSON og gagnaflutning frá biðlara til netþjóns. Og um það bil 10-15% af forritskóðanum þínum mun fara í að flytja gögn frá einum flokki til annars með því að nota penna eða hækjur eins og AutoMapper. Það þarf að skrifa þennan kóða og greiða þarf forriturum fyrir að búa til og viðhalda honum.

Það kemur í ljós að erfitt er að þróa 1C tungumálið án þess að flækja það að stigi almennra tungumála og missa þannig kostinn við einfaldleikann. Hvert er verkefni seljanda í meginatriðum að leysa: að gefa út staðlaða lausn sem sérhver nemandi sem er veiddur á götunni getur sérsniðið með tilskildu gæðastigi (þ. Ef þú ert sölubás, taktu nemanda ef þú ert verksmiðja, taktu sérfræðingur frá framkvæmdafélaga þínum. Sú staðreynd að framkvæmdaaðilar selja nemendur á verði sérfræðingur er ekki vandamál með umgjörðina. Byggingarfræðilega séð verður ramminn að leysa vandamál beggja, kóðinn fyrir staðlaðar stillingar (sem við seldum fyrirtækjum með loforð um aðlögun) ætti að vera hægt að skilja af nemanda og sérfræðingur ætti að geta skilið hvað sem þú vilt.

Það sem að mínu mati raunverulega vantar í tungumálið, það sem neyðir þig til að skrifa meira en þú gætir, er það sem sóar tíma sem viðskiptavinurinn greiðir.

Möguleiki á að slá inn á stigi, til dæmis TypeScript (þar af leiðandi þróaðari kóða greiningartæki í IDE, endurstillingu, færri móðgandi jambs)
Framboð aðgerða sem fyrsta flokks hluti. Örlítið flóknara hugtak, en magn dæmigerðs boilerplate-kóða gæti minnkað verulega. Skilningur nemandans á kóðanum, IMHO, myndi jafnvel aukast vegna minnkunar á magni
Alhliða safnbókstafir, frumstillir. Sama hluturinn - að minnka magn kóða sem þarf að skrifa og/eða horfa á með augunum. Að fylla söfn tekur yfir 9000% af 1C forritunartíma. Að skrifa þetta án setningafræðilegs sykurs er langt, dýrt og villuhættulegt. Almennt séð fer magn LOC í 1C lausnum yfir öll hugsanleg mörk miðað við tiltæka opna ramma og almennt öll Java fyrirtæki þitt samanlagt. Tungumálið er orðrétt og þetta hrynur niður í gagnamagn, minni, IDE bremsur, tíma, peninga...
loksins byggingar Ég er með tilgátu um að þessa smíði vanti vegna þess að þeir fundu ekki vel heppnaða þýðingu á henni á rússnesku :)
Eigin gagnategundir (án OOP), hliðstæður af gerð frá VB6. Það gerir þér kleift að skrifa ekki mannvirki með því að nota athugasemdir í BSP og töfraaðferðum sem smíða þessar mannvirki. Við fáum: minni kóða, vísbendingu í gegnum punkt, hraðari lausn á vandamálinu, færri villur vegna innsláttarvillna og vantar eiginleika mannvirkja. Nú hvílir vélritun notendaskipana alfarið á þróunarteymi Standard Subsystem Library, sem, til hróss, skrifar vandlega athugasemdir um væntanlega eiginleika færibreytubygginganna sem hafa verið samþykktar.
Enginn sykur þegar unnið er með ósamstillt símtöl á vefþjóninum. callback-hel í formi ProcessingNotifications er tímabundin hækja sem orsakast af skyndilegri breytingu á API helstu vafra, en þú getur ekki lifað svona allan tímann að kosturinn við „skilning nemenda“ á ósamstilltum kóða er að glatast fleiri og fleiri. Bættu engan stuðning við þessa hugmyndafræði í aðal IDE og hlutirnir versna enn.

Þetta er eitt af brýnu vandamálunum, það er ljóst að listinn gæti verið miklu stærri, en við megum ekki gleyma því að þetta er samt ekki almennt tungumál, það krefst ekki fjölþráða, lambda aðgerða, aðgang að GPU og hratt útreikningar með flotpunkti. Þetta er viðskiptarökfræði forskriftarmál.

Forritari sem hefur þegar unnið mikið með þetta tungumál, skoðar js eða c#, leiðist innan ramma þessa tungumáls. Það er staðreynd. Hann þarf þroska. Á hinni hliðinni á skalanum fyrir seljanda er kostnaðurinn við að innleiða tilgreinda eiginleika á móti aukningu tekna eftir innleiðingu þeirra. Hér hef ég engar upplýsingar um það sem nú vegur þyngra í augum félagsins.

Þróunarumhverfi

Hlutirnir ganga heldur ekki snurðulaust fyrir sig hér. Það eru tvö þróunarumhverfi. Sá fyrsti er Configurator sem fylgir með afhendingu. Annað er Enterprise Development Tools umhverfið, eða EDT í stuttu máli, þróað á grundvelli Eclipse.

Stillingarbúnaðurinn býður upp á alhliða þróunarverkefni, styður alla eiginleika og er aðalumhverfið á markaðnum. Það er líka siðferðilega úrelt, ekki að þróast, samkvæmt sögusögnum - vegna magns tæknilegra skulda innra með sér. Hægt væri að bæta ástandið með því að opna innra API (í formi vináttu við Snjókarl A. Orefkova eða á sjálfstæðum grundvelli), en svo er ekki. Æfingin hefur sýnt að samfélagið mun skrifa eigin eiginleika í IDE, svo framarlega sem seljandinn truflar ekki. En við höfum það sem við höfum. Stillingin var frábær á árunum 2004-2005, minnti mjög á Visual Studio þess tíma, sums staðar var hann enn svalari, en hann var fastur á þeim tímum.

Að auki hefur rúmmál meðalstaðlaðrar lausnar vaxið nokkrum sinnum síðan þá, og í dag getur IDE einfaldlega ekki ráðið við magn kóðans sem það er fóðrað með. Nothæfi og endurstillingargeta er ekki einu sinni núll, þeir eru í mínus. Allt þetta eykur ekki eldmóð hjá hönnuðunum og þá dreymir um að flytjast yfir í önnur vistkerfi og halda áfram að kóða skítinn þar, en í notalegu umhverfi sem hrækir ekki í andlitið á þér með hegðun sinni.

Í staðinn er boðið upp á IDE skrifað frá grunni, byggt á Eclipse. Þar eru heimildirnar, eins og í öðrum hugbúnaði, í formi textaskráa, eru geymdar í GIT, draga beiðnigreinar, allt þetta. Hins vegar hefur það ekki yfirgefið beta stöðu í mörg ár núna, þó að það batni með hverri útgáfu. Ég mun ekki skrifa um ókosti EDT, í dag er það mínus, á morgun er það fastur eiginleiki. Mikilvægi slíkrar lýsingar mun fljótt hverfa. Í dag er hægt að þróa í EDT, en það er óvenjulegt að þú þarft að vera tilbúinn fyrir ákveðinn fjölda IDE galla.

Ef þú horfir á ástandið í gegnum áðurnefnt „1C prisma“ færðu eitthvað á þessa leið: útgáfa nýja IDE eykur ekki sölu á kössum, en útflæði þróunaraðila gæti minnkað. Það er erfitt að segja hvað bíður vistkerfisins hvað varðar þægindi þróunaraðila, en Microsoft hefur þegar klúðrað farsímahönnuðum með því að bjóða þeim þjónustu sína of seint.

Þróunarstjórnun

Allt hér er umtalsvert betra en að skrifa kóða, sérstaklega nýlega, þegar viðleitni samfélagsins dró fram í dagsljósið vandamálin við sjálfvirkni stjórnsýslunnar, hleypti af stokkunum frumgerðum sem kalla á að henda 1C geymslunni í ruslahauginn og nota git, skjóta sök, kóða-endurskoðun , kyrrstöðugreining, sjálfvirk dreifing og o.s.frv. Mörgum eiginleikum hefur verið bætt við pallinn sem auka sjálfvirkni þróunarverkefna. Hins vegar var öllum þessum eiginleikum bætt við eingöngu og eingöngu til að þróa okkar eigin stóru vörur, þegar það varð augljóst að við gætum ekki verið án sjálfvirkni. Það voru sjálfvirkar sameiningar, þríhliða samanburður við KDiff og allt það. Hleypt af stokkunum á Github gitconverter, sem satt að segja var hugmyndafræðilega dreginn frá verkefninu gitsync, en breytt til að henta ferlum seljanda fyrirtækisins. Þökk sé þrjósku strákunum frá opnum uppsprettu, fór sjálfvirkni þróunar í 1C af stað. Opið API fyrir stillingarforritið, IMHO, myndi einnig breyta siðferðislegu afturhaldi aðal IDE.

Í dag, að geyma 1C heimildir í git með skuldbindingum tengdum málum í Jira, umsögnum í Crucible, ýta á hnapp frá Jenkins og Allure skýrslur um kóðapróf í 1C og jafnvel kyrrstöðugreining í SonarQube - þetta er langt frá því að vera fréttir, heldur almennt í fyrirtækjum þar sem mikil 1C þróun er.

Stjórnsýsla

Hér er margt að segja. Í fyrsta lagi er þetta auðvitað netþjónn (1C miðlaraþyrping). Dásamlegur hlutur, en vegna þeirrar staðreyndar að þetta er algjörlega svartur kassi, skjalfestur í nægilega nákvæmum smáatriðum, en á ákveðinn hátt - að ná tökum á því að hefja óslitið starf í háhleðsluham á nokkrum netþjónum er hlutskipti fárra útvalinna sem klæðast medalíu með áletruninni „Sérfræðingur í tæknimálum“. Það er athyglisvert að í grundvallaratriðum er stjórnun 1C netþjóns ekkert frábrugðin því að stjórna öðrum þjónum. Það er nettengt, fjölþráða forrit sem eyðir minni, örgjörva og diskaauðlindum. Veitir næg tækifæri til söfnunar og greiningar fjarmælinga.

Vandamálið hér er að seljandinn býður ekki upp á neitt sérstakt hvað varðar tilbúnar lausnir fyrir einmitt þessa greiningu. Já, það er til 1C: Instrumentation and Control Center, þeir eru meira að segja nokkuð góðir, en þeir eru mjög dýrir og ekki allir sem eiga þá. Það er ýmislegt í samfélaginu til að tengja Grafana, Zabbix, ELK og annað úr venjulegu stjórnunarsettinu, en það er engin ein lausn sem hentar meirihlutanum. Verkefnið bíður hetju þess. Og ef þú ert fyrirtæki sem ætlar að setja af stað á 1C klasa, þá þarftu sérfræðing. Þitt eigið að innan eða utan, en þú þarft á því að halda. Það er eðlilegt að það sé sérstakt hlutverk með hæfni til að reka netþjóna, ekki allir 1C notendur ættu að vita þetta, þú þarft bara að skilja að slíkt hlutverk er nauðsynlegt. Tökum SAP sem dæmi. Þar mun forritari líklegast ekki einu sinni standa upp úr stólnum ef hann er beðinn um að stilla eitthvað á forritaþjóninum. Hann gæti bara verið heimskur og hann mun ekki skammast sín. Í SAP aðferðafræðinni er sérstakt starfsmannahlutverk fyrir þetta. Einhverra hluta vegna er talið að í 1C-iðnaðinum ætti að sameina þetta í einn starfsmann fyrir sömu laun. Það er blekking.

Ókostir 1C miðlara

Það er nákvæmlega einn mínus - áreiðanleiki. Eða, ef þú vilt, ófyrirsjáanleika. Skyndileg undarleg hegðun netþjónsins er þegar orðin umtalsefni. Alhliða úrræði - að stöðva netþjóninn og hreinsa öll skyndiminni - er meira að segja lýst í handbók sérfræðingsins og jafnvel er mælt með lotubók sem gerir þetta. Ef 1C kerfið þitt byrjar að gera eitthvað sem það ætti ekki einu sinni fræðilega að gera, þá er kominn tími til að hreinsa skyndiminni lotugagnanna. Samkvæmt mínu mati eru aðeins þrír menn á öllu landinu sem kunna að reka 1C netþjón án þessarar aðferðar og þeir deila ekki leyndarmálum, vegna þess að... þeir lifa af þessu. Kannski er leyndarmál þeirra að þeir hreinsa fundargögn, en þeir segja engum frá því, náungi.

Annars er 1C þjónninn sama forritið og hvert annað og er stjórnað á svipaðan hátt, með því að lesa skjölin og banka á tambúrínuna.

Docker

Notagildi þess að nota 1C netþjón með gáma í framleiðslu hefur ekki enn verið sannað. Miðlarinn er ekki flokkaður með því einfaldlega að bæta við hnútum fyrir aftan jafnvægisbúnaðinn, sem dregur úr ávinningi af gámavæðingu framleiðslu í lágmarki, og æfingin á farsælum rekstri í gámum í háhleðsluham hefur ekki verið staðfest. Þess vegna nota aðeins verktaki Docker+1C til að setja upp prófunarumhverfi. Þar er það mjög gagnlegt, notað, gerir þér kleift að leika þér með nútímatækni og taka þér hlé frá örvæntingu stillingarbúnaðarins.

Viðskiptaþáttur

Frá fjárfestingarsjónarmiði gerir 1C þér kleift að leysa vandamálið við að koma viðskiptahugmyndum af stað fljótt vegna víðtækrar getu umsóknarflokka. 1C út úr kassanum gefur mjög viðeigandi skýrslugerð, samþættingu við hvað sem er, vefbiðlara, farsímaforrit, farsímaforrit, stuðning fyrir ýmsar DBMS, þ.m.t. ókeypis, þvert á vettvang, bæði miðlara og uppsetta biðlarahluta. Já, notendaviðmót forrita verður gult, stundum er þetta mínus, en ekki alltaf.
Með því að velja 1C fær fyrirtæki sett af hugbúnaðarlausnum sem gera þeim kleift að byggja upp mjög breitt úrval af forritum, auk fjölda forritara á markaðnum sem vilja minna fé en Javaistar og skila á sama tíma hraðar árangri.

Til dæmis er hægt að leysa það verkefni að senda PDF reikning til viðskiptavinar á klukkutíma vinnu nemenda. Sama vandamálið í .NET er hægt að leysa með því að kaupa sérbókasafn, eða nokkra daga eða vikur af kóðun af stirðum, skeggjaðri þróunaraðila. Stundum, bæði í einu. Og já, ég var aðeins að tala um PDF kynslóð. Við höfum ekki einu sinni sagt hvaðan þetta frumvarp kemur. Vefframleiðandinn verður að búa til eyðublað þar sem rekstraraðilinn mun slá inn gögnin, bakþjónninn þarf að búa til dto líkön til að flytja JSON, líkön til að geyma í gagnagrunninum, uppbygging gagnagrunnsins sjálfs, flutning til hans, myndun myndræns birtingu þessa reiknings, og aðeins þá - PDF. Á 1C er öllu verkefninu, frá grunni, lokið á nákvæmlega einni klukkustund.

Fullbúið bókhaldskerfi fyrir lítinn sölubás með einu viðskiptaferli keypt/selt er gert á 3 klukkustundum með söluskýrslu, bókhaldi vöru á innkaupa- og söluverði, sundurliðað eftir vöruhúsum, aðgangsréttareftirliti, vefbiðlara og farsímaforriti. . Allt í lagi, ég gleymdi umsókninni, með umsókninni ekki eftir 3 klukkustundir, á sex.

Hversu langan tíma mun þetta verkefni taka .NET verktaki frá því að setja upp sjónræna vinnustofu á hreina tölvu til að sýna viðskiptavininum það? Hvað með þróunarkostnaðinn? Sami hlutur.

Styrkleikar 1C sem vettvangur

1C er sterkur ekki vegna þess að það er eitthvað sérstakt við það sem er það besta í heiminum. Þvert á móti, í hverju undirkerfi fyrir sig er hægt að finna áhugaverðari hliðstæðu í hugbúnaði heimsins. Hins vegar, miðað við samsetningu þátta, sé ég ekki vettvang svipað og 1C. Þetta er þar sem viðskiptalegur árangur liggur. Kostir pallsins eru á víð og dreif og sjást best þegar þú sérð hvernig þetta er gert á öðrum vettvangi. Í grundvallaratriðum eru þetta EKKI einu sinni eiginleikar, heldur þvert á móti - höfnun á eiginleikum í þágu einni ákveðinni hugmyndafræði. Nokkur dæmi:

Unicode. Hvað í fjandanum gæti verið einfaldara? Það er engin þörf á að nota eins-bæta ASCII kóðun árið 2019 (nema samþættingu við forna eldri). Aldrei. En nei. Engu að síður, einhver í einhverri töflu notar einn-bæta varchar og forritið mun eiga í vandræðum með kóðun. Árið 2015 mistókst LDAP heimild gitlab vegna rangrar vinnu með kóðun JetBrains IDE virkar enn ekki með kyrillísku í skráarnöfnum alls staðar. 1C veitir hágæða einangrun á forritakóða frá gagnagrunnslaginu. Þar er ómögulegt að slá inn töflur á lágu stigi og jambs af vanhæfum yngri á gagnagrunnsstigi eru ómögulegar þar. Já, það geta verið önnur vandamál þar frá óhæfum yngri börnum, en fjölbreytnin í vandamálum er mun minni. Nú muntu segja mér að forritið þitt sé rétt hannað og gagnagrunnsaðgangslagið er einangrað eins og það á að vera. Skoðaðu aftur sérsniðið Java forritið þitt. Náið og heiðarlega. Truflar samviskan þig? Þá er ég ánægður með þig.
Númerun skjala/heimildabóka. Í 1C er það örugglega ekki það sveigjanlegasta og ekki það besta. En það sem þeir gera í bankahugbúnaði og í sjálfskrifuðum bókhaldskerfum - jæja, það er bara myrkur. Annaðhvort verður sjálfsmynd föst í (og svo „ó, af hverju höfum við göt“), eða þvert á móti munu þeir búa til rafall sem vinnur með læsingu á DBMS stigi (og verður flöskuháls). Reyndar er frekar erfitt að gera þetta að því er virðist einfalda verkefni - enda-til-enda teljara aðila, með sérstöðuhluta sem byggir á ákveðnu setti lykla, forskeyti, svo að það loki ekki gagnagrunninum við samhliða innslátt gagna. .
Auðkenni skráa í gagnagrunninum. 1C tók viljasterka ákvörðun - öll tenglaauðkenni eru algjörlega tilbúin og það er allt. Og það eru engin vandamál með dreifða gagnagrunna og kauphallir. Hönnuðir annarra kerfa búa þrjósklega til eitthvað eins og sjálfsmynd (það er styttra!), draga þau inn í GUI þar til það er kominn tími til að búa til nokkur tengd tilvik (og þá verða þau uppgötvað). Áttu þetta ekki? Heiðarlega?
Listar. 1C hefur nokkuð vel heppnaða aðferð til að fletta í gegnum (stóra) lista og fletta í gegnum þá. Leyfðu mér að bóka strax - með réttri notkun vélbúnaðarins! Almennt séð er efnið frekar óþægilegt, það er ekki hægt að leysa það sem best: það er annaðhvort leiðandi og einfalt (en hættan á risastórum færslum á viðskiptavininum) eða síðuskipun er af einum eða öðrum skakka. Þeir sem stunda boðskipti gera það oft skakkt. Þeir sem búa til heiðarlega skrunstiku bæta við gagnagrunni, rás og biðlara.
Stýrt eyðublöð. Eflaust, í vefþjóninum virkar viðmótið ekki fullkomlega. En það virkar. En fyrir mörg önnur bókhalds- og bankakerfi er það verkefni á fyrirtækisstigi að búa til afskekktan vinnustað. Fyrirvari: sem betur fer fyrir þá sem upphaflega gerðu það á vefnum, mun þetta ekki hafa áhrif.
Farsímaforrit. Nýlega geturðu líka skrifað farsímaforrit meðan þú ert í sama vistkerfi. Það er aðeins flóknara hér en með vefbiðlara, sérkenni tækja neyða þig til að skrifa sérstaklega fyrir þau, en engu að síður ræður þú ekki sérstakt teymi farsímahönnuða. Ef þig vantar forrit fyrir innri þarfir fyrirtækis (þegar farsímalausn á fyrirtækisvandamáli er mikilvægari en gul UI hönnun), þá notarðu einfaldlega sama vettvang úr kassanum.
Skýrslugerð. Með þessu orði á ég ekki við BI kerfi með stórum gögnum og töf á ETL ferlinu. Hér er átt við skýrslur rekstrarstarfsmanna sem gera þér kleift að meta stöðu bókhalds hér og nú. Jafnvægi, gagnkvæmt uppgjör, endurflokkun o.fl. 1C kemur út úr kassanum með skýrslukerfi með sveigjanlegum stillingum fyrir hópa, síur og sjónmynd á notendahliðinni. Já, það eru til kaldari hliðstæður á markaðnum. En ekki innan ramma alls-í-einnar lausnar og á verði sem stundum er hærra en allt-í-einn lausn. Og oftar er það jafnvel á hinn veginn: aðeins skýrslugerð, en dýrari en allur pallurinn og verri að gæðum.
Prentvæn eyðublöð. Jæja, notaðu .NET til að leysa vandamálið við að senda launaseðla í PDF til starfsmanna með tölvupósti. Og nú verkefnið að prenta reikninga. Hvað með að vista afrit þeirra á sama PDF? Fyrir 1C gælunafn er +1 kóðalína að gefa út hvaða útlit sem er í PDF. Þetta þýðir + 40 sekúndur af vinnutíma, í stað daga eða vikna á öðru tungumáli. Prentað eyðublað í 1C er ótrúlega auðvelt að þróa og nógu öflugt til að keppa við gjaldskylda hliðstæða. Já, líklega, það eru ekki mörg gagnvirk tækifæri í 1C töflureiknisskjölum, þú getur ekki fengið 3D skýringarmynd með mælikvarða með því að nota OpenGL. En er það virkilega nauðsynlegt?

Þetta eru aðeins örfá dæmi þar sem takmarkandi virkni eða innleiðing málamiðlana reynist vera mikilvægur byggingarlistarlegur ávinningur í framtíðinni. Jafnvel málamiðlun eða ekki árangursríkasti kosturinn - hann er nú þegar í kassanum og þykir sjálfsagður. Sjálfstæð útfærsla þess verður annaðhvort ómöguleg (vegna þess að slíkar ákvarðanir verða að vera teknar í upphafi verkefnis, og það er enginn tími til þess, og það er enginn arkitekt), eða nokkrar dýrar endurtekningar. Í hverjum og einum upptalinna punkta (og þetta er ekki tæmandi listi yfir byggingarlausnir) geturðu skrúfað fyrir og sett upp takmarkanir sem hindra skala. Í öllum tilvikum, þú, sem kaupsýslumaður, þarft að ganga úr skugga um að forritarar þínir, þegar þeir búa til „kerfi frá grunni“, hafi beinar hendur og muni leysa lúmsk kerfisvandamál strax vel.

Já, eins og í hverju öðru flóknu kerfi, hefur 1C sjálft einnig lausnir sem hindra skala í ákveðnum þáttum. Hins vegar endurtek ég, miðað við samsetningu þátta, eignarkostnaðar og fjölda vandamála sem þegar eru leyst fyrirfram, sé ég ekki verðugan keppinaut á markaðnum. Fyrir sama verð færðu fjárhagslega umsóknarramma, samsettan netþjón, með notendaviðmóti og vefviðmóti, með farsímaforriti, með skýrslugerð, samþættingu og fullt af öðru. Í Java heiminum ræður þú framenda- og bakendateymi, kembiforrit á lágu stigi af heimaskrifuðum miðlarakóða og borgar sérstaklega fyrir 2 farsímaforrit fyrir 2 farsímakerfi.

Ég er ekki að segja að 1C muni leysa öll mál, heldur fyrir innri fyrirtækjaumsókn, þegar engin þörf er á að merkja notendaviðmótið - hvað annað þarf?

Fly í smyrslið

Þú hefur líklega fengið á tilfinninguna að 1C muni bjarga heiminum og að allar aðrar leiðir til að skrifa fyrirtækjakerfi séu rangar. Það er alls ekki þannig. Frá sjónarhóli kaupsýslumanns, ef þú velur 1C, þá til viðbótar við hraðan tíma á markað, verður þú að taka tillit til eftirfarandi ókosta:

Áreiðanleiki netþjóns. Krafist er virkilega vandaðra sérfræðinga sem geta tryggt óslitinn rekstur þess. Mér er ekki kunnugt um tilbúna þjálfun fyrir slíka sérfræðinga frá söluaðilanum. Það eru námskeið til að undirbúa sérfræðiprófið, en þetta er ekki nóg að mínu mati.
Stuðningur. Sjá fyrri málsgrein. Til að fá stuðning frá seljanda þarftu að kaupa það. Af einhverjum ástæðum er þetta ekki samþykkt í 1C iðnaði. Og með SAP er það næstum því sem þarf að kaupa og það truflar engan. Án fyrirtækjastuðnings og án sérfræðings um starfsfólk geturðu verið í friði með 1C galla.
Samt geturðu ekki gert nákvæmlega allt með 1C. Þetta er tól og eins og hvert tól hefur það takmörk fyrir nothæfi. Í 1C landslaginu er mjög æskilegt að hafa „non-1C“ kerfisarkitekt.
Góð 1C gælunöfn eru ekkert ódýrari en góðir forritarar á öðrum tungumálum. Þó er dýrt að ráða slæma forritara, burtséð frá tungumálinu sem þeir skrifa á.

Við skulum punkta punktana

1C er hröð umsóknarþróun (RAD) ramma fyrir fyrirtæki og er sniðin fyrir þetta.
Þriggja hæða hlekkur með stuðningi við helstu DBMS, viðskiptavinaviðmót, mjög gott ORM og skýrslugerð
Miklir möguleikar á samþættingu við kerfi sem geta gert það sem 1C getur ekki. Ef þú vilt vélanám skaltu taka Python og senda niðurstöðuna til 1C í gegnum http eða RabbitMQ
Það er engin þörf á að leitast við að gera allt með 1C, þú þarft að skilja styrkleika þess og nota þá í þínum eigin tilgangi
Hönnuðir sem sækjast eftir því að grafa sig inn í tæknilegar rammagræjur og endurhanna á N-ára fresti í nýja vél leiðast 1C. Þar er allt mjög íhaldssamt.
Hönnurum leiðist líka vegna þess að framleiðandinn hefur mjög litlar áhyggjur af þeim. Leiðinlegt tungumál, veik IDE. Þeir krefjast nútímavæðingar.
Aftur á móti eru forritarar sem geta ekki fundið gaman með því að nota og læra aðra tækni sem þeir hafa gaman af eru slæmir verktaki. Þeir munu væla og flytja í annað vistkerfi.
Vinnuveitendur sem leyfa ekki 1C gælunöfnum sínum að skrifa eitthvað í Python eru slæmir vinnuveitendur. Þeir munu missa starfsmenn með fróðleiksfúsum huga og í þeirra stað koma apakóðarar sem, þó að þeir séu sammála öllu, draga fyrirtækjahugbúnað út í mýrina. Það verður samt að endurskrifa það, svo kannski væri betra að fjárfesta aðeins í Python aðeins fyrr?
1C er viðskiptafyrirtæki og innleiðir eiginleika sem byggjast eingöngu á eigin hagsmunum og hagkvæmni. Þú getur ekki kennt henni um þetta, fyrirtæki verða að hugsa um hagnað, svona er lífið
1C græðir á því að selja lausnir á viðskiptavandamálum, ekki vandamálum þróunaraðila Vasya. Þessi tvö hugtök eru í samræmi, en forgangurinn er nákvæmlega það sem ég sagði. Þegar verktaki Vasya er tilbúinn að borga fyrir persónulegt leyfi fyrir 1C: Resharper, mun það birtast nokkuð fljótt, "Resharper" eftir A. Orefkova er sönnun þess. Ef söluaðilinn styddi það, og barðist ekki gegn því, myndi skapast markaður fyrir hugbúnað fyrir þróunaraðila. Núna er einn og hálfur aðili á þessum markaði með vafasaman árangur og allt vegna þess að samþættingin við IDE er neikvæð og allt er gert á hækjum.
Starfsemi fjölvélastjóra mun hverfa í gleymskunnar dá. Nútímaforrit eru of stór til að muna bæði frá kóðahliðinni og frá viðskiptahliðinni. 1C þjónninn er líka að verða flóknari og það verður ómögulegt að hafa allar tegundir af sérfræðiþekkingu í einum starfsmanni. Þetta ætti að hafa í för með sér eftirspurn eftir sérfræðingum, sem þýðir aðdráttarafl 1C starfsgreinarinnar og hækkun launa. Ef Vasya vann áður þrír-í-einn fyrir ein laun, nú þarftu að ráða tvo Vasyas og samkeppni meðal Vasyas getur ýtt undir heildarvöxt stigs þeirra.

Ályktun

1C er mjög verðug vara. Í mínu verðbili þekki ég engar hliðstæður, skrifaðu í athugasemdirnar ef þær eru til. Hins vegar er útflæði þróunaraðila úr vistkerfinu sífellt meira áberandi og þetta er „atvinnuflótti“, sama hvernig á það er litið. Iðnaðurinn hungrar í nútímavæðingu.
Ef þú ert þróunaraðili skaltu ekki hengja þig á 1C og halda ekki að allt sé töfrandi á öðrum tungumálum. Á meðan þú ert yngri, kannski. Um leið og leysa þarf eitthvað stærra þarf að leita lengur að tilbúnum lausnum og klára þær með auknum hætti. Hvað varðar gæði „blokkanna“ sem hægt er að byggja lausn úr, þá er 1C mjög, mjög gott.

Og eitt enn - ef 1C gælunafn kemur til þín til að ráða, þá er hægt að skipa 1C gælunafnið á öruggan hátt í stöðu aðalsérfræðinga. Skilningur þeirra á verkefninu, efnissviðinu og niðurbrotsfærni er frábær. Ég er viss um að þetta er einmitt vegna þvingaðrar notkunar DDD í 1C þróun. Einstaklingur er þjálfaður í að hugsa um merkingu verkefnis fyrst og fremst, um tengsl milli hluta viðfangsefnisins, og hefur á sama tíma tæknilegan bakgrunn í samþættingartækni og gagnaskiptasniðum.

Vertu meðvituð um að kjörinn rammi er ekki til og farðu vel með þig.
Gott fyrir alla!

PS: takk kærlega speshuric um aðstoð við gerð greinarinnar.

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Ertu með 1C í fyrirtækinu þínu?

13,3%Alls ekki.71
30,3%Það er, en bara í bókhaldsdeildinni einhvers staðar. Kjarnakerfi á öðrum kerfum162
41,4%Já, helstu viðskiptaferlar vinna á it221
15,0%1C verður að deyja, framtíðin tilheyrir %technology_name%80

534 notendur kusu. 99 notendur sátu hjá.

Heimild: www.habr.com

1C - Gott og illt. Fyrirkomulag punkta í holivar um 1C