1C – Il bene e il male. Disposizione dei punti negli holivar intorno al 1° sec

Amici e colleghi, ultimamente sono stati più frequenti gli articoli su Habré che incitano all'odio verso 1C come piattaforma di sviluppo, e i discorsi dei suoi difensori. Questi articoli hanno identificato un problema serio: molto spesso i critici di 1C lo criticano dalla posizione di "non padroneggiarlo", rimproverando problemi che di fatto sono facilmente risolvibili e, al contrario, non toccando problemi che sono veramente importanti, vale la pena discutere e non vengono risolti dal venditore. Credo che abbia senso condurre una revisione sobria ed equilibrata della piattaforma 1C. Cosa può fare, cosa non può fare, cosa dovrebbe fare ma non fa e, per dessert, cosa fa con il botto, e i tuoi sviluppatori di %technology_name% faranno cento anni, buttandolo via più di un budget annuale.

Di conseguenza, tu, come manager o architetto, sarai in grado di comprendere chiaramente quale compito sarà vantaggioso per te utilizzare 1C e dove deve essere bruciato con un ferro caldo. Come sviluppatore nel mondo "non 1C", sarai in grado di vedere cosa c'è in 1C che sta causando confusione. E come sviluppatore 1C, sarai in grado di confrontare il tuo sistema con gli ecosistemi di altre lingue e comprendere la tua posizione nel sistema di coordinate dello sviluppo del software.

Sotto il taglio ci sono un sacco di grossi attacchi a 1C, ai critici di 1C, a Java, .NET e in generale... Il fan è pieno, benvenuto!

Informazioni su di me

Conosco l'argomento della conversazione dal 2004 circa. Programmatore probabilmente da quando avevo 6 anni, dal momento in cui ho ricevuto un libro sul professor Fortran con fumetti su un gatto, un passero e un bruco. Ho analizzato i programmi scritti dal gatto dalle immagini del libro e ho scoperto cosa facevano. E sì, all’epoca non avevo un vero computer, ma c’era un disegno sulla copertina del libro e onestamente ho premuto i pulsanti di carta, inserendo i comandi che avevo spiato sul gatto X.

Poi c’erano BK0011 e BASIC a scuola, C++ e assemblatori all’università, poi 1C, e poi tante altre cose che sono troppo pigro per ricordare. Negli ultimi 15 anni mi sono occupato principalmente di 1C, non solo in termini di codifica, ma di 1C in generale. Impostazione attività, amministrazione e devops qui. Negli ultimi 5 anni mi sono impegnato in attività socialmente utili in termini di sviluppo di strumenti di sviluppo e automazione per altri utenti 1C, scrivendo articoli e libri.

Decidiamo l'argomento della discussione

Per prima cosa definiamo di cosa parleremo, poiché le lettere “1C” possono significare molte cose. In questo caso, con le lettere "1C" intendiamo esclusivamente il framework di sviluppo "1C: Enterprise" della moderna ottava versione. Non parleremo molto del produttore e delle sue politiche (ma qualcosa dovremo fare) e non discuteremo di applicazioni specifiche scritte utilizzando questo framework. La tecnologia è separata, le applicazioni, ovvero le configurazioni, sono separate.

Architettura di alto livello 1C: Enterprise

Non per niente menziono la parola “quadro”. Dal punto di vista dello sviluppatore, la piattaforma 1C è precisamente un framework. E devi trattarlo esattamente come un quadro. Pensalo come Spring o ASP.NET, eseguito da qualche runtime (rispettivamente JVM o CLR). Si dà il caso che nel mondo della programmazione convenzionale (“non 1C”) la divisione in framework, macchine virtuali e applicazioni specifiche sia naturale, poiché questi componenti sono solitamente sviluppati da produttori diversi. Nel mondo 1C non è consuetudine distinguere esplicitamente tra framework di sviluppo e runtime stesso; inoltre, anche applicazioni specifiche scritte utilizzando il framework vengono sviluppate principalmente da 1C stesso. Di conseguenza, sorge una certa confusione. Pertanto, nell'ambito dell'articolo, dovremo considerare 1C da più lati contemporaneamente e classificarlo lungo diversi assi coordinati. E in ciascun asse delle coordinate metteremo una pala di sostanza marrone e esamineremo le caratteristiche, i vantaggi e gli svantaggi della soluzione esistente.

Punti di vista su 1C

1C per l'acquirente

L'acquirente acquista un sistema di automazione con il quale può risolvere rapidamente i problemi di automatizzazione della propria attività. Un'azienda può essere una piccola bancarella o una grande holding. È chiaro che le esigenze di queste aziende sono diverse, ma entrambe sono supportate da un'unica piattaforma di codice base.

Per l'acquirente 1C si tratta di un rapido time-to-market. Veloce. Più veloce di Java, C# o JS. Media. Intorno all'ospedale. È chiaro che un sito Web per biglietti da visita che utilizza React risulterà migliore, ma il backend di un sistema WMS verrà avviato più velocemente su 1C.

1C come strumento

Ogni soluzione tecnologica ha dei limiti di applicabilità. 1C non è un linguaggio di uso generale; non vive separatamente dalla sua struttura. Si consiglia di utilizzare 1C quando è necessario:

• applicazione server
• applicazione in cui appaiono le finanze
• con interfaccia utente già pronta, ORM, reporting, XML/JSON/COM/PDF/YourDataTransferingFormat
• con supporto per processi e lavori in background
• con sicurezza basata sui ruoli
• con logica aziendale scriptabile
• con la capacità di creare rapidamente un prototipo e un ridotto time-to-market

Non hai bisogno di 1C se vuoi:

• apprendimento automatico
• Calcoli GPU
• computer grafica
• calcoli matematici
• Sistema CAD
• elaborazione del segnale (suono, video)
• chiamate http ad alto carico con centinaia di migliaia di rps

1C come azienda manifatturiera

Vale la pena capire qual è l'attività di 1C come produttore di software. L'azienda 1C vende soluzioni ai problemi aziendali attraverso l'automazione. Aziende diverse, grandi o piccole, ma è quello che vende. I mezzi per raggiungere questo obiettivo sono le applicazioni aziendali. Per contabilità, contabilità salariale, ecc. Per scrivere queste applicazioni, l'azienda utilizza la propria piattaforma di sviluppo di applicazioni aziendali. Appositamente studiato per le attività comuni di queste stesse applicazioni aziendali:

• contabilità finanziaria
• facile personalizzazione della logica aziendale
• ampie possibilità di integrazione in ambienti IT eterogenei

Come produttore, 1C ritiene che questa sia la strategia che consente di lavorare con partner e clienti in una modalità vantaggiosa per tutti. Puoi discuterne, ma è più o meno così che l'azienda si promuove: soluzioni già pronte ai problemi aziendali che possono essere rapidamente personalizzate dai partner e integrate in qualsiasi panorama IT.

Tutte le affermazioni o i desideri per 1C come quadro dovrebbero essere visti esclusivamente attraverso questo prisma. "Vogliamo l'OOP in 1C", affermano gli sviluppatori. "Quanto ci costerà supportare l'OOP nella piattaforma, questo ci aiuterà ad aumentare le vendite di scatole?" dice 1C. Apre il suo "prisma" di vendita di soluzioni ai problemi aziendali:

- Ehi, affari, vuoi l'OOP nel tuo 1C?
- Questo mi aiuterà a risolvere i miei problemi?
- Chi lo sa...
- Allora non ce n'è bisogno

Questo approccio può essere positivo o negativo a seconda di chi lo guarda, ma è proprio così. Parlando del fatto che non esiste una funzionalità X in 1C, è necessario comprendere che non è presente per un motivo, ma nel contesto della scelta "costo di implementazione rispetto all'importo del profitto".

Classificazione tecnologica

“In effetti, gli Odinesnik fanno del loro meglio per utilizzare i migliori modelli, accuratamente selezionati da premurosi metodologi e sviluppatori della piattaforma 1C.
Quando scrivi il tuo stupido codice per un semplice modulo gestito, in realtà lo stai utilizzando controller-vista-modello с associazione dati a doppio senso в motore di app dati a tre livelli, aromatizzato mappatura delle relazioni tra oggetti di alto livello sulla base di descrizione dichiarativa dei metadatiavendo il proprio linguaggio di query indipendente dalla piattaforma, C interfaccia utente dichiarativa basata sui dati, serializzazione completa e trasparente e linguaggio di programmazione orientato al dominio.

Il punto in cui gli sviluppatori 1C differiscono dai loro colleghi occidentali è nelle PR. Amano dare un nome importante a qualsiasi stronzata e portarla in giro come un sacco sporco.
A. Orefkov

La piattaforma 1C ha una classica architettura a 3 livelli, al centro della quale si trova il server delle applicazioni (o la sua emulazione a poco prezzo per i piccoli negozianti). Come DBMS viene utilizzato MS SQL o Postgres. C'è anche il supporto per Oracle e IBM DB2, ma questo è piuttosto esoterico; nessuno sa cosa accadrà se implementi 1C su questi database con carico medio e alto. Credo che la stessa 1C non lo sappia.

La parte client è un thin client installato sulla macchina dell'utente o un client Web. La caratteristica fondamentale è che i programmatori non scrivono 2 codici diversi, scrivono un'applicazione, in una lingua, e puoi visualizzarla nel browser se ce n'è un desiderio o una necessità. Chi voleva un vero stack completo e un unico linguaggio per il front-end e il back-end, node.js? Non sono mai riusciti a fare esattamente la stessa cosa fino alla fine. Esiste un vero stack completo, ma dovrai scriverlo in 1C. L'ironia del destino, queste cose :)

La soluzione cloud SaaS 1C:Fresh funziona anche in modalità browser, in cui non è possibile acquistare 1C, ma noleggiare un piccolo database e tenere traccia delle vendite di shawarma lì. Solo nel browser, senza installare o configurare nulla.

Inoltre, esiste un client legacy, che in 1C è chiamato "applicazione regolare". L'eredità è eredità, benvenuto nel mondo delle applicazioni nel 2002, ma stiamo ancora parlando dello stato attuale dell'ecosistema.

La parte server 1C supporta il clustering e la scalabilità aggiungendo nuove macchine al cluster. Molte copie sono state rotte qui e ci sarà una sezione separata nell'articolo a riguardo. In breve, questo non equivale ad aggiungere un paio di istanze esattamente identiche dietro HAProxy.

