1C - Godt og ondt. Arrangement av punkter i holivar rundt 1C

Venner og kolleger, nylig har det vært hyppigere artikler om Habré med hat mot 1C som utviklingsplattform, og taler fra forsvarerne. Disse artiklene identifiserte ett alvorlig problem: oftest kritiserer kritikere av 1C det fra posisjonen til å "ikke mestre det", skjeller ut problemer som de facto lett kan løses, og tvert imot, ikke berører problemer som er virkelig viktige, verdt diskuterer og løses ikke av leverandøren. Jeg mener det er fornuftig å gjennomføre en nøktern og balansert gjennomgang av 1C-plattformen. Hva den kan gjøre, hva den ikke kan, hva den bør gjøre, men ikke gjør, og, til dessert, hva den gjør med et smell, og utviklerne dine hos %technology_name% vil gjøre i hundre år, og kaste det bort mer enn ett årlig budsjett.

Som et resultat vil du som leder eller arkitekt kunne få en klar forståelse av hvilken oppgave det vil være gunstig for deg å bruke 1C, og hvor det må brennes ut med et varmt strykejern. Som utvikler i "ikke-1C"-verdenen vil du kunne se hva som er der i 1C som skaper oppstyr. Og som 1C-utvikler vil du kunne sammenligne systemet ditt med økosystemene til andre språk og forstå plasseringen din i koordinatsystemet for programvareutvikling.

Under kuttet er det mange tykke angrep på 1C, på kritikere av 1C, på Java, .NET og generelt... Viften er full, velkommen!

Om meg

Jeg har vært kjent med samtaleemnet siden ca. 2004. Jeg har programmert sannsynligvis siden jeg var 6 år gammel, helt fra jeg fikk en bok om professor Fortran med tegneserier om en katt, en spurv og en larve. Jeg analyserte programmene som katten skrev ut fra bildene i boken og fant ut hva de gjorde. Og ja, jeg hadde ikke en ekte datamaskin på den tiden, men det var en tegning på spredningen av boken, og jeg trykket ærlig på papirknappene og skrev inn kommandoene jeg hadde spionert på katten X.

Så var det BK0011 og BASIC på skolen, C++ og montører på universitetet, så 1C, og så mange andre ting som jeg er for lat til å huske. De siste 15 årene har jeg hovedsakelig vært involvert i 1C, ikke bare når det gjelder koding, men i 1C generelt. Sette oppgaver, administrasjon og devops her. De siste 5 årene har jeg vært engasjert i samfunnsnyttige aktiviteter når det gjelder utvikling av utviklings- og automatiseringsverktøy for andre 1C-brukere, skriving av artikler og bøker.

La oss bestemme temaet for diskusjon

Først, la oss definere hva vi skal snakke om, siden bokstavene "1C" kan bety mange ting. I dette tilfellet vil vi med bokstavene "1C" utelukkende mene utviklingsrammeverket "1C: Enterprise" til den moderne, åttende versjonen. Vi vil ikke snakke mye om produsenten og dens retningslinjer (men vi må gjøre litt) Vi vil ikke diskutere spesifikke applikasjoner skrevet ved hjelp av dette rammeverket. Teknologi er separat, applikasjoner aka konfigurasjoner er separate.

Høynivåarkitektur 1C: Enterprise

Det er ikke for ingenting jeg nevner ordet "rammeverk". Fra en utviklers synspunkt er 1C-plattformen nettopp et rammeverk. Og du må behandle det nøyaktig som et rammeverk. Tenk på det som Spring eller ASP.NET, utført av en viss kjøretid (henholdsvis JVM eller CLR). Det har seg slik at i en verden av konvensjonell programmering ("ikke 1C") er inndelingen i rammer, virtuelle maskiner og spesifikke applikasjoner naturlig, på grunn av det faktum at disse komponentene vanligvis utvikles av forskjellige produsenter. I 1C-verdenen er det ikke vanlig å eksplisitt skille mellom utviklingsrammeverket og selve kjøretiden, i tillegg er spesifikke applikasjoner skrevet ved hjelp av rammeverket også hovedsakelig utviklet av 1C selv. Som et resultat oppstår det noe forvirring. Derfor, innenfor rammen av artikkelen, må vi vurdere 1C fra flere sider samtidig og klassifisere den langs flere koordinatakser. Og i hver koordinatakse vil vi sette en spade med brunt stoff og se på funksjonene, fordelene og ulempene ved den eksisterende løsningen.

Synspunkter på 1C

1C for kjøperen

Kjøperen kjøper et automatiseringssystem som han raskt kan løse problemene med å automatisere sin egen virksomhet med. En bedrift kan være en liten stall, eller det kan være et stort holdingselskap. Det er tydelig at behovene til disse virksomhetene er forskjellige, men begge støttes av en enkelt plattformkodebase.

For 1C-kjøperen er dette en rask time-to-market. Fort. Raskere enn Java, C# eller JS. Gjennomsnitt. Rundt sykehuset. Det er klart at et visittkortnettsted som bruker React vil vise seg bedre, men backend av et WMS-system vil starte raskere på 1C.

1C som et verktøy

