1C - Gott och ont. Arrangemang av punkter i holivar runt 1C

Vänner och kollegor, på senare tid har det varit mer frekventa artiklar om Habré med hat mot 1C som utvecklingsplattform och tal från dess försvarare. Dessa artiklar identifierade ett allvarligt problem: oftast kritiserar kritiker av 1C det från ståndpunkten att de "inte behärskar det", skäller ut problem som de facto lätt kan lösas, och tvärtom, inte rör problem som är riktigt viktiga, värda diskuterar och löses inte av säljaren. Jag anser att det är vettigt att genomföra en sober och balanserad granskning av 1C-plattformen. Vad den kan göra, vad den inte kan göra, vad den borde göra men inte gör, och, till efterrätt, vad den gör med råge, och dina utvecklare på %technology_name% kommer att göra i hundra år och slänga den mer än en årlig budget.

Som ett resultat kommer du som chef eller arkitekt att kunna få en tydlig förståelse för vilken uppgift det kommer att vara fördelaktigt för dig att använda 1C, och var det behöver brännas ut med ett varmt strykjärn. Som utvecklare i "icke-1C"-världen kommer du att kunna se vad som finns i 1C som orsakar bråk. Och som 1C-utvecklare kommer du att kunna jämföra ditt system med andra språks ekosystem och förstå din plats i koordinatsystemet för mjukvaruutveckling.

Under klippet finns det många tjocka attacker mot 1C, mot kritiker av 1C, på Java, .NET och i allmänhet... Fläkten är full, välkommen!

Om mig

Jag har varit bekant med samtalsämnet sedan cirka 2004. Jag har programmerat förmodligen sedan jag var 6 år gammal, från det att jag fick en bok om professor Fortran med serier om en katt, en sparv och en larv. Jag analyserade programmen som katten skrev från bilderna i boken och fick reda på vad de gjorde. Och ja, jag hade inte en riktig dator vid den tiden, men det fanns en teckning på bokens spridning och jag tryckte ärligt på pappersknapparna och skrev in kommandona jag hade spionerat på katten X.

Sedan var det BK0011 och BASIC i skolan, C++ och montörer på universitetet, sedan 1C, och sedan så många andra saker som jag är för lat för att komma ihåg. De senaste 15 åren har jag främst varit engagerad i 1C, inte bara vad gäller kodning, utan i 1C i allmänhet. Ställer in uppgifter, administration och devops här. De senaste 5 åren har jag ägnat mig åt socialt nyttiga aktiviteter när det gäller att utveckla utvecklings- och automationsverktyg för andra 1C-användare, skriva artiklar och böcker.

Låt oss ta ställning till diskussionsämnet

Låt oss först definiera vad vi ska prata om, eftersom bokstäverna "1C" kan betyda många saker. I det här fallet menar vi med bokstäverna "1C" uteslutande utvecklingsramverket "1C: Enterprise" i den moderna åttonde versionen. Vi kommer inte att prata mycket om tillverkaren och dess policy (men vi måste göra lite).Vi kommer inte att diskutera specifika applikationer skrivna med detta ramverk. Teknik är separat, applikationer aka konfigurationer är separata.

Högnivåarkitektur 1C: Enterprise

Det är inte för inte som jag nämner ordet "ramverk". Ur utvecklarens synvinkel är 1C-plattformen just ett ramverk. Och du måste behandla det precis som ett ramverk. Tänk på det som Spring eller ASP.NET, kört av någon körtid (JVM respektive CLR). Det råkar vara så att i en värld av konventionell programmering (“inte 1C”) är uppdelningen i ramverk, virtuella maskiner och specifika applikationer naturlig, på grund av att dessa komponenter vanligtvis utvecklas av olika tillverkare. I 1C-världen är det inte vanligt att explicit särskilja utvecklingsramverket och själva körtiden; dessutom utvecklas specifika applikationer som skrivs med ramverket också huvudsakligen av 1C själv. Som ett resultat uppstår viss förvirring. Därför måste vi, inom ramen för artikeln, överväga 1C från flera sidor samtidigt och klassificera den längs flera koordinataxlar. Och i varje koordinataxel kommer vi att lägga en spade av brunt ämne och titta på funktionerna, fördelarna och nackdelarna med den befintliga lösningen.

Synpunkter på 1C

1C för köparen

Köparen köper ett automationssystem med vilket han snabbt kan lösa problemen med att automatisera sin egen verksamhet. Ett företag kan vara ett litet stall, eller det kan vara ett stort holdingbolag. Det är tydligt att behoven hos dessa företag är olika, men båda stöds av en enda plattformskodbas.

För 1C-köparen är detta en snabb time-to-market. Snabb. Snabbare än Java, C# eller JS. Genomsnitt. Runt sjukhuset. Det är klart att en visitkortswebbplats som använder React kommer att bli bättre, men backend av ett WMS-system kommer att starta snabbare på 1C.

1C som ett verktyg