Il framework di sviluppo dell'applicazione utilizza il proprio linguaggio di programmazione, che assomiglia più o meno a VB6 leggermente migliorato tradotto in russo. Per le persone che odiano tutto ciò che è russo, che non credono che "se" sia tradotto come "se", viene offerta la seconda opzione di sintassi. Quelli. Se lo desideri, puoi scriverlo in 1C in modo che sia indistinguibile da VB.

Proprio questo linguaggio di programmazione è la ragione principale dell'odio dei soprannomi 1C nei confronti della loro piattaforma. Diciamolo chiaro, non senza motivo. Il linguaggio è stato concepito nel modo più semplice possibile, progettato per soddisfare il mantra "SVILUPPATORI, SVILUPPATORI" su scala almeno nella CSI. L'essenza commerciale di una soluzione del genere, a mio avviso, è chiaramente visibile: più sviluppatori, maggiore copertura del mercato. Ciò si è verificato, secondo varie stime, dal 45% al ​​95%. Dico subito che scrivere nella lingua che ritieni sia davvero più semplice. E conosco parecchi linguaggi di programmazione.

Cominciamo con la lingua.

Linguaggio di programmazione 1C

Allo stesso tempo il punto forte e debole del sistema. Fornisce un facile accesso e leggibilità. D'altra parte non è stato aggiornato dal rilascio della versione 8 nel 2002 ed è moralmente obsoleto. Qualcuno dirà “lo svantaggio principale è che non esiste OOP” e si sbaglierà. In primo luogo, all'OLP non piace non solo Nuraliev, ma anche Torvalds. E in secondo luogo, l'OOP esiste ancora.

Dal punto di vista dello sviluppatore, ha a disposizione un framework con classi base visualizzate sul DBMS. Lo sviluppatore può prendere la classe base “Directory” ed ereditare da essa la directory “Clients”. Può aggiungere nuovi campi di classe, ad esempio INN e Indirizzo, e anche, se necessario, può sovrascrivere (override) i metodi della classe base, ad esempio il metodo OnWrite/AtRecord.

Il framework è progettato in modo tale che raramente sia necessaria un'eredità più profonda e la restrizione nell'OOP, a mio avviso, ha senso. 1C si concentra sul Domain Driven Development e ti fa pensare, prima di tutto, all'argomento della soluzione in fase di sviluppo, e questo è positivo. Non solo non c'è alcuna tentazione, ma non c'è nemmeno bisogno di scrivere 10 DTO e ViewModel diversi solo per mostrare alcuni dati dal dominio da qualche parte. Lo sviluppatore 1C opera sempre con un'entità, senza ingombrare il contesto della percezione con una dozzina di classi con nomi simili, che rappresentano la stessa entità, ma da un lato diverso. Qualsiasi applicazione .NET, ad esempio, conterrà necessariamente cinque o due ViewModel e DTO per la serializzazione in JSON e il trasferimento dei dati dal client al server. E circa il 10-15% del codice dell'applicazione verrà speso per trasferire i dati da una classe all'altra utilizzando penne o stampelle come AutoMapper. Questo codice deve essere scritto e i programmatori devono essere pagati per crearlo e mantenerlo.

Si scopre che il linguaggio 1C è difficile da sviluppare senza complicarlo al livello dei linguaggi tradizionali, perdendo così il vantaggio della semplicità. Qual è il compito del venditore che viene essenzialmente risolto: fornire una soluzione standard che qualsiasi studente sorpreso per strada possa personalizzare con il livello di qualità richiesto (ad esempio, viene completata una custodia che copre da una bancarella a una grande fabbrica). Se sei una bancarella, prendi uno studente; se sei una fabbrica, prendi un guru dal tuo partner di implementazione. Il fatto che i partner attuativi vendano studenti al prezzo di un guru non è un problema con il quadro. Dal punto di vista architettonico, il framework deve risolvere i problemi di entrambi, il codice delle configurazioni standard (che abbiamo venduto alle aziende con la promessa di personalizzazione) dovrebbe essere in grado di essere compreso da uno studente e un guru dovrebbe essere in grado di capire qualunque cosa tu voglia.

Ciò che secondo me manca davvero nella lingua, ciò che ti costringe a scrivere più di quanto potresti, è la perdita di tempo pagata dal cliente.