Hver teknologisk løsning har grenser for anvendelighet. 1C er ikke et generellt språk, det lever ikke atskilt fra rammeverket. Det anbefales å bruke 1C når du trenger:

• serverapplikasjon
• søknad hvor økonomi dukker opp
• med ferdige brukergrensesnitt, ORM, rapportering, XML/JSON/COM/PDF/YourDataTransferingFormat
• med støtte til bakgrunnsprosesser og jobber
• med rollebasert sikkerhet
• med skriptbar forretningslogikk
• med muligheten til raskt å lage en prototype og lav time-to-market

Du trenger ikke 1C hvis du vil:

• maskinlæring
• GPU-beregninger
• data-grafikk
• matematiske beregninger
• CAD-system
• signalbehandling (lyd, video)
• høylast http-anrop med hundretusenvis av rps

1C som et produksjonsselskap

Det er verdt å forstå hva virksomheten til 1C som programvareprodusent er. 1C-selskapet selger løsninger på forretningsproblemer gjennom automatisering. Ulike virksomheter, store som små, men det er det hun selger. Midlene for å nå dette målet er forretningsapplikasjoner. For regnskap, lønnsregnskap osv. For å skrive disse søknadene bruker selskapet sin egen utviklingsplattform for forretningsapplikasjoner. Spesielt skreddersydd for vanlige oppgaver i disse samme forretningsapplikasjonene:

• finansregnskap
• enkel tilpasning av forretningslogikk
• brede integrasjonsmuligheter i heterogene IT-landskap

Som produsent mener 1C at dette er strategien som lar deg jobbe med partnere og kunder i en vinn-vinn-modus. Du kan argumentere med dette, men det er omtrent slik selskapet promoterer seg selv: ferdige løsninger på forretningsproblemer som raskt kan tilpasses av partnere og integreres i ethvert IT-landskap.

Alle krav eller ønsker for 1C som rammeverk bør ses utelukkende gjennom dette prismet. "Vi vil ha OOP i 1C," sier utviklerne. «Hvor mye vil det koste oss å støtte OOP i plattformen, vil dette hjelpe oss med å øke salget av bokser?» sier 1C. Åpner sitt "prisme" med å selge løsninger på forretningsproblemer:

- Hei, bedrift, vil du ha OOP i 1C?
– Vil dette hjelpe meg med å løse problemene mine?
- Hvem vet...
– Da er det ikke behov

Denne tilnærmingen kan være god eller dårlig avhengig av hvem som ser på den, men det er bare slik det er. Når du snakker om det faktum at det ikke er noen funksjon X i 1C, må du forstå at den ikke er der av en grunn, men i sammenheng med valget "implementeringskostnad vs fortjenestebeløp".

Teknologisk klassifisering

"Faktisk gjør Odinesniks sitt beste for å bruke de beste mønstrene, nøye utvalgt av omsorgsfulle metodologer og utviklere av 1C-plattformen.
Når du skriver den dumme koden din for et enkelt administrert skjema, bruker du i virkeligheten modell-visning-kontroller с dobbeltveis databinding в tre-lags-data-app-motor, smaksatt objektrelasjonskartlegging på høyt nivå på basen deklarativ metadatabeskrivelseå ha sitt eget plattformuavhengig spørrespråkc deklarativt datadrevet brukergrensesnitt, fullstendig transparent serialisering og domeneorientert programspråk.

Der 1C-utviklere skiller seg fra sine vestlige kolleger er i PR. De elsker å gi noe tull et stort navn og løpe rundt med det som en skitten pose.»
A. Orefkov

1C-plattformen har en klassisk 3-lags arkitektur, i sentrum av denne er applikasjonsserveren (eller dens emulering for lite penger for små butikkeiere). Enten MS SQL eller Postgres brukes som DBMS. Det er også støtte for Oracle og IBM DB2, men dette er ganske esoterisk, ingen vet hva som vil skje hvis du implementerer 1C på disse databasene under middels og høy belastning. Jeg tror at 1C selv ikke vet dette.

Klientdelen er enten en tynnklient installert på brukerens maskin eller en nettklient. Nøkkelfunksjonen er at programmerere ikke skriver 2 forskjellige koder, de skriver en applikasjon, på ett språk, og du kan vise den i nettleseren hvis det er et ønske eller behov. Hvem ville ha en ekte full stack og et enkelt språk for front- og backend, node.js? De klarte aldri å gjøre akkurat det samme før på slutten. En ekte full stack finnes, men du må skrive den i 1C. Skjebnens ironi, slike ting :)

Sky SaaS-løsningen 1C:Fresh fungerer også i nettlesermodus, der du ikke kan kjøpe 1C, men leie en liten database og holde styr på shawarma-salget der. Bare i nettleseren, uten å installere eller konfigurere noe.

I tillegg er det en eldre klient, som i 1C kalles en "vanlig applikasjon". Arven er arv, velkommen til applikasjonsverdenen i 2002, men vi snakker fortsatt om den nåværende tilstanden til økosystemet.