Varje teknisk lösning har gränser för tillämpbarhet. 1C är inte ett allmänspråk, det lever inte separat från sitt ramverk. Det är lämpligt att använda 1C när du behöver:

• serverapplikation
• applikation där ekonomi dyker upp
• med färdigt UI, ORM, Reporting, XML/JSON/COM/PDF/YourDataTransferingFormat
• med stöd för bakgrundsprocesser och jobb
• med rollbaserad säkerhet
• med skriptbar affärslogik
• med förmågan att snabbt skapa en prototyp och låg time-to-market

Du behöver inte 1C om du vill:

• maskininlärning
• GPU-beräkningar
• Datorgrafik
• matematiska beräkningar
• CAD-system
• signalbehandling (ljud, video)
• ladda http-anrop med hundratusentals rps

1C som ett tillverkningsföretag

Det är värt att förstå vad 1C har för verksamhet som mjukvarutillverkare. 1C-företaget säljer lösningar på affärsproblem genom automatisering. Olika företag, stora som små, men det är vad hon säljer. Medlen för att uppnå detta mål är affärsapplikationer. För bokföring, löneredovisning etc. För att skriva dessa ansökningar använder företaget sin egen utvecklingsplattform för affärsapplikationer. Speciellt skräddarsydd för vanliga uppgifter i samma affärsapplikationer:

• finansiell redovisning
• enkel anpassning av affärslogik
• breda integrationsmöjligheter i heterogena IT-landskap

Som tillverkare tror 1C att detta är strategin som gör att du kan arbeta med partners och kunder i ett win-win-läge. Man kan argumentera med detta, men ungefär så här marknadsför företaget sig: färdiga lösningar på affärsproblem som snabbt kan anpassas av partners och integreras i vilket IT-landskap som helst.

Alla anspråk eller önskemål om 1C som ramverk bör ses uteslutande genom detta prisma. "Vi vill ha OOP i 1C", säger utvecklarna. "Hur mycket kommer det att kosta oss att stödja OOP i plattformen, kommer detta att hjälpa oss att öka försäljningen av lådor?" säger 1C. Öppnar sitt "prisma" för att sälja lösningar på affärsproblem:

- Hej, företag, vill du ha OOP i din 1C?
- Kommer detta att hjälpa mig att lösa mina problem?
- Vem vet...
– Då finns det inget behov

Detta tillvägagångssätt kan vara bra eller dåligt beroende på vem som tittar på det, men det är bara så det är. På tal om det faktum att det inte finns någon funktion X i 1C, måste du förstå att den inte finns där av en anledning, utan i samband med valet "implementeringskostnad vs vinstbelopp".

Teknisk klassificering

"Odinesniks gör faktiskt sitt bästa för att använda de bästa mönstren, noggrant utvalda av omtänksamma metodologer och utvecklare av 1C-plattformen.
När du skriver din dumma kod för en enkel hanterad form använder du i verkligheten modell-view-controller с dubbelriktad databindning в tre-lagers-data-app-motor, smaksatt objektrelationskartläggning på hög nivå på basen deklarativ metadatabeskrivningha sin egen plattformsoberoende frågespråk, C- deklarativt datadrivet användargränssnitt, fullständig transparent serialisering och domänorienterat programspråk.

Där 1C-utvecklare skiljer sig från sina västerländska kollegor är i PR. De älskar att ge alla skitsnack ett stort namn och springa runt med det som en smutsig påse.”
A. Orefkov

1C-plattformen har en klassisk 3-skiktsarkitektur, i mitten av denna är applikationsservern (eller dess emulering för lite pengar för små butiksinnehavare). Antingen MS SQL eller Postgres används som DBMS. Det finns också stöd för Oracle och IBM DB2, men detta är ganska esoteriskt, ingen vet vad som kommer att hända om du implementerar 1C på dessa databaser under medelhög och hög belastning. Jag tror att 1C själv inte vet detta.

Klientdelen är antingen en tunn klient installerad på användarens dator eller en webbklient. Nyckelfunktionen är att programmerare inte skriver 2 olika koder, de skriver en applikation, på ett språk, och du kan visa den i webbläsaren om det finns ett önskemål eller behov. Vem där ville ha en riktig fullstack och ett enda språk för front- och backend, node.js? De lyckades aldrig göra exakt samma sak till slutet. En riktig fullstack finns, men du måste skriva den i 1C. Ödets ironi, sådana saker :)

Molnet SaaS-lösningen 1C:Fresh fungerar även i webbläsarläge, där man inte kan köpa 1C, utan hyra en liten databas och hålla koll på shawarmaförsäljningen där. Bara i webbläsaren, utan att installera eller konfigurera något.

Dessutom finns det en äldre klient, som i 1C kallas en "vanlig applikation". Arvet är arv, välkommen till applikationsvärlden 2002, men vi talar fortfarande om ekosystemets nuvarande tillstånd.

