Sõbrad ja kolleegid, viimasel ajal on Habré kohta sagedamini ilmunud artikleid, mis vihkavad 1C kui arendusplatvormi vastu, ja selle kaitsjate kõnesid. Nendes artiklites tuvastati üks tõsine probleem: enamasti kritiseerivad 1C kriitikud seda positsioonilt "ei valda seda", noomivad probleeme, mis on de facto kergesti lahendatavad, ja vastupidi, ei puuduta probleeme, mis on tõesti olulised, väärt. arutatakse ja müüja neid ei lahenda. Usun, et 1C platvormi kaine ja tasakaalustatud ülevaatamine on mõttekas. Mida see suudab, mida ta ei suuda, mida ta peaks tegema, aga ei tee, ja magustoiduks, mida see suure hooga teeb, ja teie %technology_name% arendajad teevad seda sada aastat, visates selle minema rohkem kui üks aastaeelarve.
Selle tulemusel saate juhi või arhitektina selge ülevaate sellest, mis ülesandeks on teile 1C kasutamine kasulik ja kus tuleb see kuuma triikrauaga läbi põletada. Mitte-1C maailmas arendajana näete, mis on 1C-s, mis segab. Ja 1C arendajana saate võrrelda oma süsteemi teiste keelte ökosüsteemidega ja mõista oma asukohta tarkvaraarenduse koordinaatsüsteemis.
Lõika all on palju pakse rünnakuid 1C-le, 1C kriitikutele, Java-le, .NET-ile ja üldse... Fänn on täis, tere tulemast!
Minust
Olen vestlusteemaga kursis umbes aastast 2004. Olen programmeerimisega tegelenud vist 6. eluaastast saati, sellest hetkest, kui sain professor Fortrani raamatu koos koomiksitega kassist, varblast ja röövikust. Analüüsisin programme, mida kass raamatus olevate piltide järgi kirjutas, ja sain teada, mida nad tegid. Ja jah, mul polnud tol ajal päris arvutit, aga raamatu leviku kohta oli joonis ja ma vajutasin ausalt paberinuppe, sisestades käsklusi, mida olin kassi X järele luuranud.
Siis olid koolis BK0011 ja BASIC, ülikoolis C++ ja assemblerid, siis 1C ja siis nii palju muud, mida ma olen liiga laisk meenutama. Viimased 15 aastat olen tegelenud peamiselt 1C-ga, mitte ainult kodeerimise, vaid 1C-ga üldiselt. Siin saate seadistada ülesandeid, administreerida ja arendada. Viimased 5 aastat olen tegelenud sotsiaalselt kasulike tegevustega, mis puudutab arendus- ja automatiseerimistööriistade väljatöötamist teistele 1C kasutajatele, artiklite ja raamatute kirjutamist.
Otsustame arutluse teema üle
Esiteks määratleme, millest me räägime, kuna tähed "1C" võivad tähendada palju asju. Sel juhul peame tähtede “1C” all silmas eranditult kaasaegse, kaheksanda versiooni arendusraamistikku “1C: Enterprise”. Tootjast ja selle poliitikast me palju ei räägi (aga me peame natuke tegema). Tehnoloogia on eraldi, rakendused ehk konfiguratsioonid on eraldi.
Kõrgetasemeline arhitektuur 1C: Enterprise
Ma ei maini asjata sõna "raamistik". Arendaja vaatenurgast on 1C platvorm täpselt raamistik. Ja peate seda käsitlema täpselt nagu raamistikku. Mõelge sellele kui Spring või ASP.NET, mida käivitab mõni käitusaeg (vastavalt JVM või CLR). Juhtub nii, et tavapärase programmeerimise (“mitte 1C”) maailmas on raamistikeks, virtuaalmasinateks ja konkreetseteks rakendusteks jagunemine loomulik, kuna neid komponente arendavad tavaliselt erinevad tootjad. 1C maailmas pole tavaks arendusraamistikku ja käitusaega ennast selgesõnaliselt eristada, lisaks arendab raamistiku abil kirjutatud konkreetseid rakendusi peamiselt 1C ise. Selle tulemusena tekib teatav segadus. Seetõttu peame artikli raames kaaluma 1C-d korraga mitmest küljest ja klassifitseerima seda mööda mitut koordinaattelge. Ja igale koordinaatteljele paneme labida pruuni ainet ja vaatame olemasoleva lahenduse omadusi, eeliseid ja puudusi.
Vaatepunktid 1C-l
1C ostjale
Ostja ostab automaatikasüsteemi, millega saab kiiresti lahendada enda äri automatiseerimise probleemid. Ettevõte võib olla väike müügilett või suur valdusettevõte. On selge, et nende ettevõtete vajadused on erinevad, kuid mõlemat toetab üks platvormi koodibaas.
1C ostja jaoks on see kiire turule jõudmise aeg. Kiire. Kiirem kui Java, C# või JS. Keskmine. Haigla ümber. On selge, et Reacti kasutav visiitkaartide veebisait tuleb paremini välja, kuid WMS-süsteemi taustaprogramm käivitub 1C-s kiiremini.
1C tööriistana
Igal tehnoloogilisel lahendusel on rakendatavuse piirid. 1C ei ole üldotstarbeline keel, see ei ela oma raamistikust eraldi. Soovitatav on kasutada 1C, kui vajate:
- serverirakendus
- rakendus, kus raha ilmub
- valmis kasutajaliidese, ORM-i, aruandluse, XML/JSON/COM/PDF/YourDataTransferingFormatiga
- taustaprotsesside ja tööde toega
- rollipõhise turvalisusega
- skriptitava äriloogikaga
- võimalusega kiiresti luua prototüüp ja lühikese turustamisajaga
Te ei vaja 1C, kui soovite:
- masinõpe
- GPU arvutused
- arvutigraafika
- matemaatilised arvutused
- CAD süsteem
- signaalitöötlus (heli, video)
- highload http-kõned sadade tuhandete pööretega
1C tootmisettevõttena
Tasub mõista, mis on 1C kui tarkvaratootja äri. 1C ettevõte müüb automatiseerimise kaudu lahendusi äriprobleemidele. Erinevad ettevõtted, nii suured kui väikesed, aga just seda ta müüb. Vahendid selle eesmärgi saavutamiseks on ärirakendused. Raamatupidamiseks, palgaarvestuseks jne. Nende rakenduste kirjutamiseks kasutab ettevõte oma ärirakenduste arendusplatvormi. Spetsiaalselt kohandatud nende samade ärirakenduste tavapäraste ülesannete jaoks:
- finantsarvestus
- äriloogika lihtne kohandamine
- laialdased integreerimisvõimalused heterogeensetel IT-maastikel
Tootjana usub 1C, et see on strateegia, mis võimaldab teil teha koostööd partnerite ja klientidega režiimis, millest võidavad kõik. Sellele võib vaielda, aga umbkaudu reklaamib ettevõte end nii: äriprobleemidele valmislahendused, mida partnerid saavad kiiresti kohandada ja mis tahes IT-maastikule integreerida.
Kõiki väiteid või soove 1C kui raamistiku kohta tuleks vaadelda ainult läbi selle prisma. "Me tahame OOP-i 1C-s," ütlevad arendajad. "Kui palju maksab meile OOP-i toetamine platvormis, kas see aitab meil kastide müüki suurendada?" ütleb 1C. Avab oma "prisma" äriprobleemidele lahenduste müümisel:
- Hei, äri, kas sa tahad OOP-i oma 1C-sse?
- Kas see aitab mul probleeme lahendada?
- Kes teab...
- Siis pole vaja
See lähenemine võib olla hea või halb olenevalt sellest, kes seda vaatab, kuid nii see lihtsalt on. Rääkides sellest, et 1C-s pole funktsiooni X, peate mõistma, et see pole seal põhjusega, vaid valiku "rakenduskulu vs kasumisumma" kontekstis.
Tehnoloogiline klassifikatsioon
„Tegelikult annavad Odinesniks endast parima, et kasutada parimaid mustreid, mille on hoolikalt valinud hoolivad metoodikud ja platvormi 1C arendajad.
Kui kirjutate oma lolli koodi lihtsa hallatava vormi jaoks, siis tegelikult kasutate seda mudel-vaate-kontroller с kahesuunaline andmete sidumine в kolmekihiline andmerakenduse mootor, maitsestatud kõrgetasemeline objektide seoste kaardistamine alusel deklaratiivne metaandmete kirjeldusmillel on oma platvormist sõltumatu päringukeel, C deklaratiivne andmepõhine kasutajaliides, täielik läbipaistev serialiseerimine ja domeenile orienteeritud programmikeel.1C arendajad oma lääne kolleegidest erinevad on PR. Nad armastavad igale jamale suurt nime anda ja sellega nagu räpase kotiga ringi joosta.
A. Orefkov
1C platvormil on klassikaline 3-tasandiline arhitektuur, mille keskmes on rakendusserver (või selle emuleerimine väikese raha eest väikestele poepidajatele). DBMS-ina kasutatakse MS SQL-i või Postgresi. Toetatakse ka Oracle'i ja IBM DB2, kuid see on üsna esoteeriline, keegi ei tea, mis juhtub, kui rakendate 1C nendes andmebaasides keskmise ja suure koormuse korral. Usun, et 1C ise seda ei tea.
Kliendiosa on kas kasutaja masinasse installitud õhuke klient või veebiklient. Peamine omadus on see, et programmeerijad ei kirjuta 2 erinevat koodi, nad kirjutavad ühe rakenduse, ühes keeles ja soovi või vajaduse korral saate seda brauseris kuvada. Kes tahtis tõelist täielikku pinu ja ühtset keelt esi- ja taustaprogrammi jaoks, node.js? Täpselt sama asja ei õnnestunud neil kunagi lõpuni teha. Tõeline täispakk on olemas, kuid peate selle 1C-s kirjutama. Saatuse iroonia, sellised asjad :)
Pilve SaaS-lahendus 1C:Fresh töötab ka brauserirežiimis, milles ei saa osta 1C, vaid rentida väike andmebaas ja jälgida seal toimuvat shawarma müüki. Lihtsalt brauseris, midagi installimata või konfigureerimata.
Lisaks on olemas pärandklient, mida 1C-s nimetatakse "tavarakenduseks". Pärand on pärand, tere tulemast rakenduste maailma aastal 2002, kuid me räägime siiski ökosüsteemi hetkeseisust.
1C serveriosa toetab klastrite loomist ja skaleerimist, lisades klastrisse uusi masinaid. Siin on päris palju koopiaid purustatud ja selle kohta tuleb artiklis eraldi jaotis. Lühidalt öeldes pole see päris sama, mis paari täpselt sama eksemplari lisamine HAProxy taha.
Rakenduste arendusraamistik kasutab oma programmeerimiskeelt, mis sarnaneb umbkaudu veidi täiustatud vene keelde tõlgitud VB6-ga. Inimestele, kes vihkavad kõike venekeelset ja kes ei usu, et "kui" tõlgitakse kui "kui", pakutakse teist süntaksivalikut. Need. Soovi korral võid selle 1C-sse kirjutada nii, et see VB-st ei eristu.
Just see programmeerimiskeel on 1C hüüdnimede vihkamise peamine põhjus nende platvormi vastu. Olgem ausad, mitte ilma põhjuseta. Keel oli mõeldud võimalikult lihtsaks, et täita mantrat "ARENDAJAD, ARENJAD" vähemalt SRÜ mastaabis. Sellise lahenduse äriline olemus on minu arvates selgelt nähtav: rohkem arendajaid, suurem turu katvus. See sai teoks, erinevatel hinnangutel 45% kuni 95%. Ütlen kohe, et teie arvates on tõesti lihtsam kirjutada keeles. Ja ma oskan päris paljusid programmeerimiskeeli.
Alustame keelest.
1C programmeerimiskeel
Samal ajal süsteemi tugev ja nõrk koht. Pakub hõlpsat sisestamist ja loetavust. Teisest küljest pole seda värskendatud alates 8. versiooni väljaandmisest 2002. aastal ja see on moraalselt vananenud. Keegi ütleb "peamine puudus on see, et OOP-i pole" ja nad eksivad. Esiteks ei meeldi PLO-le mitte ainult Nuraliev, vaid ka Torvalds. Ja teiseks, OOP on endiselt olemas.
Arendaja seisukohast on tema käsutuses DBMS-is kuvatavate baasklassidega raamistik. Arendaja võib võtta baasklassi “Kataloog” ja pärida sealt kataloogi “Kliendid”. Sellele saab lisada uusi klassivälju, näiteks Maksumaksja Identifitseerimisnumber ja Aadress, samuti saab vajadusel alistada baasklassi meetodeid, näiteks OnWrite/AtRecord meetodit.
Raamistik on loodud nii, et sügavamat pärimist on harva vaja ja OOP-i piirang on minu arvates mõistlik. 1C keskendub domeenipõhisele arendusele ja paneb mõtlema ennekõike arendatava lahenduse teemavaldkonnale ja see on hea. Pole mitte ainult kiusatust, vaid ka vajadust kirjutada 10 erinevat DTO-d ja ViewModelsi, et näidata kuskil mingeid andmeid domeenist. 1C arendaja töötab alati ühe olemiga, risustamata taju konteksti kümnete sarnaste nimedega klassidega, mis esindavad sama olemit, kuid erinevast küljest. Näiteks mis tahes .NET-rakendus peab tingimata sisaldama viit või kahte ViewModelsi ja DTO-d JSON-i serialiseerimiseks ja andmete edastamiseks kliendilt serverisse. Ja ligikaudu 10–15% teie rakenduse koodist kulub andmete edastamiseks ühest klassist teise, kasutades pliiatseid või karkusid, nagu AutoMapper. See kood tuleb kirjutada ja programmeerijatele selle loomise ja hooldamise eest maksta.
Selgub, et 1C keelt on keeruline arendada ilma seda tavakeelte tasemele komplitseerimata, kaotades sellega lihtsuse eelise. Mida müüja ülesanne sisuliselt lahendatakse: väljastada tüüplahendus, mida iga tänavalt tabatud õpilane saaks vajaliku kvaliteeditasemega kohandada (st valmib ümbris, mis hõlmab boksist suure tehaseni). Kui olete kiosk, võtke tudeng, kui olete tehas, võtke guru oma rakenduspartnerilt. See, et rakenduspartnerid müüvad õpilasi guru hinnaga, pole raamistiku probleem. Arhitektuuriliselt peab raamistik lahendama mõlema probleemid, standardkonfiguratsioonide kood (mille me müüsime ettevõtetele koos kohandamise lubadusega) peaks olema õpilasele arusaadav ja guru peaks saama aru, mida iganes soovite.
Mis minu meelest keelest väga puudu jääb, mis sunnib kirjutama rohkem, kui jõuaks, on see, mis raiskab kliendi tasutud aega.
- Võimalus tippida tasemel, näiteks TypeScript (selle tulemuseks on rohkem arenenud koodianalüüsi tööriistad IDE-s, refaktoreerimine, vähem solvavaid jambeid)
Funktsioonide saadavus esimese klassi objektidena. Veidi keerulisem kontseptsioon, kuid tüüpilise katlakoodi kogust saaks oluliselt vähendada. Õpilase arusaam koodist IMHO isegi suureneks tänu mahu vähenemisele - Universaalkogu literaalid, initsialiseerijad. Sama asi - koodide arvu vähendamine, mida tuleb kirjutada ja/või silmaga vaadata. Kogude täitmine võtab üle 9000% 1C programmeerimisajast. Selle kirjutamine ilma süntaktilise suhkruta on pikk, kulukas ja vigadetundlik. Üldiselt ületab LOC-i hulk 1C-lahendustes kõik mõeldavad piirid võrreldes saadaolevate avatud raamistike ja üldiselt kõigi teie ettevõtte Javadega kokku. Keel on paljusõnaline ja see taandub andmemahuks, mäluks, IDE-piduriteks, ajaks, rahaks...
- lõpuks konstruktsioonid Mul on hüpotees, et see konstruktsioon on puudu seetõttu, et nad ei leidnud selle edukat tõlget vene keelde :)
- Oma andmetüübid (ilma OOP-ita), tüübi analoogid VB6-st. See võimaldab teil mitte kirjutada struktuure, kasutades BSP-s kommentaare ja maagilisi meetodeid, mis neid struktuure loovad. Saame: vähem koodi, vihje läbi punkti, kiirem probleemi lahendamine, vähem kirjavigadest ja struktuuride puuduvatest omadustest tulenevaid vigu. Nüüd lasub kasutajastruktuuride tippimine täielikult Standard Subsystem Library arendusmeeskonnal, kes oma kiituseks kirjutab hoolikalt kommentaare läbitud parameetristruktuuride eeldatavate omaduste kohta.
- Veebikliendis asünkroonsete kõnedega töötamisel pole suhkrut. Callback-hell vormis ProcessingNotifications on ajutine kark, mis on põhjustatud peamiste brauserite API äkilisest muutumisest, kuid niimoodi ei saa elada kogu aeg rohkem ja rohkem. Kui lisage sellele paradigmale peamises IDE-s tugi ja asjad lähevad veelgi hullemaks.
See on üks pakilisemaid probleeme, on selge, et nimekiri võiks olla palju suurem, kuid me ei tohi unustada, et see pole ikkagi üldotstarbeline keel, see ei nõua mitmelõimelisust, lambda funktsioone, juurdepääsu GPU-le ja kiiret ujukomaarvutused. See on äriloogika skriptikeel.
Programmeerijal, kes on selle keelega juba palju töötanud, uurib js või c#, hakkab selle keele raames igav. See on fakt. Ta vajab arengut. Teisel pool müüja jaoks on määratud funktsioonide rakendamise kulud võrreldes tulude suurenemisega pärast nende rakendamist. Siin ei ole mul mingit infot selle kohta, mis hetkel ettevõtte silmis üles kaalub.
Arenduskeskkond
Ka siin ei lähe asjad libedalt. Arenduskeskkondi on kaks. Esimene on tarnekomplektis sisalduv konfiguraator. Teine on Eclipse’i baasil välja töötatud Enterprise Development Toolsi keskkond ehk lühidalt EDT.
Konfiguraator pakub täielikku valikut arendusülesandeid, toetab kõiki funktsioone ja on peamine keskkond turul. See on ka moraalselt vananenud, kuulujuttude järgi ei arene – enda sees oleva tehnilise võla suuruse tõttu. Olukorda saaks parandada sisemise API avamisega (sõpruse vormis A. Orefkova või iseseisvalt), kuid see pole nii. Praktika on näidanud, et kogukond kirjutab IDE-sse oma funktsioonid seni, kuni müüja ei sekku. Aga meil on see, mis meil on. Konfiguraator oli aastatel 2004-2005 suurepärane, meenutas väga tolleaegset Visual Studiot, kohati oli isegi lahedam, aga jäi nendesse aegadesse kinni.
Lisaks on keskmise standardlahenduse maht sellest ajast kordades kasvanud ja täna ei tule IDE lihtsalt toime selle koodihulgaga, millega seda ette söödetakse. Kasutatavus ja ümbertöötlemisvõimalused pole isegi nullis, need on miinuses. See kõik ei lisa arendajatele entusiasmi ja nad unistavad kolida teistesse ökosüsteemidesse ja jätkata seal paska kodeerimist, kuid mõnusas keskkonnas, mis oma käitumisega näkku ei sülita.
Alternatiivina pakutakse nullist kirjutatud IDE-d, mis on ehitatud Eclipse'ile. Seal elavad allikad, nagu igas muus tarkvaras, tekstifailide kujul, salvestatakse GIT-i, tõmba päringu harud, kõik see. Negatiivne külg on see, et see pole juba mitu aastat beetastaatust lahkunud, kuigi see muutub iga väljalaskega paremaks. Ma ei kirjuta EDT puudustest, täna on see miinus, homme on see fikseeritud funktsioon. Sellise kirjelduse asjakohasus kaob kiiresti. Tänapäeval on EDT-s võimalik areneda, kuid see on ebatavaline, et peate olema valmis teatud arvu IDE-vigadeks.
Kui vaadata olukorda läbi eelmainitud “1C prisma”, siis saad umbes sellise: uue IDE väljalaskmine ei suurenda kastide müüki, küll aga võib väheneda ARENDAJATE väljavool. Raske on öelda, mis ootab ökosüsteemi arendajate mugavuse osas, kuid Microsoft on mobiiliarendajad juba rikkunud, pakkudes neile oma teenuseid liiga hilja.
Arendusjuhtimine
Siin on kõik oluliselt parem kui koodi kirjutamisel, eriti viimasel ajal, kui kogukonna jõupingutused tõid päevavalgele halduse automatiseerimise probleemid, käivitati prototüübid, mis kutsusid üles viskama 1C hoidla prügihunnikusse ja kasutama giti, kiiret süüdistamist, koodi ülevaatamist. , staatiline analüüs, automaatne juurutamine jne. Platvormile on lisatud palju funktsioone, mis tõstavad arendusülesannete automatiseerituse taset. Kuid kõik need funktsioonid lisati ainult ja ainult meie enda suurte toodete arendamiseks, kui sai selgeks, et me ei saa ilma automatiseerimiseta hakkama. Toimusid automaatsed liitmised, kolmesuunaline võrdlus KDiffiga ja kõik muu. Käivitatud Githubis , kes ausalt öeldes ideoloogiliselt projektist eemale tiriti , kuid muudetud nii, et see sobiks müüja ettevõtte protsessidega. Tänu kangekaelsetele avatud lähtekoodiga kuttidele sai 1C arendusautomaatika käiku. Konfiguraatori IMHO avatud API nihutaks ka peamise IDE moraalset mahajäämust.
Tänapäeval salvestatakse 1C allikad gitis koos Jira probleemidega seotud kohustustega, Crucible'i ülevaated, Jenkinsi nupud ja Allure raportid kooditestimise kohta 1C-s ja isegi - see pole kaugeltki uudis, vaid pigem peavool ettevõtetes, kus on palju 1C arendust.
Haldamine
Siin on palju öelda. Esiteks on see loomulikult server (1C serveriklaster). Imeline asi, kuid tänu sellele, et tegemist on täiesti musta kastiga, mis on dokumenteeritud piisavalt detailselt, kuid spetsiifilisel viisil – mitme serveri kõrgkoormuse režiimis katkematu töö käivitamise valdamine on väheste väljavalitute asi, kes kannavad medal kirjaga “Tehnoloogiliste küsimuste ekspert”. Väärib märkimist, et põhimõtteliselt ei erine 1C-serveri haldamine mis tahes muu serveri haldamisest. See on võrgupõhine mitme lõimega rakendus, mis tarbib mälu, protsessori ja ketta ressursse. Pakub rohkelt võimalusi telemeetria kogumiseks ja diagnostikaks.
Siin on probleem selles, et müüja ei paku just selle diagnostika jaoks valmislahenduste osas midagi erilist. Jah, on olemas 1C: Instrumentation and Control Center, need on isegi päris head, aga väga kallid ja kõigil neid pole. Kogukonnas on mitmeid arendusi Grafana, Zabbixi, ELK ja muude asjade ühendamiseks standardsest administraatorikomplektist, kuid pole ühtegi lahendust, mis sobiks enamusele. Ülesanne ootab oma kangelast. Ja kui olete ettevõte, mis plaanib käivitada 1C klastris, vajate eksperti. Oma seest või väljast, aga sul on seda vaja. On normaalne, et serveri tööks on pädevustega eraldi roll, mitte iga 1C kasutaja ei peaks seda teadma, peate lihtsalt aru saama, et sellist rolli on vaja. Võtame näiteks SAP-i. Seal ei tõuse programmeerija tõenäoliselt isegi toolilt, kui tal palutakse rakendusserveris midagi konfigureerida. Ta võib olla lihtsalt rumal ja tal pole häbi. SAP metoodikas on selleks eraldi töötaja roll. Millegipärast arvatakse 1C tööstuses, et see tuleks ühendada ühe töötajaga sama palga eest. See on pettekujutelm.
1C serveri puudused
Seal on täpselt üks miinus - töökindlus. Või kui soovite, siis ettearvamatust. Serveri äkiline kummaline käitumine on juba kõneaineks saanud. Universaalset abinõu - serveri seiskamist ja vahemälu tühjendamist - kirjeldatakse isegi eksperdi käsiraamatus ja soovitatakse isegi partiiraamatut, mis seda teeb. Kui teie 1C-süsteem hakkab tegema midagi, mida ta isegi teoreetiliselt tegema ei peaks, on aeg tühjendada seansiandmete vahemälu. Minu hinnangul on terves riigis vaid kolm inimest, kes oskavad ilma selle protseduurita 1C serverit juhtida ja nad ei jaga saladusi, sest... nad elavad sellest. Võib-olla on nende saladus selles, et nad puhastavad seansiandmeid, kuid nad ei räägi sellest kellelegi, kutt.
Vastasel juhul on 1C-server sama rakendus, mis iga teine ja seda hallatakse peaaegu samamoodi, lugedes dokumentatsiooni ja koputades tamburiinile.
laevalaadija
Konteinerite 1C serveri kasutamise kasulikkus tootmises pole veel tõestatud. Serverit ei rühmitata lihtsalt tasakaalustaja taha sõlmede lisamisega, mis vähendab tootmise konteineriseerimise eeliseid miinimumini, ja konteinerites suure koormusega režiimis eduka töötamise praktikat pole loodud. Seetõttu kasutavad testkeskkondade seadistamiseks Docker+1C-d ainult arendajad. Seal on see väga kasulik, rakendatud, võimaldab teil mängida kaasaegsete tehnoloogiatega ja puhata konfiguraatori meeleheitest.
Kaubanduslik komponent
Investeerimise seisukohast võimaldab 1C teil rakendusklasside laiade võimaluste tõttu lahendada äriideede kiire käivitamise probleemi. 1C out of the box annab väga korraliku Aruandluse, integratsiooni kõigega, veebikliendi, mobiilikliendi, mobiilirakenduse, erinevate DBMS-ide toe, sh. tasuta, platvormiülene nii serveri kui ka installitud kliendi osad. Jah, rakenduste kasutajaliides on kollane, mõnikord on see miinus, kuid mitte alati.
Valides 1C, saab ettevõte komplekti tarkvaralahendusi, mis võimaldavad luua väga laia valikut rakendusi, aga ka palju arendajaid turul, kes tahavad vähem raha kui javaistid ja toovad samal ajal tulemusi kiiremini.
Näiteks saab õpilase töötunniga lahendada PDF-arve kliendile saatmise ülesande. Sama probleemi .NET-is saab lahendada varalise raamatukogu ostmisega või paaripäevase või -nädalase kodeerimisega karmi habemega arendaja poolt. Mõnikord mõlemat korraga. Ja jah, ma rääkisin ainult PDF-i genereerimisest. Me pole öelnud, kust see arve üldse tuleb. Veebi frontender peab looma vormi, kuhu operaator sisestab andmed, backender peab looma dto mudelid JSON-i ülekandmiseks, mudelid andmebaasi salvestamiseks, andmebaasi enda struktuuri, sinna migreerumise, graafilise vormingu moodustamise. selle konto kuvamine ja alles siis - PDF. 1C-l on kogu ülesanne nullist tehtud täpselt ühe tunniga.
Täisväärtuslik raamatupidamissüsteem väikesele boksile ühe ostetud/müüdud äriprotsessiga tehakse 3 tunniga koos müügiaruandluse, kaupade arvestuse ostu-müügihindadega, laokaupa, juurdepääsuõiguste kontrolli, veebikliendi ja mobiilirakendusega. . Olgu, ma unustasin rakenduse, mitte 3 tunni pärast, vaid kuue pärast.
Kui kaua võtab .NET-i arendajal aega selle ülesande täitmiseks visuaalstuudio puhtasse arvutisse installimisest kuni kliendile demonstreerimiseni? Kuidas on lood arenduskuludega? Sama asi.
1C kui platvormi tugevused
1C pole tugev mitte sellepärast, et selles on midagi spetsiifilist, mis on maailma parim. Vastupidi, igast üksikust alamsüsteemist võib leida maailma tarkvarast huvitavama analoogi. Kuid tegurite kombinatsiooni põhjal ei näe ma 1C-ga sarnast platvormi. Siin peitub äriline edu. Platvormi eelised on sellel hajutatud ja on kõige selgemini nähtavad, kui näete, kuidas seda muudel platvormidel tehakse. Põhimõtteliselt EI OLE need isegi tunnused, vaid vastupidi – tunnuste tagasilükkamine ühe konkreetse paradigma kasuks. Mõned näited:
- Unicode. Mis pagan võiks olla lihtsam? 2019. aastal pole vaja kasutada ühebaidiseid ASCII-kodeeringuid (v.a integreerimine iidsete pärandkoodidega). Mitte kunagi. Kuid mitte. Igatahes kasutab keegi mõnes tabelis ühebaidist varcharit ja rakendusel on probleeme kodeeringutega. 2015. aastal ebaõnnestus gitlabi LDAP-i autoriseerimine, kuna JetBrains IDE ei tööta endiselt kõikjal failinimedes kirillitsaga. 1C pakub rakenduskoodi kvaliteetset isoleerimist andmebaasikihist. Seal ei saa madalal tasemel tabeleid tippida ja ebakompetentsete juunioride jambid andmebaasi tasemel on seal võimatud. Jah, ebakompetentsete juunioridega võib olla ka muid probleeme, kuid probleemide mitmekesisus on palju väiksem. Nüüd ütlete mulle, et teie rakendus on õigesti kujundatud ja andmebaasi juurdepääsukiht on isoleeritud nii, nagu see peaks olema. Vaadake veel kord oma ettevõtte kohandatud Java-rakendust. Tihedalt ja ausalt. Kas teie südametunnistus häirib teid? Siis on mul sinu üle hea meel.
- Teavikute/teatmete nummerdamine. 1C puhul pole see kindlasti kõige paindlikum ega ka parim. Aga mida nad pangatarkvaras ja ise kirjutatud raamatupidamissüsteemides teevad – see on lihtsalt pimedus. Kas jääb identiteet kinni (ja siis “ah, miks meil on augud”) või vastupidi, tehakse generaator, mis töötab DBMS-i tasemel lukustamisega (ja muutub kitsaskohaks). Tegelikult on seda pealtnäha lihtsat ülesannet üsna keeruline teha - olemite otsast lõpuni loendur, mille unikaalsuse sektsioon põhineb teatud võtmekomplektil, eesliited, et see paralleelse andmesisestuse ajal andmebaasi ei blokeeriks. .
- Andmebaasis olevate kirjete identifikaatorid. 1C tegi tugeva otsuse – kõik lingiidentifikaatorid on täiesti sünteetilised ja kõik. Ja hajutatud andmebaaside ja vahetustega pole probleeme. Teiste süsteemide arendajad loovad kangekaelselt midagi identiteedi sarnast (see on lühem!), lohistavad need GUI-sse, kuni on aeg luua mitu seotud eksemplari (ja siis need avastatakse). Kas teil seda pole? Ausalt?
- Loendid. 1C-l on üsna edukad mehhanismid (suurte) loendite lehitsemiseks ja nendes navigeerimiseks. Lubage mul teha broneering kohe – mehhanismi õige kasutamisega! Üldiselt on teema üsna ebameeldiv, seda ei saa ideaalselt lahendada: see on kas intuitiivne ja lihtne (aga kliendil on tohutute rekordikomplektide oht) või on lehitsemine ühe või teise kõverusega. Need, kes otsivad, teevad seda sageli viltu. Need, kes teevad ausa kerimisriba, lisavad andmebaasi, kanali ja kliendi.
- Hallatavad vormid. Kahtlemata ei tööta veebikliendi liides ideaalselt. Aga see toimib. Kuid paljude teiste raamatupidamis- ja pangasüsteemide jaoks on kaugtöökoha loomine ettevõtte tasemel projekt. Kohustustest loobumine: õnneks ei mõjuta see neid, kes selle algselt veebis tegid.
- Mobiilirakendus. Viimasel ajal on võimalik mobiilirakendusi kirjutada ka samas ökosüsteemis viibides. Siin on see pisut keerulisem kui veebikliendi puhul; seadmete eripära sunnib kirjutama spetsiaalselt nende jaoks, kuid sellest hoolimata ei palka te eraldi mobiiliarendajate meeskonda. Kui vajate rakendust ettevõtte sisemisteks vajadusteks (kui ettevõtte probleemi mobiilne lahendus on olulisem kui kollane kasutajaliidese kujundus), kasutate lihtsalt karbist välja võttes sama platvormi.
- Aruandlus. Selle sõna all ei pea ma silmas BI-süsteemi, millel on suurandmed ja ETL-i protsessi mahajäämus. See viitab operatiivpersonali aruannetele, mis võimaldavad hinnata raamatupidamise seisu siin ja praegu. Saldod, omavahelised arveldused, ümberpaigutamine jne. 1C tuleb karbist välja aruandlussüsteemiga, millel on paindlikud sätted rühmitamiseks, filtriteks ja kasutajapoolseks visualiseerimiseks. Jah, turul on lahedamaid analooge. Kuid mitte kõik-ühes lahenduse raames ja hinnaga, mis on mõnikord kõrgem kui kõik-ühes lahendus. Ja sagedamini on see isegi vastupidi: ainult aruandlus, kuid kallim kui kogu platvorm ja halvem kvaliteet.
- Prinditavad vormid. Noh, kasutage .NET-i, et lahendada töötajatele e-posti teel PDF-vormingus palgalehtede saatmine. Ja nüüd arvete printimise ülesanne. Aga nende koopiate salvestamine samasse PDF-i? 1C hüüdnime puhul on mis tahes paigutuse väljastamine PDF-i +1 koodirida. See tähendab + 40 sekundit tööaega, mitte päevade või nädalate teises keeles. Trükitud vormipaigutusi 1C-s on uskumatult lihtne välja töötada ja need on piisavalt võimsad, et konkureerida tasuliste kolleegidega. Jah, arvatavasti pole 1C tabelidokumentides palju interaktiivseid võimalusi, OpenGL-i abil ei saa kiiresti skaleerimisega 3D-skeemi. Aga kas see on tõesti vajalik?
Need on vaid mõned näited, kus funktsionaalsuse piiramine või kompromisside rakendamine osutub tulevikus oluliseks arhitektuuriliseks kasuks. Isegi kompromiss või mitte kõige tõhusam variant - see on juba karbis ja seda peetakse iseenesestmõistetavaks. Selle iseseisev teostus on kas võimatu (sest sellised otsused tuleb teha projekti alguses ja selleks pole aega ja arhitekti pole üldse) või mitu kulukat iteratsiooni. Igas loetletud punktis (ja see pole arhitektuursete lahenduste täielik loetelu) saate rikkuda ja kehtestada piiranguid, mis blokeerivad skaleerimist. Igal juhul peate ärimehena veenduma, et teie programmeerijatel oleks "süsteemi nullist" loomisel sirged käed ja nad saaksid peened süsteemiprobleemid kohe hästi hakkama.
Jah, nagu igas teises keerulises süsteemis, on ka 1C-l endal lahendusi, mis teatud aspektides skaleerimist blokeerivad. Siiski kordan, et tegurite kombinatsiooni, omamiskulude ja juba eelnevalt lahendatud probleemide arvu põhjal ei näe ma turul väärilist konkurenti. Sama hinna eest saate finantsrakenduste raamistiku, klasterdatud tasakaalustatud serveri, kasutajaliidese ja veebiliidese, mobiilirakenduse, aruandluse, integratsiooni ja hunniku muud. Java maailmas palkate esi- ja tagaotsa meeskonna, silute kodus kirjutatud serverikoodi madala taseme hunnikuid ja maksate 2 mobiilirakenduse eest eraldi 2 mobiilse OS-i eest.
Ma ei ütle, et 1C lahendab kõik juhtumid, kuid mida veel on vaja ettevõttesisese rakenduse jaoks, kui kasutajaliidest pole vaja brändida?
Fly salvaga
Tõenäoliselt jäi teile mulje, et 1C päästab maailma ja kõik muud ettevõttesüsteemide kirjutamise viisid on valed. See pole üldse nii. Ärimehe seisukohast, kui valite 1C, peate lisaks kiirele turule jõudmisele arvestama järgmiste puudustega:
- Serveri töökindlus. Vaja on tõeliselt kvaliteetseid spetsialiste, kes suudavad tagada selle katkematu töö. Ma ei ole teadlik sellistele spetsialistidele müüjalt valmis koolitusprogrammist. Eksperdi eksamiks valmistumiseks on kursusi, kuid minu arvates sellest ei piisa.
- Toetus. Vaata eelmist punkti. Müüja toe saamiseks peate selle ostma. Millegipärast ei aktsepteerita seda 1C tööstuses. Ja SAP-iga on see peaaegu kohustuslik ost ja see ei häiri kedagi. Ilma ettevõtte toetuseta ja ilma spetsialistideta võite jääda 1C tõrgetega üksi.
- Siiski ei saa 1C-ga absoluutselt kõike teha. See on tööriist ja nagu igal tööriistal, on ka selle rakenduspiirangud. 1C maastikul on väga soovitav omada “mitte-1C” süsteemiarhitekti.
- Head 1C hüüdnimed ei ole odavamad kui head programmeerijad teistes keeltes. Kuigi halbade programmeerijate palkamine on kallis, olenemata sellest, millises keeles nad kirjutavad.
Teeme täpid
- 1C on kiire rakenduste arendamise (RAD) raamistik äri jaoks ja on selle jaoks kohandatud.
- Kolmetasandiline link suuremate DBMS-ide toega, kliendi kasutajaliides, väga hea ORM-i ja aruandlus
- Laiad võimalused integreerimiseks süsteemidega, mis suudavad teha seda, mida 1C ei suuda. Kui soovite masinõpet, võtke Python ja saatke tulemus 1C-le läbi http või RabbitMQ
- Pole vaja püüda teha kõike 1C abil, peate mõistma selle tugevaid külgi ja kasutama neid oma eesmärkidel
- Arendajad, kes soovivad süveneda tehnoloogilise raamistiku vidinatesse ja iga N aasta järel uue mootori jaoks ümber kujundada, on 1C-st tüdinud. Seal on kõik väga konservatiivne.
- Samuti on arendajatel igav, sest nende pärast on tootja väga vähe muret. Igav keel, nõrk IDE. Need nõuavad moderniseerimist.
- Teisest küljest on arendajad, kes ei leia nalja mõne muu neile meeldiva tehnoloogia kasutamise ja õppimise kaudu, halvad arendajad. Nad virisevad ja kolivad teise ökosüsteemi.
- Tööandjad, kes ei luba oma 1C hüüdnimedel Pythonis midagi kirjutada, on halvad tööandjad. Nad kaotavad uudishimuliku meelega töötajad ja nende asemele tulevad ahvikodeerijad, kes kõigega nõustudes firmatarkvara sohu tirivad. See tuleb ikkagi ümber kirjutada, nii et võib-olla oleks õigem veidi varem Pythonisse investeerida?
- 1C on äriettevõte ja rakendab funktsioone ainult oma huvidest ja otstarbekusest lähtuvalt. Te ei saa teda selles süüdistada, äri peab mõtlema kasumile, see on elu
- 1C teenib raha, müües lahendusi äriprobleemidele, mitte Vasya arendajaprobleemidele. Need kaks mõistet on korrelatsioonis, kuid prioriteet on täpselt see, mida ma ütlesin. Kui arendaja Vasya on valmis 1C: Resharperi isikliku litsentsi eest maksma, ilmub see üsna kiiresti, on selle tõestuseks A. Orefkova “Resharper”. Kui müüja seda toetaks ja selle vastu ei võitleks, tekiks arendajatele mõeldud tarkvara turg. Nüüd on sellel turul poolteist küsitavate tulemustega mängijat ja kõik sellepärast, et integratsioon IDE-ga on negatiivne ja kõik käib karkudel.
- Mitme masina operaatori praktika kaob unustuse hõlma. Kaasaegsed rakendused on liiga suured, et neid nii koodi poolelt kui ka ärikasutuse poolelt meeles pidada. 1C-server muutub ka keerukamaks, ühes töötajas on võimatu hoida kõiki eriteadmisi. See peaks kaasa tooma nõudluse spetsialistide järele, mis tähendab 1C elukutse atraktiivsust ja palkade tõusu. Kui varem töötas Vasya kolm-ühes ühe palga eest, siis nüüd tuleb palgata kaks Vasjat ja konkurents Vasjade vahel võib tõuke anda nende taseme üldisele kasvule.
Järeldus
1C on väga väärt toode. Minu hinnaklassis ei tea ma üldse ühtegi analoogi, kirjutage kommentaaridesse, kui neid on. Arendajate väljavool ökosüsteemist on aga üha märgatavam ja see on “ajude äravool”, vaatamata sellele, kuidas seda vaadata. Tööstus näljas moderniseerimise järele.
Kui olete arendaja, ärge jääge 1C-le ja ärge arvake, et teistes keeltes on kõik maagiline. Ehk siis, kui oled noorem. Niipea, kui on vaja midagi suuremat lahendada, tuleb valmislahendusi kauem otsida ja intensiivsemalt lõpule viia. Nende “plokkide” kvaliteedi poolest, millest saab lahenduse ehitada, on 1C väga-väga hea.
Ja veel üks asi - kui teile tuleb tööle 1C hüüdnimi, võib 1C hüüdnime julgelt juhtivate analüütikute ametikohale määrata. Nende arusaam ülesandest, ainevaldkonnast ja jaotusoskustest on suurepärane. Olen kindel, et selle põhjuseks on just DDD sunnitud kasutamine 1C arenduses. Inimene on koolitatud mõtlema eelkõige ülesande tähendusele, ainevaldkonna objektide vahelistele seostele ning samas omab tehnilist tausta integratsioonitehnoloogiate ja andmevahetusformaatide vallas.
Olge teadlik, et ideaalset raamistikku pole olemas ja hoolitsege enda eest.
Hea kõigile!
PS: tänan teid väga abi eest artikli koostamisel.
Küsitluses saavad osaleda ainult registreerunud kasutajad. palun.
Kas teie ettevõttes on 1C?
-
13,3%Üldse mitte.71
-
30,3%On küll, aga ainult raamatupidamisosakonnas kuskil. Põhisüsteemid teistel platvormidel162
-
41,4%Jah, peamised äriprotsessid töötavad selle peal221
-
15,0%1C peab surema, tulevik kuulub %technology_name%80-le
534 kasutajat hääletas. 99 kasutajat jäi erapooletuks.
Allikas: www.habr.com