1C-serverdelen støtter klynging og skalering ved å legge til nye maskiner i klyngen. Ganske mange eksemplarer er ødelagt her og det kommer en egen del i artikkelen om dette. Kort sagt, dette er ikke helt det samme som å legge til et par nøyaktig de samme forekomstene bak HAProxy.

Rammeverket for applikasjonsutvikling bruker sitt eget programmeringsspråk, som omtrent ligner en litt forbedret VB6 oversatt til russisk. For folk som hater alt russisk, som ikke tror at "hvis" er oversatt som "hvis", tilbys det andre syntaksalternativet. De. Hvis du ønsker det, kan du skrive det i 1C på en slik måte at det ikke kan skilles fra VB.

Dette programmeringsspråket er hovedårsaken til hatet til 1C kallenavn mot deres plattform. La oss innse det, ikke uten grunn. Språket ble unnfanget så enkelt som mulig, designet for å oppfylle mantraet "UTVIKLER, UTVIKLER" på en skala i det minste i CIS. Den kommersielle essensen av en slik løsning er etter min mening tydelig synlig: flere utviklere, større markedsdekning. Dette gikk i oppfyllelse, ifølge ulike estimater fra 45 % til 95 %. Jeg vil si med en gang at det er lettere å skrive på språket du tror. Og jeg kan ganske mange programmeringsspråk.

La oss starte med språket.

1C programmeringsspråk

Samtidig er systemets sterke og svake punkt. Gir enkel inngang og lesbarhet. På den annen side har den ikke blitt oppdatert siden utgivelsen av versjon 8 i 2002 og er moralsk utdatert. Noen vil si "den største ulempen er at det ikke er noen OOP", og de vil ta feil. For det første liker ikke PLO ikke bare Nuraliev, men også Torvalds. Og for det andre, OOP eksisterer fortsatt.

Fra utviklerens synspunkt har han til disposisjon et rammeverk med basisklasser vist på DBMS. Utvikleren kan ta basisklassen "Directory" og arve "Clients"-katalogen fra den. Den kan legge til nye klassefelt til den, for eksempel INN og Address, og om nødvendig kan den også overstyre (overstyre) metoder for basisklassen, for eksempel OnWrite/AtRecord-metoden.

Rammeverket er utformet på en slik måte at det sjelden er behov for dypere arv, og begrensningen i OOP er etter min mening fornuftig. 1C fokuserer på domenedrevet utvikling og får deg først og fremst til å tenke på fagområdet til løsningen som utvikles, og dette er bra. Det er ikke bare noen fristelse, men det er heller ikke nødvendig å skrive 10 forskjellige DTOer og ViewModels bare for å vise noen data fra domenet et sted. 1C-utvikleren opererer alltid med én enhet, uten å fylle oppfatningskonteksten med et dusin klasser med lignende navn, som representerer den samme enheten, men fra en annen side. Enhver .NET-applikasjon, for eksempel, vil nødvendigvis inneholde fem eller to ViewModels og DTOer for serialisering til JSON og dataoverføring fra klient til server. Og omtrent 10-15 % av applikasjonskoden din vil bli brukt på å overføre data fra en klasse til en annen ved å bruke penner eller krykker som AutoMapper. Denne koden må skrives og programmerere må betales for å lage og vedlikeholde den.

Det viser seg at 1C-språket er vanskelig å utvikle uten å komplisere det til nivået av vanlige språk, og dermed miste fordelen med enkelhet. Hva er leverandørens oppgave som i hovedsak blir løst: å utstede en standardløsning som enhver student fanget på gaten kan tilpasse med det nødvendige kvalitetsnivået (dvs. en sak som dekker fra en bod til en stor fabrikk er ferdigstilt). Hvis du er en stall, ta en student hvis du er en fabrikk, ta en guru fra implementeringspartneren din. Det faktum at implementeringspartnere selger studenter til prisen av en guru er ikke et problem med rammeverket. Arkitektonisk må rammeverket løse problemene til begge, koden for standardkonfigurasjoner (som vi solgte til bedrifter med løftet om tilpasning) skal kunne forstås av en student, og en guru skal kunne forstå hva du vil.

Det som etter min mening virkelig mangler i språket, det som tvinger deg til å skrive mer enn du kunne, er det som kaster bort tid betalt av kunden.

• Mulighet for å skrive på nivået, for eksempel TypeScript (som et resultat, mer utviklede kodeanalyseverktøy i IDE, refactoring, færre offensive jambs)
  Tilgjengelighet av funksjoner som førsteklasses objekter. Et litt mer komplekst konsept, men mengden typisk standardkode kan reduseres betraktelig. Elevens forståelse av koden, IMHO, ville til og med øke på grunn av reduksjonen i volum