1C-serverdelen stöder klustring och skalning genom att lägga till nya maskiner till klustret. Ganska många kopior har brutits här och det kommer att finnas ett separat avsnitt i artikeln om detta. Kort sagt, detta är inte riktigt detsamma som att lägga till ett par exakt samma instanser bakom HAProxy.

Ramverket för applikationsutveckling använder sitt eget programmeringsspråk, som ungefär liknar en något förbättrad VB6 översatt till ryska. För människor som hatar allt ryskt, som inte tror att "om" är översatt som "om", erbjuds det andra syntaxalternativet. De där. Om du vill kan du skriva det i 1C på ett sådant sätt att det inte går att skilja från VB.

Just detta programmeringsspråk är huvudorsaken till hatet mot 1C smeknamn mot deras plattform. Låt oss inse det, inte utan anledning. Språket var tänkt så enkelt som möjligt, utformat för att uppfylla mantrat "UTVECKLARE, UTVECKLARE" på en skala åtminstone i OSS. Den kommersiella essensen av en sådan lösning är enligt min mening tydligt synlig: fler utvecklare, större marknadstäckning. Detta blev sant, enligt olika uppskattningar från 45% till 95%. Jag ska genast säga att det är mycket lättare att skriva på det språk du tycker. Och jag kan ganska många programmeringsspråk.

Låt oss börja med språket.

1C programmeringsspråk

Samtidigt är systemets starka och svaga punkt. Ger enkel ingång och läsbarhet. Å andra sidan har den inte uppdaterats sedan version 8 släpptes 2002 och är moraliskt föråldrad. Någon kommer att säga "den största nackdelen är att det inte finns någon OOP" och de kommer att ha fel. För det första gillar PLO inte bara Nuraliev utan även Torvalds. Och för det andra, OOP existerar fortfarande.

Ur utvecklarens synvinkel har han till sitt förfogande ett ramverk med basklasser som visas på DBMS. Utvecklaren kan ta basklassen "Directory" och ärva "Clients"-katalogen från den. Den kan lägga till nya klassfält till den, till exempel INN och Address, och även, om det behövs, kan den åsidosätta (åsidosätta) metoder för basklassen, till exempel OnWrite/AtRecord-metoden.

Ramverket är utformat på ett sådant sätt att djupare nedärvning sällan behövs, och begränsningen i OOP är enligt min mening vettig. 1C fokuserar på Domain Driven Development och får dig först och främst att tänka på ämnesområdet för lösningen som utvecklas, och det är bra. Det finns inte bara ingen frestelse, utan heller inget behov av att skriva 10 olika DTO:er och ViewModels bara för att visa lite data från domänen någonstans. 1C-utvecklaren arbetar alltid med en enhet, utan att belamra perceptionskontexten med ett dussin klasser med liknande namn, som representerar samma enhet, men från en annan sida. Alla .NET-applikationer kommer till exempel nödvändigtvis att innehålla fem eller två ViewModels och DTO:er för serialisering till JSON och dataöverföring från klient till server. Och ungefär 10-15 % av din applikationskod kommer att spenderas på att överföra data från en klass till en annan med hjälp av pennor eller kryckor som AutoMapper. Denna kod måste skrivas och programmerare måste få betalt för att skapa och underhålla den.

Det visar sig att 1C-språket är svårt att utveckla utan att komplicera det till nivån för vanliga språk, och därmed förlora fördelen med enkelhet. Vad är säljarens uppgift som i huvudsak löses: att utfärda en standardlösning som varje elev som fångas på gatan kan anpassa med den erforderliga kvalitetsnivån (dvs. ett fodral som täcker från ett stall till en stor fabrik färdigställs). Om du är ett stall, ta en student; om du är en fabrik, ta en guru från din implementerande partner. Det faktum att implementerande partners säljer studenter till priset av en guru är inget problem med ramverket. Arkitektoniskt måste ramverket lösa problemen för båda, koden för standardkonfigurationer (som vi sålde till företag med löfte om anpassning) ska kunna förstås av en student, och en guru ska kunna förstå vad du vill.

Det som enligt min mening verkligen saknas i språket, det som tvingar dig att skriva mer än du skulle kunna, är det som slösar tid som kunden betalar.

• Möjlighet att skriva på nivån, till exempel TypeScript (som ett resultat, mer utvecklade kodanalysverktyg i IDE, refactoring, färre offensiva jambs)
  Tillgänglighet av funktioner som förstklassiga objekt. Ett lite mer komplicerat koncept, men mängden typiska standardkod kan reduceras avsevärt. Elevens förståelse av koden, IMHO, skulle till och med öka på grund av volymminskningen