• Possibilità di digitare a livello, ad esempio, TypeScript (di conseguenza, strumenti di analisi del codice più sviluppati nell'IDE, refactoring, meno stipiti offensivi)
  Disponibilità di funzioni come oggetti di prima classe. Un concetto leggermente più complesso, ma la quantità di codice tipico potrebbe essere notevolmente ridotta. La comprensione del codice da parte dello studente, IMHO, aumenterebbe addirittura a causa della riduzione del volume
• Letterali di raccolta universali, inizializzatori. La stessa cosa: ridurre la quantità di codice che deve essere scritto e/o guardato con i tuoi occhi. Il riempimento delle raccolte richiede oltre il 9000% del tempo di programmazione 1C. Scriverlo senza zucchero sintattico è lungo, costoso e soggetto a errori. In generale, la quantità di LOC nelle soluzioni 1C supera tutti i limiti immaginabili rispetto ai framework aperti disponibili e, in generale, a tutti i Java aziendali messi insieme. Il linguaggio è prolisso e questo degenera nella quantità di dati, memoria, freni IDE, tempo, denaro...
• infine costruzioni, ho l'ipotesi che questa costruzione manchi a causa del fatto che non ne hanno trovata una traduzione riuscita in russo :)
• Tipi di dati propri (senza OOP), analoghi al tipo di VB6. Ti consentirà di non digitare strutture utilizzando commenti nel BSP e metodi magici che costruiscono queste strutture. Otteniamo: meno codice, un suggerimento tramite un punto, una soluzione più rapida al problema, meno errori dovuti a errori di battitura e proprietà mancanti delle strutture. Ora la digitazione delle strutture utente spetta interamente al team di sviluppo della Standard Subsystem Library, che, a suo merito, scrive attentamente commenti sulle proprietà attese delle strutture dei parametri passate.
• Niente zucchero quando si lavora con chiamate asincrone sul client web. il callback-hell sotto forma di ProcessingNotifications è una stampella temporanea causata da un improvviso cambiamento nelle API dei principali browser, ma non si può vivere sempre così; si sta perdendo il vantaggio della “comprensione da parte degli studenti” del codice asincrono sempre più. Se non aggiungi alcun supporto per questo paradigma nell'IDE principale, le cose peggioreranno ulteriormente.

Questo è uno dei problemi più urgenti, è chiaro che l'elenco potrebbe essere molto più lungo, ma non bisogna dimenticare che non si tratta ancora di un linguaggio generico, non richiede multithreading, funzioni lambda, accesso alla GPU e velocità calcoli in virgola mobile. Questo è un linguaggio di scripting della logica aziendale.

Un programmatore che ha già lavorato molto con questo linguaggio, esamina js o c#, si annoia nell'ambito di questo linguaggio. È un fatto. Ha bisogno di sviluppo. Dall'altro lato della bilancia per il fornitore c'è il costo di implementazione delle funzionalità specificate rispetto all'aumento delle entrate dopo la loro implementazione. Qui non ho alcuna informazione su ciò che attualmente prevale agli occhi dell'azienda.

Sviluppo dell'ambiente

Anche qui le cose non stanno andando bene. Esistono due ambienti di sviluppo. Il primo è il Configuratore incluso nella consegna. Il secondo è l'ambiente Enterprise Development Tools, o EDT in breve, sviluppato sulla base di Eclipse.

Il configuratore fornisce una gamma completa di attività di sviluppo, supporta tutte le funzionalità ed è l'ambiente principale sul mercato. È anche moralmente obsoleto, non in via di sviluppo, secondo le indiscrezioni, a causa dell'ammontare del debito tecnico al suo interno. La situazione potrebbe essere migliorata aprendo un'API interna (sotto forma di amicizia con Pupazzo di neve A. Orefkova o su base indipendente), ma non è così. La pratica ha dimostrato che la comunità scriverà le proprie funzionalità nell'IDE, purché il fornitore non interferisca. Ma abbiamo quello che abbiamo. Il configuratore era fantastico nel 2004-2005, ricordava molto Visual Studio di quei tempi, in alcuni punti era ancora più bello, ma era bloccato a quei tempi.

Inoltre, da allora il volume della soluzione standard media è cresciuto più volte e oggi l'IDE semplicemente non riesce a far fronte alla quantità di codice con cui viene alimentato. L'usabilità e le capacità di refactoring non sono nemmeno pari a zero, sono in rosso. Tutto ciò non aggiunge entusiasmo agli sviluppatori e sognano di trasferirsi in altri ecosistemi e continuare a scrivere codice lì, ma in un ambiente piacevole che non ti sputi in faccia con il suo comportamento.

In alternativa viene offerto un IDE scritto da zero, costruito su Eclipse. Lì, i sorgenti, come in qualsiasi altro software, vivono sotto forma di file di testo, sono archiviati in GIT, pull request branch, tutto questo. L’aspetto negativo è che non ha lasciato lo stato beta ormai da molti anni, anche se sta migliorando ad ogni versione. Non scriverò sugli svantaggi dell'EDT, oggi è un aspetto negativo, domani è una caratteristica fissa. La rilevanza di una tale descrizione svanirà rapidamente. Oggi è possibile sviluppare in EDT, ma è insolito: bisogna essere preparati a un certo numero di bug dell'IDE.

Se guardi la situazione attraverso il già citato "prisma 1C", ottieni qualcosa del genere: il rilascio del nuovo IDE non aumenta le vendite di box, ma il deflusso di SVILUPPATORI potrebbe essere ridotto. È difficile dire cosa attende l’ecosistema in termini di comfort per gli sviluppatori, ma Microsoft ha già rovinato gli sviluppatori mobili offrendo loro i suoi servizi troppo tardi.

Gestione dello sviluppo

Tutto qui è significativamente migliore che nella scrittura del codice, soprattutto di recente, quando gli sforzi della comunità hanno portato alla luce i problemi dell'automazione dell'amministrazione, hanno lanciato prototipi che richiedevano di gettare il repository 1C nella spazzatura e di utilizzare git, quick colpa, revisione del codice , analisi statica, distribuzione automatica e così via. Alla piattaforma sono state aggiunte molte funzionalità che aumentano il livello di automazione delle attività di sviluppo. Tutte queste funzionalità però sono state aggiunte solo ed esclusivamente per lo sviluppo dei nostri prodotti di grandi dimensioni, quando è diventato evidente che non potevamo fare a meno dell’automazione. C'erano unioni automatiche, confronti a tre con KDiff e tutto il resto. Lanciato su Github gitconverter, che, francamente, è stato ideologicamente trascinato lontano dal progetto gitsync, ma modificato per adattarsi ai processi dell'azienda fornitrice. Grazie ai ragazzi testardi dell'open source, l'automazione dello sviluppo in 1C è decollata. Un'API aperta per il configuratore, IMHO, sposterebbe anche l'arretratezza morale dell'IDE principale.

Oggi, archiviando sorgenti 1C in Git con commit collegati a problemi in Jira, recensioni in Crucible, pulsanti di Jenkins e rapporti Allure sui test del codice in 1C e persino analisi statica in SonarQube - questa è tutt'altro che una novità, ma piuttosto il mainstream nelle aziende in cui c'è molto sviluppo 1C.

amministrazione

C'è molto da dire qui. Innanzitutto, questo è, ovviamente, un server (cluster di server 1C). Una cosa meravigliosa, ma poiché si tratta di una scatola completamente nera, documentata in modo sufficientemente dettagliato, ma in modo specifico: padroneggiare l'avvio di un funzionamento ininterrotto in modalità highload su più server è compito di pochi eletti che indossano un medaglia con la scritta “Esperto in questioni tecnologiche”. Vale la pena notare che, in linea di principio, amministrare un server 1C non è diverso dall'amministrare qualsiasi altro server. È un'applicazione multi-thread basata sulla rete che consuma memoria, CPU e risorse del disco. Fornisce ampie opportunità per la raccolta e la diagnostica della telemetria.

Il problema qui è che il venditore non offre nulla di speciale in termini di soluzioni già pronte proprio per questa diagnostica. Sì, c'è 1C: Instrumentation and Control Center, sono anche abbastanza buoni, ma sono molto costosi e non tutti li hanno. Ci sono una serie di sviluppi nella comunità per connettere Grafana, Zabbix, ELK e altre cose dal set di amministrazione standard, ma non esiste un'unica soluzione adatta alla maggioranza. Il compito attende il suo eroe. E se sei un'azienda che prevede di avviarsi su un cluster 1C, hai bisogno di un esperto. Il tuo dentro o fuori, ma ne hai bisogno. È normale che esista un ruolo separato con competenze per il funzionamento del server, non tutti gli utenti 1C dovrebbero saperlo, devi solo capire che tale ruolo è necessario. Prendiamo ad esempio SAP. Lì, il programmatore, molto probabilmente, non si alzerà nemmeno dalla sedia se gli viene chiesto di configurare qualcosa sul server delle applicazioni. Potrebbe essere semplicemente stupido e non si vergognerà. Nella metodologia SAP esiste un ruolo dipendente separato per questo. Per qualche ragione, nel settore 1C, si ritiene che ciò debba essere combinato in un dipendente per lo stesso stipendio. È un'illusione.

Svantaggi del server 1C

C'è esattamente un aspetto negativo: l'affidabilità. O, se preferisci, imprevedibilità. Lo strano comportamento improvviso del server è già diventato oggetto di discussione in città. Un rimedio universale - arrestare il server e svuotare tutte le cache - è descritto anche nel manuale dell'esperto, e si consiglia anche un batch book che faccia questo. Se il tuo sistema 1C inizia a fare qualcosa che non dovrebbe nemmeno fare teoricamente, è tempo di svuotare la cache dei dati della sessione. Secondo la mia stima, ci sono solo tre persone in tutto il paese che sanno come far funzionare un server 1C senza questa procedura e non condividono segreti, perché... vivono di questo. Forse il loro segreto è che puliscono i dati della sessione, ma non ne parlano a nessuno, amico.

Per il resto, il server 1C è un'applicazione uguale a qualsiasi altra e viene amministrato più o meno allo stesso modo, leggendo la documentazione e bussando al tamburello.

docker

L'utilità dell'utilizzo di un server 1C containerizzato in produzione non è stata ancora dimostrata. Il server non viene raggruppato semplicemente aggiungendo nodi dietro il bilanciatore, il che riduce al minimo i vantaggi della containerizzazione della produzione e non è stata stabilita la pratica di un funzionamento riuscito in contenitori in modalità carico elevato. Di conseguenza, solo gli sviluppatori utilizzano Docker+1C per configurare ambienti di test. Lì è molto utile, applicato, ti permette di giocare con le tecnologie moderne e di prenderti una pausa dallo sconforto del configuratore.

Componente commerciale

Dal punto di vista degli investimenti, 1C consente di risolvere il problema del lancio rapido di idee di business grazie alle ampie capacità delle classi applicative. 1C pronto all'uso offre reporting molto decente, integrazione con qualsiasi cosa, client Web, client mobile, applicazione mobile, supporto per vari DBMS, incl. gratuito, multipiattaforma sia server che parti client installate. Sì, l'interfaccia utente delle applicazioni sarà gialla, a volte questo è un aspetto negativo, ma non sempre.
Scegliendo 1C, un'azienda ottiene una serie di soluzioni software che consentono loro di creare una gamma molto ampia di applicazioni, così come molti sviluppatori sul mercato che vogliono meno soldi rispetto ai Javaisti e allo stesso tempo producono risultati più velocemente.

Ad esempio, il compito di inviare una fattura in PDF a un cliente può essere risolto in un'ora di lavoro da parte dello studente. Lo stesso problema in .NET può essere risolto acquistando una libreria proprietaria o un paio di giorni o settimane di codifica da parte di uno sviluppatore severo e barbuto. A volte, entrambi contemporaneamente. E sì, stavo solo parlando della generazione di PDF. Non abbiamo nemmeno detto da dove verrà questa fattura. Il frontender web dovrà creare un form dove l'operatore inserirà i dati, il backender dovrà creare modelli dto per il trasferimento JSON, modelli per l'archiviazione nel database, la struttura del database stesso, la migrazione ad esso, la formazione di un grafico visualizzazione di questo stesso account e solo allora - PDF. Su 1C, l'intera attività, da zero, viene completata esattamente in un'ora.

In 3 ore viene realizzato un sistema contabile completo per una piccola bancarella con un processo commerciale di acquisto/vendita, con reporting delle vendite, contabilità delle merci ai prezzi di acquisto e di vendita, suddivise per magazzino, controllo dei diritti di accesso, client web e applicazione mobile . Ok, mi ero dimenticato della domanda, con la domanda non in 3 ore, in sei.

Quanto tempo impiegherà uno sviluppatore .NET a eseguire questa attività dall'installazione di Visual Studio su un computer pulito alla dimostrazione al cliente? E il costo dello sviluppo? Stessa cosa.

Punti di forza di 1C come piattaforma

1C è forte non perché ci sia qualcosa di specifico che lo rende il migliore al mondo. Al contrario, in ogni singolo sottosistema puoi trovare un analogo più interessante nel software mondiale. Tuttavia, per una combinazione di fattori, non vedo una piattaforma simile a 1C. È qui che risiede il successo commerciale. I vantaggi della piattaforma sono sparsi ovunque e sono più chiaramente visibili quando vedi come viene fatto su altre piattaforme. Fondamentalmente, queste NON sono nemmeno caratteristiche, ma al contrario: un rifiuto delle caratteristiche a favore di un paradigma specifico. Alcuni esempi:

1. Unicode. Cosa diavolo potrebbe essere più semplice? Nel 2019 non è necessario utilizzare codifiche ASCII a byte singolo (ad eccezione dell'integrazione con quelle legacy antiche). Mai. Ma no. Ad ogni modo, qualcuno in qualche tabella utilizza un varchar a byte singolo e l'applicazione avrà problemi con le codifiche. Nel 2015, l'autorizzazione LDAP di gitlab è fallita a causa di un lavoro errato con le codifiche; JetBrains IDE non funziona ancora con il cirillico nei nomi dei file ovunque. 1C fornisce un isolamento di alta qualità del codice dell'applicazione dal livello del database. Lì è impossibile digitare tabelle a basso livello e lì sono impossibili gli stipiti di junior incompetenti a livello di database. Sì, potrebbero esserci altri problemi con ragazzi incompetenti, ma la varietà dei problemi è molto minore. Ora mi dirai che la tua applicazione è progettata correttamente e che il livello di accesso al database è isolato come dovrebbe essere. Dai un'altra occhiata alla tua applicazione Java personalizzata aziendale. Strettamente e onestamente. La tua coscienza ti dà fastidio? Allora sono felice per te.
2. Numerazione di documenti/libri di consultazione. In 1C non è sicuramente il più flessibile e non il migliore. Ma quello che fanno nei software bancari e nei sistemi contabili autoprodotti è solo oscurità. O l'identità verrà bloccata (e poi "oh, perché abbiamo dei buchi"), o al contrario, creeranno un generatore che funziona con il blocco a livello DBMS (e diventerà un collo di bottiglia). In effetti, è abbastanza difficile svolgere questo compito apparentemente semplice: un enumeratore di entità end-to-end, con una sezione di unicità basata su un determinato insieme di chiavi, prefisso, in modo da non bloccare il database durante l'immissione parallela dei dati .
3. Identificatori dei record nel database. 1C ha preso una decisione volitiva: tutti gli identificatori di collegamento sono assolutamente sintetici e basta. E non ci sono problemi con database e scambi distribuiti. Gli sviluppatori di altri sistemi creano ostinatamente qualcosa come un'identità (è più breve!), trascinandoli nella GUI finché non arriva il momento di creare diverse istanze correlate (e poi verranno scoperte). Non hai questo? Onestamente?
4. Elenchi. 1C dispone di meccanismi abbastanza efficaci per sfogliare elenchi (grandi) e navigare al loro interno. Vorrei effettuare subito una prenotazione, utilizzando il meccanismo correttamente! In generale, l'argomento è piuttosto spiacevole, non può essere risolto idealmente: o è intuitivo e semplice (ma c'è il rischio di enormi recordset sul client), oppure il paging è di una o di un'altra distorsione. Coloro che fanno il cercapersone spesso lo fanno in modo storto. Chi realizza una barra di scorrimento onesta aggiunge un database, un canale e un client.
5. Moduli gestiti. Senza dubbio nel client web l'interfaccia non funziona perfettamente. Ma funziona. Ma per molti altri sistemi contabili e bancari, la creazione di un posto di lavoro remoto è un progetto a livello aziendale. Disclaimer: fortunatamente per coloro che lo hanno realizzato originariamente sul web, questo non influirà.
6. Applicazione mobile. Recentemente, puoi anche scrivere applicazioni mobili nello stesso ecosistema. Qui è un po’ più complicato che con un client web; le specifiche dei dispositivi ti costringono a scrivere appositamente per loro, ma, tuttavia, non assumi un team separato di sviluppatori mobili. Se hai bisogno di un'applicazione per le esigenze interne di un'azienda (quando una soluzione mobile a un problema aziendale è più importante di un design dell'interfaccia utente giallo), utilizzi semplicemente la stessa piattaforma pronta all'uso.
7. Segnalazione. Con questa parola non intendo un sistema BI con big data e un ritardo nel processo ETL. Si tratta di rapporti del personale operativo che consentono di valutare lo stato della contabilità qui e ora. Saldi, liquidazioni reciproche, riclassificazioni, ecc. 1C è pronto all'uso con un sistema di reporting con impostazioni flessibili per raggruppamenti, filtri e visualizzazione sul lato utente. Sì, ci sono analoghi più interessanti sul mercato. Ma non nell'ambito di una soluzione all-in-one e ad un prezzo talvolta superiore a quello di una soluzione all-in-one. E più spesso accade anche il contrario: solo reportistica, ma più costosa dell’intera piattaforma e di qualità peggiore.
8. Moduli stampabili. Bene, usa .NET per risolvere il problema dell'invio delle buste paga in PDF ai dipendenti via e-mail. E ora il compito di stampare le fatture. Che ne dici di salvare le loro copie nello stesso PDF? Per il nickname 1C, l'output di qualsiasi layout in PDF è +1 riga di codice. Ciò significa + 40 secondi di tempo di lavoro, invece di giorni o settimane in un'altra lingua. I layout dei moduli stampati in 1C sono incredibilmente facili da sviluppare e abbastanza potenti da competere con le controparti a pagamento. Sì, probabilmente, non ci sono molte opportunità interattive nei fogli di calcolo 1C, non puoi ottenere rapidamente un diagramma 3D con ridimensionamento utilizzando OpenGL. Ma è davvero necessario?

Questi sono solo alcuni esempi in cui limitare la funzionalità o implementare compromessi si rivelerà un importante vantaggio architetturale in futuro. Anche un compromesso o meno l'opzione più efficace è già nella confezione ed è data per scontata. La sua implementazione indipendente sarà impossibile (perché tali decisioni devono essere prese all'inizio del progetto, e non c'è tempo per questo, e non esiste alcun architetto), o diverse iterazioni costose. In ciascuno dei punti elencati (e questo non è un elenco completo di soluzioni architettoniche), puoi sbagliare e introdurre restrizioni che bloccano il ridimensionamento. In ogni caso, tu, come uomo d'affari, devi assicurarti che i tuoi programmatori, quando creano un "sistema da zero", abbiano le mani dirette e risolvano subito bene i problemi più sottili del sistema.

Sì, come in qualsiasi altro sistema complesso, anche 1C dispone di soluzioni che bloccano il ridimensionamento in determinati aspetti. Tuttavia, ripeto, per una combinazione di fattori, il costo di gestione e il numero di problemi già risolti in anticipo, non vedo un degno concorrente sul mercato. Allo stesso prezzo, ottieni un framework per applicazioni finanziarie, un server bilanciato in cluster, con un'interfaccia utente e un'interfaccia web, con un'applicazione mobile, con reporting, integrazione e un sacco di altre cose. Nel mondo Java, assumi un team front-end e back-end, esegui il debug di banchi di basso livello di codice server scritto in casa e paghi separatamente 2 applicazioni mobili per 2 sistemi operativi mobili.

Non sto dicendo che 1C risolverà tutti i casi, ma per un'applicazione aziendale interna, quando non è necessario marchiare l'interfaccia utente, cos'altro è necessario?

Unico neo

Probabilmente hai l’impressione che 1C salverà il mondo e che tutti gli altri modi di scrivere sistemi aziendali siano sbagliati. Non è affatto così. Dal punto di vista di un uomo d'affari, se scegli 1C, oltre al rapido time-to-market, devi tenere conto dei seguenti svantaggi:

• Affidabilità del server. Sono necessari specialisti di altissima qualità in grado di garantirne il funzionamento ininterrotto. Non sono a conoscenza di un programma di formazione già pronto da parte del venditore per tali specialisti. Ci sono dei corsi per prepararsi all'esame Expert, ma questo, secondo me, non basta.
• Supporto. Vedi punto precedente. Per avere supporto dal venditore, è necessario acquistarlo. Per qualche motivo questo non è accettato nel settore 1C. E con SAP è quasi un acquisto obbligato e non dà fastidio a nessuno. Senza il supporto aziendale e senza uno staff esperto, potresti rimanere solo con i problemi 1C.
• Tuttavia, non puoi fare assolutamente tutto con 1C. Questo è uno strumento e come ogni strumento ha dei limiti di applicabilità. Nel panorama 1C, è molto desiderabile avere un architetto di sistema “non 1C”.
• I buoni soprannomi 1C non sono più economici dei buoni programmatori in altre lingue. Tuttavia, è costoso assumere cattivi programmatori, indipendentemente dalla lingua in cui scrivono.

Mettiamo i puntini

• 1C è un framework RAD (Rapid Application Development) per le aziende ed è progettato su misura per questo.
• Collegamento a tre livelli con supporto per i principali DBMS, interfaccia utente client, un ottimo ORM e reporting
• Ampie possibilità di integrazione con sistemi che possono fare ciò che 1C non può. Se desideri l'apprendimento automatico, prendi Python e invia il risultato a 1C tramite http o RabbitMQ
• Non è necessario sforzarsi di fare tutto utilizzando 1C, è necessario comprenderne i punti di forza e utilizzarli per i propri scopi
• Gli sviluppatori che gravitano verso l'approfondimento dei gadget del framework tecnologico e la riprogettazione ogni N anni su un nuovo motore sono annoiati da 1C. Tutto è molto conservatore lì.
• Anche gli sviluppatori sono annoiati perché il produttore si preoccupa molto poco per loro. Linguaggio noioso, IDE debole. Richiedono una modernizzazione.
• D'altra parte, gli sviluppatori che non riescono a divertirsi utilizzando e imparando un'altra tecnologia di cui godono sono cattivi sviluppatori. Si lamenteranno e si sposteranno in un altro ecosistema.
• I datori di lavoro che non consentono ai loro soprannomi 1C di scrivere qualcosa in Python sono cattivi datori di lavoro. Perderanno dipendenti con menti curiose e al loro posto arriveranno programmatori scimmie che, pur essendo d'accordo su tutto, trascineranno il software aziendale nella palude. Dovrà ancora essere riscritto, quindi forse sarebbe meglio investire un po' in Python un po' prima?
• 1C è una società commerciale e implementa funzionalità esclusivamente in base ai propri interessi e opportunità. Non puoi biasimarla per questo, gli affari devono pensare al profitto, questa è la vita
• 1C guadagna vendendo soluzioni ai problemi aziendali, non ai problemi degli sviluppatori di Vasya. Questi due concetti sono correlati, ma la priorità è esattamente quella che ho detto. Quando lo sviluppatore Vasya sarà pronto a pagare per una licenza personale per 1C: Resharper, apparirà abbastanza rapidamente, "Resharper" di A. Orefkova ne è la prova. Se il venditore lo supportasse e non lo contrastasse, apparirebbe un mercato per il software per gli sviluppatori. Adesso in questo mercato ci sono un attore e mezzo con risultati discutibili, e tutto perché l'integrazione con l'IDE è negativa e tutto si fa con le stampelle.
• La pratica di un operatore multi-macchina scomparirà nell'oblio. Le applicazioni moderne sono troppo grandi per essere ricordate sia dal lato del codice che dal lato dell'uso aziendale. Anche il server 1C sta diventando più complesso; sarà impossibile racchiudere tutti i tipi di competenze in un solo dipendente. Ciò dovrebbe comportare una domanda di specialisti, il che significa l'attrattiva della professione 1C e un aumento degli stipendi. Se prima Vasya lavorava tre in uno per uno stipendio, ora è necessario assumere due Vasya e la competizione tra Vasya può stimolare la crescita complessiva del loro livello.

conclusione

1C è un prodotto molto degno. Nella mia fascia di prezzo non conosco alcun analogo, scrivi nei commenti se ce ne sono. Tuttavia, il deflusso di sviluppatori dall'ecosistema sta diventando sempre più evidente, e questa è una "fuga di cervelli", non importa come la guardi. L’industria ha fame di modernizzazione.
Se sei uno sviluppatore, non fissarti su 1C e non pensare che tutto sia magico in altri linguaggi. Mentre sei junior, forse. Non appena si dovrà risolvere qualcosa di più grande, le soluzioni già pronte dovranno essere cercate più a lungo e completate più intensamente. In termini di qualità dei “blocchi” da cui è possibile costruire una soluzione, 1C è molto, molto buono.

E ancora una cosa: se un soprannome 1C viene da te per essere assunto, il soprannome 1C può essere tranquillamente nominato nella posizione di analisti principali. La loro comprensione del compito, dell'area tematica e delle capacità di scomposizione è eccellente. Sono sicuro che ciò sia dovuto proprio all'uso forzato di DDD nello sviluppo 1C. La persona è formata a pensare innanzitutto al significato del compito, alle connessioni tra gli oggetti dell'area tematica, e allo stesso tempo ha un background tecnico nelle tecnologie di integrazione e nei formati di scambio dei dati.

Sii consapevole che il quadro ideale non esiste e abbi cura di te.
Tutto bene!

PS: grazie mille speshurico per assistenza nella stesura dell'articolo.

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Hai 1C nella tua azienda?

• 13,3%Niente affatto.71

• 30,3%C'è, ma solo da qualche parte nel reparto contabilità. Sistemi core su altre piattaforme162

• 41,4%Sì, i principali processi aziendali funzionano su di esso221

• 15,0%1C deve morire, il futuro appartiene a %technology_name%80

534 utenti hanno votato. 99 utenti si sono astenuti.

Fonte: habr.com