• Universell samling bokstaver, initialiseringer. Det samme - å redusere mengden kode som må skrives og/eller ses på med øynene. Fylling av samlinger tar opp over 9000 % av 1C-programmeringstiden. Å skrive dette uten syntaktisk sukker er langt, dyrt og utsatt for feil. Generelt overskrider mengden LOC i 1C-løsninger alle tenkelige grenser sammenlignet med tilgjengelige åpne rammeverk og generelt alle Java-er for bedriften din til sammen. Språket er detaljert, og dette degenererer til mengden data, minne, IDE-bremser, tid, penger...
• endelig konstruksjoner Jeg har en hypotese om at denne konstruksjonen mangler på grunn av at de ikke fant en vellykket oversettelse av den til russisk :)
• Egne datatyper (uten OOP), analoger av Type fra VB6. Det vil tillate deg å ikke skrive strukturer ved å bruke kommentarer i BSP og magiske metoder som konstruerer disse strukturene. Vi får: mindre kode, et hint gjennom en prikk, raskere løsning på problemet, færre feil på grunn av skrivefeil og manglende egenskaper til strukturer. Nå hviler skrivingen av brukerstrukturer utelukkende hos utviklingsteamet til Standard Subsystem Library, som, til sin ære, skriver nøye kommentarer om de forventede egenskapene til de beståtte parameterstrukturene.
• Ingen sukker når du arbeider med asynkrone anrop på nettklienten. callback-helvete i form av ProcessingNotifications er en midlertidig krykke forårsaket av en plutselig endring i API-en til hovednettleserne, men du kan ikke leve slik hele tiden mer og mer. Legg til ingen støtte for dette paradigmet i hoved-IDE, og ting blir enda verre.

Dette er et av de presserende problemene, det er klart at listen kan være mye større, men vi må ikke glemme at dette fortsatt ikke er et generellt språk, det krever ikke multithreading, lambda-funksjoner, tilgang til GPU og rask flyttallsberegninger. Dette er et skriptspråk for forretningslogikk.

En programmerer som allerede har jobbet mye med dette språket, ser på js eller c#, blir lei innenfor rammen av dette språket. Det er fakta. Han trenger utvikling. På den andre siden av skalaen for leverandøren er kostnadene ved å implementere de spesifiserte funksjonene versus økningen i inntekter etter implementeringen. Her har jeg ingen informasjon om hva som for tiden veier opp i selskapets øyne.

Utviklingsmiljø

Heller ikke her går det knirkefritt. Det er to utviklingsmiljøer. Den første er konfiguratoren som er inkludert i leveransen. Det andre er Enterprise Development Tools-miljøet, eller EDT for kort, utviklet på grunnlag av Eclipse.

Konfiguratoren gir et komplett utvalg av utviklingsoppgaver, støtter alle funksjoner og er hovedmiljøet på markedet. Det er også moralsk foreldet, og utvikler seg ikke, ifølge ryktene - på grunn av mengden teknisk gjeld i seg selv. Situasjonen kan forbedres ved å åpne en intern API (i form av vennskap med Snømann A. Orefkova eller på uavhengig grunnlag), men dette er ikke tilfelle. Praksis har vist at fellesskapet vil skrive sine egne funksjoner i IDE, så lenge leverandøren ikke forstyrrer. Men vi har det vi har. Konfiguratoren var flott i 2004-2005, minner veldig om Visual Studio på den tiden, noen steder var den enda kulere, men den satt fast på den tiden.

I tillegg har volumet av den gjennomsnittlige standardløsningen vokst flere ganger siden den gang, og i dag kan IDE rett og slett ikke takle hvor mye kode den mates med. Brukervennlighet og refaktoriseringsevner er ikke engang null, de er i minus. Alt dette gir ikke utviklerne entusiasme og de drømmer om å flytte til andre økosystemer og fortsette å kode dritt der, men i et hyggelig miljø som ikke spytter deg i ansiktet med sin oppførsel.

Som et alternativ tilbys en IDE skrevet fra bunnen av, bygget på Eclipse. Der lever kildene, som i all annen programvare, i form av tekstfiler, lagres i GIT, pull request-grener, alt dette. På minussiden har den ikke forlatt betastatus på mange år nå, selv om den blir bedre for hver utgivelse. Jeg vil ikke skrive om ulempene med EDT, i dag er det et minus, i morgen er det en fast funksjon. Relevansen av en slik beskrivelse vil raskt forsvinne. I dag er det mulig å utvikle i EDT, men det er uvanlig at du må være forberedt på et visst antall IDE-feil.

Hvis du ser på situasjonen gjennom det nevnte "1C-prismet", får du noe sånt som dette: utgivelsen av den nye IDE øker ikke salget av bokser, men utstrømningen av UTVIKLERE kan bli redusert. Det er vanskelig å si hva som venter økosystemet når det gjelder utviklerkomfort, men Microsoft har allerede skrudd opp mobile utviklere ved å tilby dem tjenestene for sent.

Utviklingsledelse

Alt her er betydelig bedre enn å skrive kode, spesielt nylig, da innsatsen til fellesskapet brakte frem problemene med administrasjonsautomatisering, lanserte prototyper som krever å kaste 1C-depotet i søppelhaugen og bruke git, quick blame, code-review , statisk analyse, automatisk distribusjon og så videre. Mange funksjoner er lagt til plattformen som øker nivået på automatisering av utviklingsoppgaver. Imidlertid ble alle disse funksjonene lagt til kun og eksklusivt for utviklingen av våre egne store produkter, da det ble åpenbart at vi ikke kunne klare oss uten automatisering. Det var automatisk sammenslåing, treveis sammenligning med KDiff og alt det der. Lansert på Github gitconverter, som, ærlig talt, ideologisk ble dratt bort fra prosjektet gitsync, men modifisert for å passe leverandørselskapets prosesser. Takket være de gjenstridige gutta fra åpen kildekode, kom utviklingsautomatisering i 1C i gang. Et åpent API for konfiguratoren, IMHO, ville også flytte den moralske tilbakelentheten til hoved-IDEen.