• Universell samling bokstaver, initialiserare. Samma sak - att minska mängden kod som behöver skrivas och/eller tittas på med dina ögon. Att fylla samlingar tar upp över 9000 % av 1C-programmeringstiden. Att skriva detta utan syntaktisk socker är långt, dyrt och felbenäget. Generellt sett överskrider mängden LOC i 1C-lösningar alla tänkbara gränser jämfört med tillgängliga öppna ramverk och i allmänhet alla dina företags Javas kombinerat. Språket är mångsidigt, och detta degenererar till mängden data, minne, IDE-bromsar, tid, pengar...
• äntligen konstruktioner Jag har en hypotes om att denna konstruktion saknas på grund av att de inte hittade en lyckad översättning av den till ryska :)
• Egna datatyper (utan OOP), analoger av Typ från VB6. Det kommer att tillåta dig att inte skriva strukturer med kommentarer i BSP och magiska metoder som konstruerar dessa strukturer. Vi får: mindre kod, en ledtråd genom en punkt, snabbare lösning på problemet, färre fel på grund av stavfel och saknade egenskaper hos strukturer. Nu vilar skrivningen av användarstrukturer helt och hållet på utvecklingsteamet för Standard Subsystem Library, som, till sin kredit, noggrant skriver kommentarer om de förväntade egenskaperna hos de passerade parameterstrukturerna.
• Inget socker när du arbetar med asynkrona samtal på webbklienten. callback-helvete i form av ProcessingNotifications är en tillfällig krycka orsakad av en plötslig förändring i API:et för huvudwebbläsarna, men du kan inte leva så här hela tiden; fördelen med "studenternas förståelse" av asynkron kod går förlorad mer och mer. Lägg till inget stöd för detta paradigm i huvud-IDE och saker blir ännu värre.

Detta är ett av de akuta problemen, det är tydligt att listan kan vara mycket större, men vi får inte glömma att detta fortfarande inte är ett allmänt språk, det kräver inte multithreading, lambda-funktioner, tillgång till GPU och snabb flyttalsberäkningar. Detta är ett skriptspråk för affärslogik.

En programmerare som redan har arbetat mycket med detta språk, tittar på js eller c#, blir uttråkad inom ramen för detta språk. Det är fakta. Han behöver utveckling. På den andra sidan av skalan för leverantören är kostnaden för att implementera de specificerade funktionerna kontra intäktsökningen efter implementeringen. Här har jag ingen information om vad som för närvarande väger tyngre i företagets ögon.

Utvecklingsmiljö

Det går inte smidigt här heller. Det finns två utvecklingsmiljöer. Den första är konfiguratorn som ingår i leveransen. Den andra är Enterprise Development Tools-miljön, eller EDT för kort, utvecklad på basis av Eclipse.

Konfiguratorn ger ett komplett utbud av utvecklingsuppgifter, stöder alla funktioner och är den huvudsakliga miljön på marknaden. Det är också moraliskt föråldrat, utvecklas inte, enligt rykten - på grund av mängden tekniska skulder inom sig. Situationen skulle kunna förbättras genom att öppna ett internt API (i form av vänskap med Snögubbe A. Orefkova eller på oberoende basis), men så är inte fallet. Praxis har visat att communityn kommer att skriva sina egna funktioner i IDE, så länge leverantören inte stör. Men vi har vad vi har. Konfiguratorn var jättebra 2004-2005, påminner väldigt mycket om dåtidens Visual Studio, på vissa ställen var den ännu coolare, men den satt fast på den tiden.

Dessutom har volymen av den genomsnittliga standardlösningen vuxit flera gånger sedan dess, och idag kan IDE helt enkelt inte klara av mängden kod som den matas med. Användbarhet och refaktoreringsförmåga är inte ens noll, de är i minus. Allt detta tillför inte entusiasm till utvecklarna och de drömmer om att flytta till andra ekosystem och fortsätta koda skit där, men i en trevlig miljö som inte spottar dig i ansiktet med sitt beteende.

Som ett alternativ erbjuds en IDE skriven från grunden, byggd på Eclipse. Där lever källorna, som i all annan programvara, i form av textfiler, lagras i GIT, pull request-grenar, allt detta. På nackdelen har det inte lämnat betastatus på många år nu, även om det blir bättre för varje release. Jag kommer inte att skriva om nackdelarna med EDT, idag är det ett minus, imorgon är det en fast funktion. Relevansen av en sådan beskrivning kommer snabbt att försvinna. Idag är det möjligt att utveckla i EDT, men det är ovanligt, man måste vara beredd på ett visst antal IDE-buggar.

Om du tittar på situationen genom det ovannämnda "1C-prismat", får du något i stil med detta: lanseringen av den nya IDE ökar inte försäljningen av lådor, men utflödet av UTVECKLARE kan minska. Det är svårt att säga vad som väntar på ekosystemet när det gäller utvecklarkomfort, men Microsoft har redan skruvat ihop mobilutvecklare genom att erbjuda dem sina tjänster för sent.

Utvecklingsledning