I dag rapporterer lagring av 1C-kilder i git med forpliktelser knyttet til problemer i Jira, anmeldelser i Crucible, trykknapp fra Jenkins og Allure om kodetesting i 1C og til og med statisk analyse i SonarQube – dette er langt fra nyheter, men heller mainstream i selskaper hvor det er mye 1C-utvikling.

administrasjon

Det er mye å si her. For det første er dette selvfølgelig en server (1C server cluster). En fantastisk ting, men på grunn av det faktum at det er en helt svart boks, dokumentert i tilstrekkelig detalj, men på en spesifikk måte - å mestre lanseringen av uavbrutt drift i høybelastningsmodus på flere servere er partiet for noen få utvalgte som bærer en medalje med påskriften "Ekspert på teknologiske spørsmål". Det er verdt å merke seg at administrering av en 1C-server i prinsippet ikke er forskjellig fra å administrere en hvilken som helst annen server. Det er et nettverksbasert, multi-threaded program som bruker minne, CPU og diskressurser. Gir store muligheter for telemetriinnsamling og diagnostikk.

Problemet her er at leverandøren ikke tilbyr noe spesielt når det gjelder ferdige løsninger for akkurat denne diagnostikken. Ja, det er 1C: Instrumentation and Control Center, de er til og med ganske gode, men de er veldig dyre og ikke alle har dem. Det er en rekke utviklinger i fellesskapet for å koble sammen Grafana, Zabbix, ELK og andre ting fra standard admin-settet, men det er ingen enkelt løsning som vil passe flertallet. Oppgaven venter på helten. Og hvis du er en bedrift som planlegger å lansere på en 1C-klynge, trenger du en ekspert. Din egen innside eller fra utsiden, men du trenger det. Det er normalt at det er en egen rolle med kompetanse for serverdrift, ikke alle 1C-brukere bør vite dette, du trenger bare å forstå at en slik rolle er nødvendig. La oss ta SAP for eksempel. Der vil en programmerer mest sannsynlig ikke engang reise seg fra stolen hvis han blir bedt om å konfigurere noe på applikasjonsserveren. Han kan bare være dum og han vil ikke skamme seg. I SAP-metodikken er det en egen medarbeiderrolle for dette. Av en eller annen grunn mener man i 1C-bransjen at dette bør kombineres i én ansatt for samme lønn. Det er en vrangforestilling.

Ulemper med 1C server

Det er nøyaktig ett minus - pålitelighet. Eller, hvis du foretrekker det, uforutsigbarhet. Plutselig merkelig oppførsel av serveren har allerede blitt snakk om byen. Et universelt middel - å stoppe serveren og tømme alle cacher - er til og med beskrevet i ekspertens håndbok, og til og med en batchbok anbefales som gjør dette. Hvis 1C-systemet ditt begynner å gjøre noe som det ikke engang teoretisk burde gjøre, er det på tide å tømme øktdatabufferen. I følge mitt estimat er det bare tre personer i hele landet som vet hvordan de skal betjene en 1C-server uten denne prosedyren, og de deler ikke hemmeligheter, fordi... de lever av dette. Kanskje hemmeligheten deres er at de renser øktdata, men de forteller ikke noen om det, dude.

Ellers er 1C-serveren den samme applikasjonen som alle andre og administreres omtrent på samme måte, ved å lese dokumentasjonen og banke på tamburinen.

Docker

Nytten av å bruke en containerisert 1C-server i produksjonen er ennå ikke bevist. Serveren er ikke gruppert ved å legge til noder bak balanseren, noe som reduserer fordelene med produksjonscontainerisering til et minimum, og praksisen med vellykket drift i containere i høylastmodus er ikke etablert. Som et resultat er det bare utviklere som bruker Docker+1C til å sette opp testmiljøer. Der er det veldig nyttig, brukt, lar deg leke med moderne teknologier og ta en pause fra konfiguratorens motløshet.

Kommersiell komponent

Fra et investeringssynspunkt lar 1C deg løse problemet med å raskt lansere forretningsideer på grunn av de brede egenskapene til applikasjonsklasser. 1C ut av esken gir veldig grei Rapportering, integrasjon med hva som helst, webklient, mobilklient, mobilapplikasjon, støtte for ulike DBMS-er, inkl. gratis, kryssplattform både server og installerte klientdeler. Ja, brukergrensesnittet til applikasjoner vil være gult, noen ganger er dette et minus, men ikke alltid.
Ved å velge 1C får en bedrift et sett med programvareløsninger som lar dem bygge et veldig bredt spekter av applikasjoner, samt mange utviklere på markedet som vil ha mindre penger enn Javaister og samtidig produsere resultater raskere.

For eksempel kan oppgaven med å sende en PDF-faktura til en klient løses på en time med elevarbeid. Det samme problemet i .NET kan løses ved å kjøpe et proprietært bibliotek, eller et par dager eller uker med koding av en streng, skjeggete utvikler. Noen ganger, begge deler på en gang. Og ja, jeg snakket bare om PDF-generering. Vi har ikke sagt hvor denne regningen en gang kommer fra. Nettfrontenderen må lage et skjema der operatøren skal legge inn dataene, backenderen må lage dto-modeller for overføring av JSON, modeller for lagring i databasen, strukturen til selve databasen, migrering til den, dannelsen av en grafisk visning av denne kontoen, og først da - PDF. På 1C er hele oppgaven, fra bunnen av, ferdig på nøyaktig én time.

Et fullverdig regnskapssystem for en liten bod med én forretningsprosess kjøpt/solgt gjøres på 3 timer med salgsrapportering, regnskapsføring av varer til kjøps- og salgspriser, fordelt på lager, tilgangsrettighetskontroll, webklient og mobilapplikasjon. . Ok, jeg glemte søknaden, med søknaden ikke om 3 timer, om seks.

Hvor lang tid vil denne oppgaven ta en .NET-utvikler fra å installere visual studio på en ren datamaskin til å demonstrere den for kunden? Hva med kostnadene ved utvikling? Samme ting.

Styrkene til 1C som plattform

1C er sterk, ikke fordi det er noe spesifikt med det som er det beste i verden. Tvert imot, i hvert enkelt delsystem kan du finne en mer interessant analog i verdens programvare. Basert på en kombinasjon av faktorer ser jeg imidlertid ikke en plattform som ligner på 1C. Det er her kommersiell suksess ligger. Fordelene med plattformen er spredt utover den og er tydeligst synlig når du ser hvordan dette gjøres på andre plattformer. I utgangspunktet er dette IKKE engang funksjoner, men tvert imot - en avvisning av funksjoner til fordel for ett spesifikt paradigme. Noen få eksempler:

1. Unicode. Hva i helvete kan være enklere? Det er ikke nødvendig å bruke enkeltbyte ASCII-kodinger i 2019 (bortsett fra integrasjon med gamle eldre). Aldri. Men nei. Uansett, noen i en tabell bruker en enkeltbyte varchar og applikasjonen vil ha problemer med koding. I 2015 mislyktes gitlabs LDAP-autorisasjon på grunn av feil arbeid med kodinger. JetBrains IDE fungerer fortsatt ikke med kyrilliske filnavn overalt. 1C gir høykvalitets isolasjon av applikasjonskode fra databaselaget. Der er det umulig å skrive tabeller på lavt nivå og jambs av inkompetente juniorer på databasenivå er umulig der. Ja, det kan være andre problemer med inkompetente juniorer, men variasjonen av problemer er mye mindre. Nå vil du fortelle meg at applikasjonen din er riktig utformet og databasetilgangslaget er isolert som det skal. Ta en ny titt på din egendefinerte Java-applikasjon. Nært og ærlig. Plager samvittigheten deg? Da er jeg glad i deg.
2. Nummerering av dokumenter/oppslagsverk. I 1C er det definitivt ikke den mest fleksible og ikke den beste. Men det de gjør i bankprogramvare og i selvskrevne regnskapssystemer - vel, det er bare mørke. Enten vil identiteten sitte fast i (og så «å, hvorfor har vi hull»), eller tvert imot vil de lage en generator som fungerer med låsing på DBMS-nivå (og blir en flaskehals). Faktisk er det ganske vanskelig å gjøre denne tilsynelatende enkle oppgaven - en ende-til-ende opptelling av enheter, med en unikhetsseksjon basert på et visst sett med nøkler, prefiks, slik at den ikke blokkerer databasen under parallell dataregistrering .
3. Identifikatorer for poster i databasen. 1C tok en viljesterk avgjørelse - alle lenkeidentifikatorer er absolutt syntetiske og det er det. Og det er ingen problemer med distribuerte databaser og utvekslinger. Utviklere av andre systemer skaper hardnakket noe sånt som identitet (den er kortere!), dra dem inn i GUI til det er på tide å lage flere relaterte forekomster (og da vil de bli oppdaget). Har du ikke dette? Ærlig talt?
4. Lister. 1C har ganske vellykkede mekanismer for å bla gjennom (store) lister og navigere gjennom dem. La meg gjøre en reservasjon med en gang - med riktig bruk av mekanismen! Generelt er emnet ganske ubehagelig, det kan ikke løses ideelt: det er enten intuitivt og enkelt (men risikoen for enorme rekordsett på klienten), eller personsøking er av en eller annen skjevhet. De som driver med personsøking gjør det ofte skjevt. De som lager en ærlig rullefelt legger til en database, en kanal og en klient.
5. Administrerte skjemaer. Uten tvil, i webklienten fungerer ikke grensesnittet perfekt. Men det fungerer. Men for mange andre regnskaps- og banksystemer er det et prosjekt på bedriftsnivå å opprette en ekstern arbeidsplass. Ansvarsfraskrivelse: Heldigvis for de som opprinnelig laget det på nettet, vil dette ikke påvirke.
6. Mobilapp. Nylig kan du også skrive mobilapplikasjoner mens du er i samme økosystem. Det er litt mer komplisert her enn med en nettklient; detaljene til enhetene tvinger deg til å skrive spesielt for dem, men du ansetter ikke desto mindre et eget team med mobilutviklere. Hvis du trenger en applikasjon for de interne behovene til en bedrift (når en mobil løsning på et bedriftsproblem er viktigere enn en gul UI-design), bruker du ganske enkelt den samme plattformen ut av esken.
7. Rapportering. Med dette ordet mener jeg ikke et BI-system med store data og etterslep på ETL-prosessen. Dette refererer til operative stabsrapporter som lar deg vurdere regnskapstilstanden her og nå. Saldoer, innbyrdes oppgjør, omgradering mv. 1C kommer ut av esken med et rapporteringssystem med fleksible innstillinger for grupperinger, filtre og visualisering på brukersiden. Ja, det finnes kjøligere analoger på markedet. Men ikke innenfor rammen av en alt-i-ett-løsning og til en pris som noen ganger er høyere enn en alt-i-ett-løsning. Og oftere er det til og med omvendt: bare rapportering, men dyrere enn hele plattformen, og dårligere kvalitet.
8. Utskrivbare skjemaer. Vel, bruk .NET for å løse problemet med å sende lønnsslipper i PDF til ansatte på e-post. Og nå oppgaven med å skrive ut fakturaer. Hva med å lagre kopiene deres til samme PDF? For 1C kallenavn, utgang av et hvilket som helst layout til PDF er +1 kodelinje. Dette betyr + 40 sekunders arbeidstid, i stedet for dager eller uker på et annet språk. Utskrevne skjemaoppsett i 1C er utrolig enkle å utvikle og kraftige nok til å konkurrere med betalte motparter. Ja, sannsynligvis er det ikke mange interaktive muligheter i 1C-regnearkdokumenter, du kan ikke raskt få et 3D-diagram med skalering ved hjelp av OpenGL. Men er det virkelig nødvendig?