Allt här är betydligt bättre än att skriva kod, särskilt nyligen, när samhällets ansträngningar lyfte fram problemen med administrationsautomatisering, lanserade prototyper som uppmanade till att kasta 1C-förvaret i papperskorgen och använda git, quick blame, code-review , statisk analys, auto-deploy och etc. Många funktioner har lagts till plattformen som ökar nivån på automatisering av utvecklingsuppgifter. Men alla dessa funktioner lades till endast och exklusivt för utvecklingen av våra egna stora produkter, när det blev uppenbart att vi inte kunde klara oss utan automatisering. Det fanns automatiska sammanslagningar, trevägsjämförelser med KDiff och allt det där. Lanserades på Github gitconverter, som uppriktigt sagt drogs ideologiskt bort från projektet gitsync, men modifierad för att passa leverantörsföretagets processer. Tack vare de envisa killarna från öppen källkod kom utvecklingsautomatiseringen i 1C igång. Ett öppet API för konfiguratorn, IMHO, skulle också förskjuta den moraliska efterblivenheten hos huvud-IDE.

Idag, lagring av 1C-källor i git med commits kopplade till problem i Jira, recensioner i Crucible, tryckknapp från Jenkins och Allure rapporterar om kodtestning i 1C och till och med statisk analys i SonarQube – det här är långt ifrån nyheter, utan snarare mainstream i företag där det sker mycket 1C-utveckling.

administration

Det finns mycket att säga här. För det första är detta naturligtvis en server (1C-serverkluster). En underbar sak, men på grund av det faktum att det är en helt svart låda, dokumenterad tillräckligt detaljerat, men på ett specifikt sätt - att bemästra lanseringen av oavbruten drift i högbelastningsläge på flera servrar är lott för ett fåtal utvalda som bär en medalj med inskriptionen "Expert på tekniska frågor". Det är värt att notera att administrering av en 1C-server i princip inte skiljer sig från att administrera någon annan server. Det är ett nätverksbaserat, flertrådigt program som förbrukar minne, CPU och diskresurser. Ger stora möjligheter för telemetriinsamling och diagnostik.

Problemet här är att leverantören inte erbjuder något speciellt när det gäller färdiga lösningar för just denna diagnostik. Ja, det finns 1C: Instrumentation and Control Center, de är till och med ganska bra, men de är väldigt dyra och inte alla har dem. Det finns ett antal utvecklingar i samhället för att koppla ihop Grafana, Zabbix, ELK och andra saker från standardadminuppsättningen, men det finns ingen enskild lösning som passar majoriteten. Uppgiften väntar på dess hjälte. Och om du är ett företag som planerar att lansera på ett 1C-kluster behöver du en expert. Din egen insida eller från utsidan, men du behöver den. Det är normalt att det finns en separat roll med kompetens för serverdrift, inte alla 1C-användare borde veta detta, du behöver bara förstå att en sådan roll behövs. Låt oss ta SAP till exempel. Där kommer en programmerare med största sannolikhet inte ens resa sig från sin stol om han blir ombedd att konfigurera något på applikationsservern. Han kanske bara är dum och han kommer inte att skämmas. I SAP-metoden finns en separat medarbetarroll för detta. Av någon anledning tror man i 1C-branschen att detta bör kombineras i en anställd för samma lön. Det är en vanföreställning.

Nackdelar med 1C-server

Det finns exakt ett minus - tillförlitlighet. Eller, om du föredrar, oförutsägbarhet. Plötsligt konstigt beteende hos servern har redan blivit samtalsämne. Ett universellt botemedel - att stoppa servern och rensa alla cachar - beskrivs till och med i expertens handbok, och till och med en batchbok rekommenderas som gör detta. Om ditt 1C-system börjar göra något som det inte ens teoretiskt borde göra, är det dags att rensa sessionsdatacachen. Enligt min uppskattning finns det bara tre personer i hela landet som vet hur man driver en 1C-server utan denna procedur och de delar inga hemligheter, eftersom... de lever av detta. Kanske är deras hemlighet att de rensar sessionsdata, men de berättar inte för någon om det, dude.

Annars är 1C-servern samma applikation som alla andra och administreras på ungefär samma sätt, genom att läsa dokumentationen och knacka på tamburinen.

Hamnarbetare

Användbarheten av att använda en containeriserad 1C-server i produktionen har ännu inte bevisats. Servern är inte klustrad genom att helt enkelt lägga till noder bakom balanseraren, vilket reducerar fördelarna med produktionscontainerisering till ett minimum, och praxis för framgångsrik drift i containrar i höglastläge har inte etablerats. Som ett resultat är det bara utvecklare som använder Docker+1C för att ställa in testmiljöer. Där är det väldigt användbart, applicerat, låter dig leka med modern teknik och ta en paus från konfiguratorns förtvivlan.

Kommersiell komponent

Ur investeringssynpunkt låter 1C dig lösa problemet med att snabbt lansera affärsidéer på grund av applikationsklassernas breda kapacitet. 1C out of the box ger mycket bra Rapportering, integration med vad som helst, webbklient, mobilklient, mobilapplikation, stöd för olika DBMS, inkl. gratis, plattformsoberoende både server och installerade klientdelar. Ja, gränssnittet för applikationer kommer att vara gult, ibland är detta ett minus, men inte alltid.
Genom att välja 1C får ett företag en uppsättning mjukvarulösningar som gör att de kan bygga ett väldigt brett utbud av applikationer, samt många utvecklare på marknaden som vill ha mindre pengar än Javaister och samtidigt producera resultat snabbare.

Till exempel kan uppgiften att skicka en PDF-faktura till en kund lösas på en timmes elevarbete. Samma problem i .NET kan lösas genom att köpa ett eget bibliotek, eller ett par dagar eller veckors kodning av en sträng, skäggig utvecklare. Ibland, båda på en gång. Och ja, jag pratade bara om PDF-generering. Vi har inte sagt varifrån denna proposition ens kommer. Webfrontendern måste skapa ett formulär där operatören ska mata in data, backendern måste skapa dto-modeller för överföring av JSON, modeller för lagring i databasen, strukturen på själva databasen, migrering till den, bildandet av en grafisk visning av just detta konto, och först då - PDF. På 1C är hela uppgiften, från början, klar på exakt en timme.

Ett fullfjädrat bokföringssystem för ett litet stall med en affärsprocess köpt/såld görs på 3 timmar.Med försäljningsrapportering, redovisning av varor till köp- och försäljningspriser, uppdelat på lager, åtkomstkontroll, webbklient och mobilapplikation . Okej, jag glömde applikationen, med applikationen inte på 3 timmar, om sex.

Hur lång tid tar den här uppgiften en .NET-utvecklare från att installera Visual Studio på en ren dator till att demonstrera det för kunden? Hur är det med utvecklingskostnaderna? Samma sak.

Styrkan hos 1C som plattform

1C är stark inte för att det är något specifikt med det som är det bästa i världen. Tvärtom, i varje enskilt delsystem kan du hitta en mer intressant analog i världens mjukvara. Men baserat på en kombination av faktorer ser jag inte en plattform som liknar 1C. Det är här kommersiell framgång ligger. Fördelarna med plattformen är utspridda i den och syns tydligast när man ser hur detta går till i andra plattformar. I grund och botten är dessa INTE ens funktioner, utan tvärtom - ett förkastande av funktioner till förmån för ett specifikt paradigm. Några exempel:

1. Unicode. Vad fan kan vara enklare? Det finns inget behov av att använda enkelbyte ASCII-kodningar under 2019 (förutom för integration med gamla äldre). Aldrig. Men nej. Hur som helst, någon i någon tabell använder en enkelbyte varchar och applikationen kommer att ha problem med kodningar. 2015 misslyckades gitlabs LDAP-auktorisering på grund av felaktigt arbete med kodningar; JetBrains IDE fungerar fortfarande inte med kyrilliska i filnamn överallt. 1C ger högkvalitativ isolering av applikationskod från databaslagret. Där är det omöjligt att skriva tabeller på låg nivå och jambs av inkompetenta juniorer på databasnivå är omöjliga där. Ja, det kan finnas andra problem med inkompetenta juniorer, men variationen av problem är mycket mindre. Nu kommer du att berätta för mig att din applikation är korrekt designad och att databasåtkomstlagret är isolerat som det ska. Ta en ny titt på ditt företagsanpassade Java-program. Nära och ärligt. Stör ditt samvete dig? Då är jag glad för din skull.
2. Numrering av dokument/uppslagsböcker. I 1C är det definitivt inte det mest flexibla och inte det bästa. Men vad de gör i bankmjukvara och i självskrivna redovisningssystem - ja, det är bara mörker. Antingen kommer identiteten att fastna i (och sedan ”åh, varför har vi hål”), eller tvärtom kommer de att göra en generator som fungerar med låsning på DBMS-nivå (och kommer att bli en flaskhals). Faktum är att det är ganska svårt att göra denna till synes enkla uppgift - en end-to-end-uppräkning av enheter, med ett unikt avsnitt baserat på en viss uppsättning nycklar, prefix, så att den inte blockerar databasen under parallell datainmatning .
3. Identifierare av poster i databasen. 1C tog ett starkt beslut - alla länkidentifierare är absolut syntetiska och det är allt. Och det är inga problem med distribuerade databaser och utbyten. Utvecklare av andra system skapar envist något som identitet (den är kortare!), dra dem in i GUI tills det är dags att skapa flera relaterade instanser (och då kommer de att upptäckas). Har du inte det här? Ärligt?
4. Listor. 1C har ganska framgångsrika mekanismer för att bläddra igenom (stora) listor och navigera genom dem. Låt mig göra en reservation direkt - med korrekt användning av mekanismen! I allmänhet är ämnet ganska obehagligt, det kan inte lösas idealiskt: det är antingen intuitivt och enkelt (men risken för enorma postuppsättningar på klienten), eller så är sökningen av en eller annan snedhet. De som gör personsökning gör det ofta snett. De som gör en ärlig rullningslist lägger till en databas, en kanal och en klient.
5. Hanterade formulär. Utan tvekan, i webbklienten fungerar inte gränssnittet perfekt. Men det fungerar. Men för många andra redovisnings- och banksystem är det ett projekt på företagsnivå att skapa en fjärrarbetsplats. Friskrivningsklausul: lyckligtvis för dem som ursprungligen gjorde det på webben, kommer detta inte att påverka.
6. Mobil app. Nyligen kan du också skriva mobilapplikationer medan du är i samma ekosystem. Det är lite mer komplicerat här än med en webbklient; detaljerna för enheterna tvingar dig att skriva specifikt för dem, men ändå anställer du inte ett separat team av mobilutvecklare. Om du behöver en applikation för ett företags interna behov (när en mobil lösning på ett företagsproblem är viktigare än en gul UI-design) använder du helt enkelt samma plattform direkt.
7. Rapportering. Med detta ord menar jag inte ett BI-system med big data och en fördröjning på ETL-processen. Detta avser operativa personalrapporter som låter dig bedöma redovisningsläget här och nu. Saldon, inbördes avräkningar, omgradering m.m. 1C kommer ur lådan med ett rapporteringssystem med flexibla inställningar för grupperingar, filter och visualisering på användarsidan. Ja, det finns svalare analoger på marknaden. Men inte inom ramen för en allt-i-ett-lösning och till ett pris som ibland är högre än en allt-i-ett-lösning. Och oftare är det till och med tvärtom: bara rapportering, men dyrare än hela plattformen och sämre kvalitet.
8. Utskrivbara formulär. Jo, använd .NET för att lösa problemet med att skicka lönebesked i PDF till anställda via e-post. Och nu uppgiften att skriva ut fakturor. Vad sägs om att spara sina kopior till samma PDF? För 1C smeknamn, utmatning av valfri layout till PDF är +1 kodrad. Det innebär + 40 sekunders arbetstid, istället för dagar eller veckor på ett annat språk. Tryckta formulärlayouter i 1C är otroligt lätta att utveckla och tillräckligt kraftfulla för att konkurrera med betalda motsvarigheter. Ja, förmodligen, det finns inte många interaktiva möjligheter i 1C-kalkylbladsdokument; du kan inte snabbt få ett 3D-diagram med skalning med OpenGL. Men är det verkligen nödvändigt?