Dette er bare en håndfull eksempler der begrensende funksjonalitet eller implementering av kompromisser viser seg å være en viktig arkitektonisk fordel i fremtiden. Selv et kompromiss eller ikke det mest effektive alternativet - det er allerede i esken og tas for gitt. Dens uavhengige implementering vil enten være umulig (fordi slike beslutninger må tas i begynnelsen av prosjektet, og det er ikke tid til det, og det er ingen arkitekt i det hele tatt), eller flere dyre iterasjoner. I hvert av de oppførte punktene (og dette er ikke en fullstendig liste over arkitektoniske løsninger) kan du skru opp og innføre restriksjoner som blokkerer skalering. Uansett må du, som forretningsmann, sørge for at programmererne dine, når de lager et "system fra bunnen av", har rette hender og vil gjøre subtile systemproblemer med en gang.

Ja, som i alle andre komplekse system, har 1C selv også løsninger som blokkerer skalering i visse aspekter. Men jeg gjentar, basert på en kombinasjon av faktorer, eierkostnader og antall problemer som allerede er løst på forhånd, ser jeg ikke en verdig konkurrent på markedet. For samme pris får du et økonomisk applikasjonsrammeverk, en klynget balansert server, med UI og webgrensesnitt, med en mobilapplikasjon, med rapportering, integrasjon og en haug med andre ting. I Java-verdenen ansetter du et front-end- og back-end-team, feilsøker stimer på lavt nivå med hjemmeskrevet serverkode og betaler separat for 2 mobilapplikasjoner for 2 mobile OS.

Jeg sier ikke at 1C vil løse alle saker, men for en intern bedriftsapplikasjon, når det ikke er behov for å merke brukergrensesnittet - hva mer trengs?

Fly i salven

Du har sannsynligvis fått inntrykk av at 1C vil redde verden og at alle andre måter å skrive bedriftssystemer på er feil. Det er ikke sånn i det hele tatt. Fra en forretningsmanns synspunkt, hvis du velger 1C, må du i tillegg til rask time-to-market ta hensyn til følgende ulemper:

• Server pålitelighet. Det kreves spesialister av høy kvalitet som kan sikre uavbrutt drift. Jeg kjenner ikke til et ferdig opplæringsprogram for slike spesialister fra leverandøren. Det finnes kurs for å forberede seg til Eksperteksamenen, men dette er etter min mening ikke nok.
• Brukerstøtte. Se forrige punkt. For å få støtte fra leverandøren, må du kjøpe den. Av en eller annen grunn er dette ikke akseptert i 1C-industrien. Og med SAP er det nesten et must-kjøp og det plager ingen. Uten bedriftsstøtte og uten en ekspert på personalet, kan du stå alene med 1C-feil.
• Likevel kan du ikke gjøre absolutt alt med 1C. Dette er et verktøy, og som alle andre verktøy har det grenser for anvendelighet. I 1C-landskapet er det svært ønskelig å ha en "ikke-1C" systemarkitekt.
• Gode ​​1C kallenavn er ikke billigere enn gode programmerere på andre språk. Selv om dårlige programmerere er dyre å ansette, uavhengig av språket de skriver på.