Det här är bara en handfull exempel där begränsning av funktionalitet eller implementering av kompromisser visar sig vara en viktig arkitektonisk fördel i framtiden. Även en kompromiss eller inte det mest effektiva alternativet - det är redan i lådan och tas för givet. Dess oberoende implementering kommer antingen att vara omöjlig (eftersom sådana beslut måste fattas i början av projektet, och det finns ingen tid för det, och det finns ingen arkitekt alls), eller flera dyra iterationer. I var och en av de listade punkterna (och detta är inte en komplett lista över arkitektoniska lösningar) kan du skruva på och införa restriktioner som blockerar skalning. I vilket fall som helst måste du, som affärsman, se till att dina programmerare, när de gör ett "system från grunden", har raka händer och kommer att göra subtila systemproblem direkt.

Ja, som i alla andra komplexa system har 1C självt också lösningar som blockerar skalning i vissa aspekter. Men jag upprepar, baserat på en kombination av faktorer, ägandekostnaden och antalet problem som redan är lösta i förväg, ser jag inte en värdig konkurrent på marknaden. För samma pris får du ett ekonomiskt applikationsramverk, en klustrad balanserad server, med UI och webbgränssnitt, med en mobilapplikation, med rapportering, integration och en massa annat. I Java-världen anställer du ett front-end- och back-end-team, felsöker lågnivåstim av hemskriven serverkod och betalar separat för 2 mobilapplikationer för 2 mobila operativsystem.

Jag säger inte att 1C kommer att lösa alla fall, men för en intern företagsapplikation, när det inte finns något behov av att branda användargränssnittet - vad mer behövs?

Hake

Du fick förmodligen intrycket att 1C kommer att rädda världen och att alla andra sätt att skriva företagssystem är fel. Det är inte alls så. Ur en affärsmans synvinkel, om du väljer 1C, måste du, förutom snabb time-to-market, ta hänsyn till följande nackdelar:

• Serverns tillförlitlighet. Verkligen högkvalitativa specialister krävs som kan säkerställa dess oavbrutna drift. Jag känner inte till ett färdigt utbildningsprogram för sådana specialister från leverantören. Det finns kurser att förbereda inför Expertprovet, men detta räcker enligt mig inte.
• Stöd. Se föregående punkt. För att få support från leverantören måste du köpa den. Av någon anledning är detta inte accepterat i 1C-branschen. Och med SAP är det nästan ett måste att köpa och det stör ingen. Utan företagsstöd och utan en expert på personal kan du lämnas ensam med 1C-fel.
• Ändå kan du inte göra absolut allt med 1C. Detta är ett verktyg och som alla verktyg har det gränser för tillämpbarhet. I 1C-landskapet är det mycket önskvärt att ha en "icke-1C" systemarkitekt.
• Bra 1C smeknamn är inte billigare än bra programmerare på andra språk. Fast dåliga programmerare är dyra att anställa, oavsett vilket språk de skriver på.