La oss prikke prikkene

• 1C er et rammeverk for rask applikasjonsutvikling (RAD) for virksomheten og er skreddersydd for dette.
• Tre-lags kobling med støtte for store DBMS-er, klientgrensesnitt, en veldig god ORM og rapportering
• Brede muligheter for integrasjon med systemer som kan det 1C ikke kan. Hvis du vil ha maskinlæring, ta Python og send resultatet til 1C via http eller RabbitMQ
• Det er ikke nødvendig å strebe etter å gjøre alt ved å bruke 1C, du må forstå styrken og bruke dem til dine egne formål
• Utviklere som graviterer mot å grave inn i teknologiske rammeverk og redesigne hvert N år til en ny motor, kjeder seg med 1C. Alt er veldig konservativt der.
• Utviklere er også lei fordi det er veldig lite bekymring for dem fra produsenten. Kjedelig språk, svak IDE. De krever modernisering.
• På den annen side er utviklere som ikke finner moro ved å bruke og lære en annen teknologi de liker, dårlige utviklere. De vil sutre og flytte til et annet økosystem.
• Arbeidsgivere som ikke lar 1C-kallenavnene deres skrive noe i Python, er dårlige arbeidsgivere. De vil miste ansatte med nysgjerrige sinn, og i deres sted vil det komme apekodere som, mens de er enige i alt, vil dra bedriftens programvare inn i sumpen. Det vil fortsatt måtte skrives om, så kanskje det er bedre å investere litt i Python litt tidligere?
• 1C er et kommersielt selskap og implementerer funksjoner utelukkende basert på egne interesser og hensiktsmessighet. Du kan ikke klandre henne for dette, virksomheten må tenke på profitt, sånn er livet
• 1C tjener penger ved å selge løsninger på forretningsproblemer, ikke til Vasyas utviklerproblemer. Disse to konseptene korrelerer, men prioriteringen er akkurat det jeg sa. Når utvikler Vasya er klar til å betale for en personlig lisens for 1C: Resharper, vil det vises ganske raskt, "Resharper" av A. Orefkova er et bevis på dette. Hvis leverandøren støttet det, og ikke kjempet mot det, ville det dukke opp et marked for programvare for utviklere. Nå er det en og en halv aktør i dette markedet med tvilsomme resultater, og alt fordi integrasjonen med IDE er negativ og alt gjøres på krykker.
• Praksisen med en multimaskinoperatør vil forsvinne i glemselen. Moderne applikasjoner er for store til å huske både fra kodesiden og fra forretningsbrukssiden. 1C-serveren blir også mer kompleks; det vil være umulig å holde alle typer ekspertise i én ansatt. Dette bør innebære en etterspørsel etter spesialister, noe som betyr attraktiviteten til 1C-yrket og en økning i lønn. Hvis Vasya tidligere jobbet tre-i-en for én lønn, må du nå ansette to Vasyaer, og konkurranse mellom Vasyaer kan stimulere den generelle veksten av nivået deres.

Konklusjon

1C er et veldig verdig produkt. I min prisklasse kjenner jeg ingen analoger i det hele tatt, skriv i kommentarfeltet hvis det er noen. Utstrømmen av utviklere fra økosystemet blir imidlertid mer og mer merkbar, og dette er en "hjerneflukt", uansett hvordan du ser på det. Industrien er sulten på modernisering.
Hvis du er en utvikler, ikke heng deg opp i 1C og ikke tenk at alt er magisk på andre språk. Mens du er junior, kanskje. Så snart noe større skal løses, vil ferdige løsninger måtte letes lenger etter og gjennomføres mer intensivt. Når det gjelder kvaliteten på "blokkene" som en løsning kan bygges fra, er 1C veldig, veldig bra.

Og en ting til - hvis et 1C-kallenavn kommer til deg for å ansette, kan 1C-kallenavnet trygt utnevnes til stillingen som ledende analytikere. Deres forståelse av oppgaven, fagområdet og nedbrytningsferdighetene er utmerket. Jeg er sikker på at dette nettopp skyldes tvungen bruk av DDD i 1C-utvikling. En person er opplært til å tenke på betydningen av en oppgave først av alt, på forbindelsene mellom objekter i fagområdet, og har samtidig en teknisk bakgrunn i integrasjonsteknologier og datautvekslingsformater.

Vær klar over at den ideelle rammen ikke eksisterer og ta vare på deg selv.
Alt bra!

PS: tusen takk speshurisk for hjelp til å utarbeide artikkelen.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Har du 1C i bedriften din?

• 13,3%Ikke i det hele tatt.71

• 30,3%Det er, men bare i regnskapsavdelingen et sted. Kjernesystemer på andre plattformer162

• 41,4%Ja, de viktigste forretningsprosessene fungerer på it221

• 15,0%1C må dø, fremtiden tilhører %technology_name%80

534 brukere stemte. 99 brukere avsto.

Kilde: www.habr.com