Låt oss pricka prickarna

• 1C är ett ramverk för snabb applikationsutveckling (RAD) för företag och är skräddarsytt för detta.
• Tredelad länk med stöd för större DBMS, klientgränssnitt, en mycket bra ORM och rapportering
• Stora möjligheter till integration med system som klarar det 1C inte kan. Om du vill ha maskininlärning, ta Python och skicka resultatet till 1C via http eller RabbitMQ
• Du behöver inte sträva efter att göra allt med 1C, du måste förstå dess styrkor och använda dem för dina egna syften
• Utvecklare som drar sig mot att gräva i tekniska ramverk och designa om vart N:e år till en ny motor är uttråkade med 1C. Allt är väldigt konservativt där.
• Utvecklare är också uttråkade eftersom det finns väldigt lite oro för dem från tillverkaren. Tråkigt språk, svag IDE. De kräver modernisering.
• Å andra sidan är utvecklare som inte kan hitta kul genom att använda och lära sig en annan teknik som de gillar dåliga utvecklare. De kommer att gnälla och flytta till ett annat ekosystem.
• Arbetsgivare som inte tillåter sina 1C smeknamn att skriva något i Python är dåliga arbetsgivare. De kommer att förlora anställda med nyfikna sinnen, och i deras ställe kommer apkodare som, samtidigt som de håller med om allt, kommer att dra in företagets mjukvara i träsket. Det kommer fortfarande att behöva skrivas om, så det kanske vore bättre att investera lite i Python lite tidigare?
• 1C är ett kommersiellt företag och implementerar funktioner enbart baserat på sina egna intressen och ändamålsenlighet. Du kan inte klandra henne för detta, företag måste tänka på vinst, sånt är livet
• 1C tjänar pengar på att sälja lösningar på affärsproblem, inte på Vasyas utvecklarproblem. Dessa två begrepp korrelerar, men prioriteringen är precis vad jag sa. När utvecklaren Vasya är redo att betala för en personlig licens för 1C: Resharper kommer det att dyka upp ganska snabbt, "Resharper" av A. Orefkova är ett bevis på detta. Om leverantören stödde det, och inte kämpade emot det, skulle en marknad för mjukvara för utvecklare uppstå. Nu finns det en och en halv spelare på denna marknad med tveksamma resultat, och allt för att integrationen med IDE är negativ och allt sker på kryckor.
• Praktiken med en multimaskinsoperatör kommer att försvinna i glömska. Moderna applikationer är för stora för att komma ihåg både från kodsidan och från affärsanvändningssidan. 1C-servern blir också mer komplex, det kommer att vara omöjligt att hålla alla typer av expertis i en anställd. Detta bör medföra en efterfrågan på specialister, vilket innebär attraktionskraften för 1C-yrket och en ökning av lönerna. Om Vasya tidigare arbetade tre-i-ett för en lön, måste du nu anställa två Vasyas och konkurrens mellan Vasyas kan stimulera den totala tillväxten av deras nivå.

Slutsats

1C är en mycket värdig produkt. I min prisklass känner jag inte till några analoger alls, skriv i kommentarerna om det finns några. Utflödet av utvecklare från ekosystemet blir dock mer och mer märkbart, och detta är en "kompetensflykt", oavsett hur man ser på det. Branschen är sugen på modernisering.
Om du är en utvecklare, häng inte upp dig på 1C och tro inte att allt är magiskt på andra språk. Medan du är junior, kanske. Så fort något större behöver lösas kommer färdiga lösningar att behöva letas längre och färdigställas mer intensivt. När det gäller kvaliteten på "blocken" från vilka en lösning kan byggas är 1C väldigt, väldigt bra.

Och en sak till - om ett 1C smeknamn kommer till dig för att anställa, då kan 1C smeknamnet säkert utses till positionen som ledande analytiker. Deras förståelse för uppgiften, ämnesområdet och nedbrytningsförmågan är utmärkt. Jag är säker på att detta är just på grund av den påtvingade användningen av DDD i 1C-utveckling. Personen är tränad att tänka på meningen med uppgiften först och främst, på kopplingarna mellan objekt inom ämnesområdet, och har samtidigt en teknisk bakgrund inom integrationsteknologier och format för datautbyte.

Var medveten om att den ideala ramen inte finns och ta hand om dig själv.
Med vänliga hälsningar!

PS: tack så mycket speshurisk för hjälp med att förbereda artikeln.

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Har du 1C i ditt företag?

• 13,3%Inte alls.71

• 30,3%Det finns, men bara på redovisningsavdelningen någonstans. Kärnsystem på andra plattformar162

• 41,4%Ja, de huvudsakliga affärsprocesserna fungerar på it221

• 15,0%1C måste dö, framtiden tillhör %technology_name%80

534 användare röstade. 99 användare avstod från att rösta.

Källa: will.com