1C - Bem e mal. Disposição de pontos em holivares em torno de 1C

Amigos e colegas, recentemente, o Habr tem observado um aumento de artigos criticando o 1C como plataforma de desenvolvimento, juntamente com declarações de seus defensores. Esses artigos destacam um problema sério: na maioria das vezes, os críticos do 1C o criticam partindo de uma posição de "incapacidade de lidar com a situação", apontando problemas que, na prática, são facilmente solucionáveis, enquanto, inversamente, ignoram as questões realmente importantes que merecem ser discutidas e que não estão sendo abordadas pelo fornecedor. Acredito que faça sentido realizar uma análise sóbria e equilibrada da plataforma 1C. Abordaremos o que ela pode fazer, o que não pode, o que deveria fazer, mas não faz, e, por último, mas não menos importante, o que ela faz brilhantemente, enquanto seus desenvolvedores da %technology_name% levarão uma eternidade para fazer o mesmo, desperdiçando muitos orçamentos anuais.

Como resultado, você, como gerente ou arquiteto, poderá obter uma compreensão clara de quais tarefas se beneficiarão do 1C e onde ele precisa ser levado ao limite. Como desenvolvedor em um ambiente que não utiliza 1C, você poderá ver o que torna o 1C tão especial e justifica todo o alvoroço em torno dele. E como desenvolvedor 1C, você poderá comparar seu sistema com outros ecossistemas de linguagem e entender onde você se encaixa no cenário de desenvolvimento de software.

Abaixo do corte, você encontrará uma série de ataques contundentes ao 1C, aos críticos do 1C, ao Java, ao .NET e, em geral... Preparem-se, sejam bem-vindos!

Quem sou eu

Conheço esse assunto desde 2004, mais ou menos. Programo há uns seis anos, desde que ganhei um livro sobre o Professor Fortran com tirinhas sobre um gato, um pardal e uma lagarta. Eu analisava os programas escritos pelo gato nas ilustrações do livro e tentava descobrir o que eles faziam. E sim, eu não tinha um computador de verdade naquela época, mas havia uma foto de um na contracapa do livro, e eu, obedientemente, apertava os botões de papel, digitando os comandos que eu tinha aprendido com o X, o Gato.

Depois vieram o BK0011 e o BASIC na escola, C++ e assemblers na universidade, depois o 1C, e muito mais, tanto que é difícil lembrar de tudo. Nos últimos 15 anos, tenho me dedicado principalmente ao 1C, não apenas à programação, mas ao 1C em geral. Configuração de tarefas, administração e DevOps também fazem parte disso. Nos últimos cinco anos, tenho me envolvido em atividades de serviço comunitário, desenvolvendo ferramentas de desenvolvimento e automação para outros desenvolvedores de 1C e escrevendo artigos e livros.

Vamos decidir qual será o tema da discussão.

Primeiramente, vamos definir do que estamos falando, pois a expressão "1C" pode ter vários significados. Neste caso, "1C" refere-se exclusivamente ao framework de desenvolvimento 1C:Enterprise, a oitava versão atual. Não abordaremos muito o fabricante ou suas políticas (mas teremos que mencionar algo). Também não discutiremos aplicações específicas escritas com este framework. A tecnologia é um assunto à parte, assim como as aplicações (ou configurações).

Arquitetura de alto nível do 1C: Empresa

Menciono a palavra "framework" por um motivo. Da perspectiva de um desenvolvedor, a plataforma 1C é precisamente isso: um framework. E deve ser tratada como tal. Pense nela como o Spring ou o ASP.NET, executados por um ambiente de execução (JVM ou CLR, respectivamente). Acontece que, no mundo da programação tradicional ("não-1C"), a divisão em frameworks, máquinas virtuais e aplicações específicas é natural, devido ao fato de que esses componentes são normalmente desenvolvidos por fornecedores diferentes. No mundo 1C, no entanto, não é comum distinguir explicitamente entre o framework de desenvolvimento e o próprio ambiente de execução. Além disso, as aplicações específicas escritas usando o framework são, em sua maioria, também desenvolvidas pela própria 1C. Isso leva a alguma confusão. Portanto, neste artigo, examinaremos o 1C sob diversas perspectivas e o classificaremos em vários eixos. E, em cada eixo, analisaremos em detalhes e consideraremos os recursos, as vantagens e as desvantagens da solução existente.

Pontos de vista sobre 1C

1 centavo para o comprador

O comprador adquire um sistema de automação que lhe permitirá resolver rapidamente as suas próprias necessidades de automação empresarial. Essa empresa pode ser um pequeno quiosque ou uma grande holding. Embora essas empresas tenham necessidades claramente diferentes, ambas são suportadas por uma única plataforma de código-fonte.

Para um comprador, o 1C oferece um tempo de lançamento no mercado muito rápido. Rápido. Mais rápido que Java, C# ou JS. Em média. Não necessariamente. É claro que um site de cartão de visitas terá um desempenho melhor em React, mas o backend de um sistema WMS será lançado mais rapidamente em 1C.

1C como ferramenta

Toda solução tecnológica tem seus limites de aplicabilidade. 1C não é uma linguagem de propósito geral; ela não existe separadamente de seu framework. Faz sentido usar 1C quando você precisa de:

• aplicação de servidor
• uma aplicação que envolve finanças
• Com interface de usuário pronta, ORM, relatórios, XML/JSON/COM/PDF/SeuFormatoDeTransferênciaDeDados
• com suporte para processos e tarefas em segundo plano
• com um sistema de segurança baseado em funções
• com lógica de negócios programável
• com a capacidade de criar rapidamente um protótipo e um curto período de lançamento no mercado.

Você não precisa de 1C se quiser:

• aprendizado de máquina
• cálculos de GPU
• computação gráfica
• cálculos matemáticos
• sistema CAD
• processamento de sinal (som, vídeo)
• Chamadas HTTP de alta carga com centenas de milhares de RPS

1C como empresa de manufatura

É importante entender o negócio da 1C como fabricante de software. A 1C vende soluções para problemas empresariais por meio da automação. Seja para empresas grandes ou pequenas, é exatamente isso que ela vende. Os aplicativos empresariais são os meios para atingir esse objetivo. Para contabilidade, folha de pagamento e outras finalidades, a empresa utiliza sua própria plataforma de desenvolvimento de aplicativos empresariais. Ela é especificamente adaptada às tarefas comuns desses mesmos aplicativos empresariais:

• contabilidade financeira
• fácil personalização da lógica de negócios
• amplas capacidades de integração em ambientes de TI heterogêneos

Como fabricante, a 1C acredita que essa estratégia possibilita uma relação vantajosa para ambas as partes com parceiros e clientes. Embora isso possa ser discutível, é basicamente assim que a empresa se apresenta no mercado: soluções prontas para problemas de negócios que podem ser rapidamente personalizadas por parceiros e integradas a qualquer ambiente de TI.

Todas as reclamações ou desejos sobre o 1C como framework devem ser vistos exclusivamente sob essa perspectiva. "Queremos OOP no 1C", dizem os desenvolvedores. "Quanto nos custará o suporte a OOP na plataforma? Isso nos ajudará a aumentar as vendas de produtos físicos?", pergunta a 1C. Eles revelam sua "perspectiva" de vender soluções para problemas de negócios:

— Ei, pessoal da área de negócios, vocês querem OOP no seu 1C?
— Isso vai me ajudar a resolver meus problemas?
Quem sabe...
- Então não há necessidade.

Essa abordagem pode ser boa ou ruim, dependendo de quem a analisa, mas é assim que funciona. Quando dizemos que a versão 1C não possui o recurso X, precisamos entender que ele não está lá por um motivo específico, mas sim no contexto da relação custo-benefício entre custo de implementação e lucro.

Classificação tecnológica

"Na verdade, os usuários do Odinets aproveitam ao máximo os melhores padrões, cuidadosamente selecionados pelos metodologistas e desenvolvedores da plataforma 1C."
Quando você escreve seu código estúpido para um formulário gerenciado simples, o que você está realmente usando é modelo-visão-controlador с vinculação de dados bidirecional в motor-de-aplicativo-de-dados-três-camadas, aromatizado mapeamento objeto-relacional de alto nível baseado em descrição declarativa de metadados, que tem seu próprio linguagem de consulta independente de plataforma, C Interface de usuário declarativa orientada a dados, serialização transparente completa e linguagem de programação orientada a domínio..

O que diferencia os desenvolvedores 1C de seus colegas ocidentais é a sua comunicação. Eles adoram dar um nome pomposo a qualquer bobagem e fazer alarde disso como se fosse a menina dos seus olhos.
A. Orefkov

A plataforma 1C possui uma arquitetura clássica de três camadas, centrada no servidor de aplicativos (ou sua emulação, disponível a baixo custo para pequenas empresas). MS SQL ou Postgres são usados ​​como SGBD. Há também suporte para Oracle e IBM DB2, mas isso é em grande parte obscuro; ninguém sabe o que acontecerá se o 1C for implementado nesses bancos de dados sob cargas médias a altas. Suspeito que nem mesmo a própria 1C saiba.

O lado do cliente pode ser um cliente leve instalado na máquina do usuário ou um cliente web. A principal característica é que os programadores não escrevem dois códigos diferentes; eles escrevem um único aplicativo em uma única linguagem, e você pode implantá-lo no navegador se quiser ou precisar. Quem queria uma solução full-stack completa com uma única linguagem para o front-end e o back-end, Node.js? Eles nunca conseguiram alcançar uma experiência totalmente consistente. Uma solução full-stack completa existe, mas você terá que escrevê-la em uma única linguagem. Irônico, não é?

A solução SaaS baseada em nuvem 1C:Fresh também funciona no modo navegador. Em vez de comprar o 1C, você pode alugar um pequeno banco de dados e acompanhar suas vendas de shawarma por lá. Basta usar no seu navegador, sem precisar instalar ou configurar nada.

Existe também um cliente legado, que a 1C chama de "aplicativo comum". Legado é legado, bem-vindo ao mundo dos aplicativos de 2002, mas estamos falando do estado atual do ecossistema.

O servidor 1C suporta clustering e escalabilidade com a adição de novas máquinas ao cluster. Há bastante debate sobre isso, e abordaremos esse assunto em uma seção separada deste artigo. Resumindo, não é exatamente a mesma coisa que adicionar algumas instâncias idênticas por trás do HAProxy.

A estrutura de desenvolvimento de aplicativos usa sua própria linguagem de programação, que se assemelha, em linhas gerais, a um VB6 ligeiramente aprimorado traduzido para o russo. Para aqueles que detestam tudo o que é russo e não acreditam que "if" se traduza como "if", uma segunda opção de sintaxe é oferecida. Isso significa que, se desejado, você pode escrever em 1C de uma forma visualmente indistinguível do VB.

Essa linguagem de programação é o principal motivo pelo qual os desenvolvedores de 1C detestam sua plataforma. Francamente, não é sem motivo. A linguagem foi concebida para ser o mais simples possível, projetada para cumprir o mantra "DESENVOLVEDORES, DESENVOLVEDORES", pelo menos em escala CIS. A lógica comercial por trás dessa decisão, na minha opinião, é clara: mais desenvolvedores, maior alcance de mercado. As estimativas variam de 45% a 95%, e afirmo logo de cara que programar na linguagem em que você pensa é realmente mais fácil. E eu conheço várias linguagens de programação.

Vamos começar pela linguagem, talvez.

Linguagem de programação 1C

Essa é, ao mesmo tempo, a força e a fraqueza do sistema. Ele garante facilidade de entrada e legibilidade. Por outro lado, não é atualizado desde a versão 8, lançada em 2002, e está desatualizado. Alguns podem dizer: "A principal desvantagem é a falta de POO", mas estariam enganados. Primeiro, não é apenas Nuraliev que não gosta de POO, mas Torvalds também. E segundo, POO existe, sim.

Do ponto de vista do desenvolvedor, existe uma estrutura com classes base mapeadas para o SGBD. Ele pode pegar a classe base "Directory" e estender o diretório "Customers" a partir dela. Pode adicionar novos campos à classe, como Número de Identificação Fiscal (TIN) e Endereço, e, se necessário, sobrescrever métodos da classe base, como o método OnWrite.

O framework foi projetado de forma que heranças mais profundas raramente sejam necessárias, e a restrição de OOP, na minha opinião, faz sentido. O 1C foca no Desenvolvimento Orientado a Domínio (DDD) e força você a pensar principalmente na área temática da solução que está sendo desenvolvida, e isso é algo positivo. Não só não há tentação, como também não há necessidade de escrever 10 DTOs e ViewModels diferentes apenas para exibir alguns dados de domínio em algum lugar. Um desenvolvedor 1C sempre opera com uma única entidade, sem sobrecarregar seu contexto com uma dúzia de classes com nomes semelhantes representando a mesma entidade de perspectivas diferentes. Qualquer aplicação .NET, por exemplo, inevitavelmente conterá alguns ViewModels e DTOs para serialização em JSON e transferência de dados do cliente para o servidor. E aproximadamente 10-15% do código da sua aplicação será gasto na transferência manual de dados de uma classe para outra ou usando gambiarras como o AutoMapper. Esse código precisa ser escrito, e programadores precisam ser pagos para criá-lo e mantê-lo.

Descobriu-se que a linguagem 1C é difícil de desenvolver sem aumentar sua complexidade ao nível das linguagens convencionais, perdendo assim sua vantagem de simplicidade. Qual é o objetivo final do fornecedor: entregar uma solução padrão que qualquer estudante recrutado na rua possa personalizar com o nível de qualidade necessário (ou seja, que atenda desde um quiosque até uma grande fábrica)? Se você tem um quiosque, contrate um estudante; se você tem uma fábrica, contrate um especialista de um parceiro de implementação. O fato de os parceiros de implementação venderem estudantes pelo preço de especialistas não é um problema do framework. Arquiteturalmente, o framework deve atender às necessidades de ambos; o código para configurações padrão (que vendemos para empresas com a promessa de personalização) deve ser compreensível para um estudante, e um especialista consegue entender qualquer coisa.

Na minha opinião, o que realmente falta na linguagem, o que nos obriga a escrever mais do que é possível, o que desperdiça o tempo pago pelo cliente?

• Possibilidade de digitar no nível do TypeScript, por exemplo (resultando em ferramentas de análise de código mais avançadas no IDE, refatoração e menos bugs irritantes).
  Ter funções como objetos de primeira classe. Um conceito um pouco mais complexo, mas a quantidade de código repetitivo poderia ser significativamente reduzida em comparação com o código típico. Na minha opinião, a compreensão do código pelos alunos até melhoraria devido ao volume reduzido.
• Literais e inicializadores universais para coleções. O mesmo se aplica à redução da quantidade de código que precisa ser escrita e/ou revisada. Popular coleções consome mais de 9000% do tempo de programação em 1C. Escrever isso sem açúcar sintático é demorado, caro e propenso a erros. Em geral, o número de linhas de código em soluções 1C excede todos os limites concebíveis em comparação com frameworks de código aberto disponíveis e, na verdade, com todos os seus programas Java corporativos combinados. A linguagem é verbosa, e isso resulta em volume de dados, memória, lentidão da IDE, tempo e dinheiro.
• Finalmente, sobre as construções... Tenho uma hipótese de que essa construção está faltando porque não encontraram uma boa tradução para o russo 🙂
• Tipos de dados nativos (não orientados a objetos), análogos ao Type do VB6. Isso elimina a necessidade de tipar estruturas usando comentários na biblioteca de subsistema padrão e métodos mágicos para construir essas estruturas. O resultado: menos código, dicas pontilhadas, resolução de problemas mais rápida e menos erros de digitação e propriedades de estrutura ausentes. Atualmente, a tipagem de estruturas definidas pelo usuário é de inteira responsabilidade da equipe de desenvolvimento da Biblioteca de Subsistema Padrão, que, a seu crédito, escreve comentários meticulosos sobre as propriedades esperadas das estruturas de parâmetro passadas.
• A falta de suporte ao trabalhar com chamadas assíncronas no cliente web é um problema. O "inferno de callbacks" na forma de NotificationHandling é uma solução paliativa temporária causada por uma mudança repentina nas APIs dos principais navegadores, mas isso não é sustentável indefinidamente; a vantagem da "compreensão inicial" do código assíncrono está se perdendo cada vez mais. Some-se a isso a falta de suporte para esse paradigma na IDE principal, e a situação fica ainda pior.

Esses são apenas alguns dos problemas urgentes. A lista poderia ser muito mais longa, mas devemos lembrar que esta não é uma linguagem de propósito geral. Ela não exige multithreading, funções lambda, acesso à GPU ou cálculos rápidos de ponto flutuante. É uma linguagem de script para lógica de negócios.

Um programador que trabalhou extensivamente com essa linguagem e depois se interessou por JS ou C# acaba se entediando com ela. Isso é um fato. Ela precisa evoluir. Por outro lado, o fornecedor avalia o custo de implementação desses recursos em relação ao aumento de receita que eles gerarão. Não tenho informações sobre qual é a consideração mais importante para a empresa atualmente.

Ambiente de desenvolvimento

As coisas também não são fáceis por aqui. Existem dois ambientes de desenvolvimento. O primeiro é o Configurador, que está incluído na distribuição. O segundo é o ambiente de Ferramentas de Desenvolvimento Empresarial (EDT), desenvolvido usando o Eclipse.

O configurador oferece uma gama completa de tarefas de desenvolvimento, suporta todos os recursos e é o principal ambiente do mercado. No entanto, está desatualizado e, segundo rumores, não está sendo atualizado devido ao grande volume de dívida técnica acumulada. A situação poderia ser melhorada com a abertura da API interna (na forma de uma parceria com...). Tempestade de neve A. Orefkova ou independentemente), mas não é o caso. A experiência tem mostrado que a comunidade improvisará seus próprios recursos de IDE, desde que o fornecedor não interfira. Mas temos o que temos. O configurador era ótimo em 2004-2005, muito parecido com o Visual Studio daquela época, e até melhor em alguns aspectos, mas está preso naqueles tempos.

Além disso, o tamanho de uma solução típica média cresceu várias vezes desde então, e as IDEs atuais simplesmente não conseguem lidar com o volume de código que recebem. A usabilidade e os recursos de refatoração não são nulos; na verdade, estão em declínio. Tudo isso desanima os desenvolvedores, que sonham em migrar para outros ecossistemas e continuar programando mal por lá, mas em um ambiente agradável que não os trate com seu comportamento.

Como alternativa, oferecemos uma IDE construída do zero sobre o Eclipse. Seu código-fonte, como o de qualquer outro software, reside em arquivos de texto armazenados no GIT, branches, pull requests e tudo mais. A desvantagem é que ela não saiu do status beta há anos, embora esteja melhorando a cada versão. Não vou me aprofundar nos pontos negativos do EDT, dizendo que o problema de hoje é a solução de amanhã. Tal descrição se tornaria rapidamente irrelevante. Desenvolver no EDT é possível hoje, mas é incomum, e você precisa estar preparado para uma certa quantidade de bugs na IDE.

Se analisarmos a situação pela perspectiva do "Modelo 1C" mencionado anteriormente, o resultado seria algo como: o lançamento de uma nova IDE não impulsionará as vendas de computadores, mas provavelmente reduzirá a rotatividade de desenvolvedores. É difícil prever o futuro do ecossistema em termos de conforto para os desenvolvedores, mas a Microsoft já prejudicou os desenvolvedores mobile uma vez ao oferecer seus serviços tarde demais.

Gestão de desenvolvimento

Tudo aqui é significativamente melhor do que escrever código, especialmente nos últimos tempos, quando os esforços da comunidade trouxeram à tona problemas com a administração automatizada, o lançamento de protótipos que exigem o abandono do repositório 1C e o uso do Git, a identificação rápida de erros (quick blame), a revisão de código, a análise estática, a implantação automática e assim por diante. Muitos recursos foram adicionados à plataforma, aumentando o nível de automação das tarefas de desenvolvimento. No entanto, todos esses recursos foram adicionados exclusivamente para o desenvolvimento de nossos próprios produtos de grande porte, quando ficou claro que a automação não era mais uma opção. Recursos como mesclagem automática (auto-merges), comparações KDiff de três vias e outros semelhantes foram adicionados. Um projeto no GitHub foi lançado. conversor git, que, francamente, foi ideologicamente afastado do projeto gitsyncmas personalizada para os processos do fornecedor. Graças à dedicada equipe de código aberto, a automação de desenvolvimento no 1C avançou. Uma API de configuração aberta, na minha opinião, também superaria o atraso moral da IDE principal.

Hoje, armazenamos códigos-fonte do OneC no Git com commits vinculados a tarefas do Jira, fazemos revisões no Crucible, implantamos com um botão no Jenkins e geramos relatórios do Allure sobre testes de código no OneC, e até mesmo Análise estática no SonarQube — Isso já não é novidade, mas sim algo comum em empresas que investem muito em desenvolvimento 1C.

administração

Há muito o que dizer aqui. Primeiro, claro, temos o servidor (o cluster de servidores 1C). É uma maravilha, mas, por ser uma completa caixa preta, documentada com detalhes suficientes, porém de uma forma específica, conseguir executar operações ininterruptas de alta carga em múltiplos servidores é privilégio de poucos, aqueles que ostentam o título de "Especialista em Tecnologia". Vale ressaltar que, em princípio, administrar um servidor 1C não difere da administração de qualquer outro servidor. Trata-se de um aplicativo multithread baseado em rede que consome memória, CPU e recursos de disco. Oferece amplas capacidades para coleta de telemetria e diagnóstico.

O problema aqui é que o fornecedor não oferece nada de especial em termos de soluções prontas para esse diagnóstico. Sim, existem o 1C:KIP e o TsUP, e embora não sejam ruins, são muito caros e nem todos os possuem. A comunidade tem vários projetos para conectar o Grafana, o Zabbix, o ELK e outras ferramentas administrativas padrão, mas não há uma solução única que atenda à maioria. A tarefa aguarda um especialista. E se você é uma empresa que planeja implementar um cluster 1C, precisa de um especialista. Seja ele interno ou externo, é necessário. É normal ter uma função separada com competências específicas para o servidor; nem todo especialista em 1C precisa desse conhecimento, mas é preciso entender que essa função é necessária. Veja o SAP, por exemplo. Um programador de lá provavelmente nem se levantaria da cadeira se fosse solicitado a configurar algo no servidor de aplicativos. Ele pode simplesmente não ter ideia do que está fazendo e não se sentirá envergonhado. A metodologia SAP tem uma função dedicada para isso. Por algum motivo, o setor de TI acredita que essas habilidades devem ser combinadas em um único funcionário com o mesmo salário. Isso é um equívoco.

Desvantagens do servidor 1C

Só existe uma desvantagem: a confiabilidade. Ou, se preferir, a imprevisibilidade. Comportamentos repentinos e erráticos do servidor são o assunto do momento. A solução universal — parar o servidor e limpar todos os caches — é até descrita no manual do especialista, e um arquivo em lote é recomendado para isso. Se o seu servidor 1C começar a fazer algo que nem teoricamente deveria fazer, é hora de limpar o cache de dados da sessão. Na minha opinião, existem apenas umas três pessoas em todo o país que sabem operar um servidor 1C sem esse procedimento, e elas não compartilham seus segredos porque é assim que ganham a vida. Talvez o segredo delas seja que elas limpam os dados da sessão, mas não contam para ninguém, hehe.

De resto, o servidor 1C é uma aplicação igual a qualquer outra e é administrado de forma muito semelhante, através da leitura de documentação e muita insistência.

Estivador

A utilidade de usar um servidor 1C em contêineres em produção ainda não foi comprovada. O servidor não é clusterizado simplesmente adicionando nós atrás de um balanceador de carga, o que minimiza os benefícios da conteinerização em produção, e a operação bem-sucedida em alta carga em contêineres não foi comprovada. Como resultado, Docker + 1C é usado apenas por desenvolvedores para configurar ambientes de teste. Nesse contexto, é extremamente útil e prático, permitindo que os desenvolvedores experimentem tecnologias modernas e deem uma pausa na monotonia da ferramenta de configuração.

Componente comercial

Do ponto de vista do investimento, o 1C permite o lançamento rápido de ideias de negócios graças às amplas funcionalidades de suas classes de aplicativos. O 1C oferece, de forma nativa, relatórios bastante completos, integração com diversas plataformas, um cliente web, um cliente mobile, um aplicativo mobile, suporte para vários SGBDs, incluindo os gratuitos, e suporte multiplataforma tanto para o servidor quanto para os componentes do cliente instaláveis. Sim, a interface do aplicativo será amarela, o que às vezes pode ser uma desvantagem, mas nem sempre.
Ao escolher a 1C, uma empresa recebe um conjunto de soluções de software que lhe permitem criar uma ampla variedade de aplicações, além de ter acesso a uma grande quantidade de desenvolvedores no mercado que cobram menos do que os desenvolvedores Java e entregam resultados mais rapidamente.

Por exemplo, enviar uma fatura em PDF para um cliente pode ser feito em uma hora de trabalho de um estudante. A mesma tarefa em .NET pode ser realizada comprando uma biblioteca proprietária ou levando alguns dias ou semanas de programação por um desenvolvedor sério e barbudo. Às vezes, ambos. E sim, eu só falei sobre gerar um PDF. Não dissemos de onde a fatura viria. O desenvolvedor front-end precisa criar o formulário onde o operador insere os dados, o desenvolvedor back-end precisa criar modelos DTO para transmitir JSON, modelos para armazená-lo no banco de dados, a própria estrutura do banco de dados, migrações para ele, gerar uma representação gráfica da fatura e só então o PDF. Em 1C, toda a tarefa, do zero, pode ser concluída em exatamente uma hora.

Um sistema de contabilidade completo para um pequeno quiosque com um único processo de compra e venda pode ser desenvolvido em cerca de três horas. Ele inclui relatórios de vendas, controle de estoque por preços de compra e venda, detalhamento por depósito, controle de acesso, um cliente web e um aplicativo móvel. Ok, estou exagerando um pouco sobre o aplicativo; com ele, não leva três horas, leva seis.

Quanto tempo um desenvolvedor .NET levará para concluir essa tarefa, desde a instalação do Visual Studio em um computador limpo até a demonstração ao cliente? E qual o custo do desenvolvimento? Exatamente.

Pontos fortes da 1C como plataforma

A força do 1C não reside em possuir uma única funcionalidade específica que seja a melhor da categoria. Pelo contrário, cada subsistema individual tem um equivalente mais interessante em softwares globais. Contudo, considerando uma combinação de fatores, não vejo uma plataforma comparável ao 1C. É precisamente aí que reside o seu sucesso comercial. As vantagens da plataforma estão dispersas e tornam-se mais evidentes quando se observa como são implementadas em outras plataformas. Na maioria dos casos, não se tratam de funcionalidades propriamente ditas, mas sim da rejeição de funcionalidades em favor de um paradigma específico. Alguns exemplos:

1. Unicode. O que poderia ser mais simples? Não use codificações ASCII de byte único em 2019 (exceto para integração com sistemas legados opacos). De jeito nenhum. Mas não. Alguém ainda usará um varchar de byte único em alguma tabela, e o aplicativo terá problemas de codificação. Em 2015, a autorização LDAP do GitLab falhou devido ao tratamento inadequado de codificação, e o IDE da JetBrains ainda nem sempre lida com caracteres cirílicos em nomes de arquivos. O Unicode oferece um excelente isolamento do código do aplicativo em relação à camada de banco de dados. Ele não permite a tipificação de tabelas em um nível baixo, e os erros de desenvolvedores juniores incompetentes no nível do banco de dados são impossíveis. Sim, outros erros cometidos por desenvolvedores juniores incompetentes são possíveis, mas a variedade de problemas é muito menor. Você me dirá agora que seu aplicativo foi projetado corretamente e que a camada de acesso ao banco de dados está devidamente isolada. Dê outra olhada no seu aplicativo Java corporativo personalizado. Observe com atenção e honestidade. Sua consciência não o incomoda? Então, fico feliz por você.
2. Numeração de documentos/diretórios. Certamente não é a mais flexível ou a melhor em 1C. Mas o que fazem em softwares bancários e sistemas de contabilidade personalizados é simplesmente impressionante. Às vezes, inserem uma identidade (e depois "ah, por que existem lacunas?"), outras vezes criam um gerador que funciona com bloqueio no nível do SGBD (e se torna um gargalo). De fato, é bastante difícil implementar essa tarefa aparentemente simples — um sistema de numeração de entidades de ponta a ponta, com unicidade definida por um determinado conjunto de chaves e prefixos — de uma forma que não bloqueie o banco de dados durante a entrada paralela de dados.
3. Identificadores de registros de banco de dados. A 1C tomou uma decisão ousada: todos os identificadores de link são completamente sintéticos, e ponto final. E não há problemas com bancos de dados distribuídos e exchanges. Os desenvolvedores de outros sistemas teimosamente improvisam algo como identidade (afinal, é mais curto!), arrastando-os para a interface gráfica até que chegue a hora de criar múltiplas instâncias vinculadas (e aí eles terão uma surpresa desagradável). Vocês não têm nada parecido? Sério?
4. Listas. O 1C possui alguns mecanismos bastante bons para percorrer listas (grandes) e navegar por elas. Deixe-me esclarecer logo de início: isso só funciona se você usar o mecanismo corretamente! Este é um problema bastante espinhoso e não foi resolvido da melhor forma: ou é intuitivo e simples (mas corre o risco de gerar conjuntos de registros enormes no cliente), ou a paginação é falha de alguma forma. Quem implementa paginação geralmente faz isso de maneira inadequada. Quem cria uma barra de rolagem adequada acaba bagunçando o banco de dados, o canal e o cliente.
5. Formulários gerenciados. É verdade que a interface do cliente web não é perfeita, mas funciona. Para muitos outros sistemas contábeis e bancários, no entanto, implementar uma estação de trabalho remota é um projeto de nível empresarial. Observação: felizmente, isso não afetará aqueles que inicialmente implementaram o sistema na web.
6. Aplicativo móvel. Recentemente, também é possível desenvolver aplicativos móveis dentro do mesmo ecossistema. É um pouco mais complexo do que com um cliente web, já que as especificidades de cada dispositivo exigem desenvolvimento personalizado. No entanto, você não precisa contratar uma equipe separada de desenvolvedores mobile. Se precisar de um aplicativo para necessidades internas da empresa (quando uma solução mobile para um problema corporativo é mais importante do que um design de interface chamativo), basta usar a mesma plataforma, que já vem pronta para uso.
7. Relatórios. Com isso, não me refiro a um sistema de BI com big data e atrasos no ETL. Refiro-me a relatórios operacionais que permitem avaliar a situação contábil em tempo real. Saldos, liquidações, discrepâncias de estoque e assim por diante. O 1C já vem com um sistema de relatórios integrado, com configurações flexíveis para agrupamentos, filtros e visualização pelo usuário. Sim, existem alternativas melhores no mercado. Mas elas não são soluções completas e, às vezes, o preço é mais alto do que o de uma solução completa. Na maioria das vezes, é o oposto: apenas relatórios, mas mais caros do que a plataforma completa e de qualidade inferior.
8. Formulários impressos. Tente usar o .NET para resolver o problema de enviar comprovantes de folha de pagamento aos funcionários por e-mail em formato PDF. Agora, que tal imprimir faturas? E salvar cópias delas em PDF? Para um usuário do 1C, gerar qualquer layout em PDF significa apenas uma linha de código a mais. Isso representa 40 segundos de trabalho, em vez de dias ou semanas em outra linguagem. Os layouts de formulários impressos no 1C são incrivelmente fáceis de desenvolver e poderosos o suficiente para competir com soluções pagas. Sim, as planilhas do 1C provavelmente não oferecem muitos recursos interativos e você não pode criar rapidamente um diagrama 3D com escala usando OpenGL. Mas isso é realmente necessário?

Esses são apenas alguns exemplos de como limitar a funcionalidade ou implementar soluções de compromisso acaba se revelando uma vantagem arquitetônica significativa a longo prazo. Mesmo uma solução de compromisso ou imperfeita já está disponível e é considerada como certa. Implementá-la de forma independente seria impossível (porque tais decisões precisam ser tomadas no início do projeto, e não há tempo para isso, e não há arquiteto de qualquer forma) ou exigiria várias iterações dispendiosas. Cada um desses pontos (e esta lista está longe de ser completa) pode ser mal executado e introduzir limitações que dificultam a escalabilidade. Em qualquer caso, como dono de uma empresa, você precisa garantir que seus programadores, ao construir um sistema do zero, sejam qualificados e saibam lidar bem com os detalhes sutis do sistema desde o início.

Sim, como qualquer outro sistema complexo, o próprio 1C possui soluções que, de uma forma ou de outra, dificultam a escalabilidade. No entanto, repito, considerando a combinação de fatores, o custo total de propriedade e a quantidade de problemas já resolvidos, não vejo um concorrente à altura no mercado. Pelo mesmo preço, você obtém uma estrutura de aplicação financeira, um servidor clusterizado e balanceado com interface de usuário e web, um aplicativo móvel, relatórios, integração e uma série de outros recursos. No mundo Java, você contrata uma equipe de front-end e back-end, depura problemas de baixo nível em código de servidor personalizado e paga separadamente por dois aplicativos móveis para dois sistemas operacionais móveis.

Não estou dizendo que o 1C resolverá todos os casos, mas para um aplicativo corporativo interno, quando não há necessidade de personalizar a interface do usuário com a marca, o que mais é necessário?

Mosca na sopa

Você pode ter a impressão de que o 1C vai salvar o mundo e que todos os outros métodos de desenvolvimento de sistemas corporativos estão errados. Isso não é verdade. Do ponto de vista empresarial, se você optar pelo 1C, além da rápida implementação no mercado, também deve considerar as seguintes desvantagens:

• Confiabilidade do servidor. Precisamos de especialistas de alta qualidade capazes de garantir seu bom funcionamento. Não tenho conhecimento de nenhum programa de treinamento oferecido pelo fornecedor para esses especialistas. Existem cursos preparatórios para o exame de "Especialista", mas, na minha opinião, são insuficientes.
• Suporte. Veja o ponto anterior. Para obter suporte do fornecedor, você precisa comprá-lo. Por algum motivo, isso não é comum no setor de TI. Mas com a SAP, é quase obrigatório e ninguém parece se importar. Sem suporte corporativo e um especialista na equipe, você fica sozinho com os problemas de TI.
• Afinal, não é possível fazer tudo com 1C. É uma ferramenta e, como qualquer ferramenta, tem suas limitações. Em um ambiente baseado em 1C, é altamente recomendável ter um arquiteto de sistemas que não tenha conhecimento avançado em 1C.
• Bons programadores em 1C não são mais baratos do que bons programadores em outras linguagens. No entanto, contratar programadores ruins é caro, independentemente da linguagem que utilizem.

Vamos esclarecer os detalhes.

• 1C é uma estrutura de desenvolvimento rápido de aplicações (RAD) para negócios, feita sob medida para essa finalidade.
• Um sistema de três camadas com suporte para os principais SGBDs, uma interface de usuário para o cliente, um ORM bastante eficiente e geração de relatórios.
• Possui amplas capacidades de integração com sistemas que oferecem recursos que o 1C não possui. Se você deseja aprendizado de máquina, use Python e transfira os resultados para o 1C via HTTP ou RabbitMQ.
• Você não precisa tentar fazer tudo o que o 1C oferece; você precisa entender seus pontos fortes e usá-los a seu favor.
• Os desenvolvedores que se dedicam a mexer com estruturas e dispositivos tecnológicos, e a retrabalhá-los a cada N anos para usar um novo motor gráfico, ficam entediados com o 1C. Tudo lá é muito conservador.
• Os desenvolvedores também estão entediados porque o fabricante demonstra pouca preocupação com eles. A linguagem é monótona, a IDE é fraca. Precisam de modernização.
• Por outro lado, desenvolvedores que não conseguem se divertir usando e aprendendo outra tecnologia que apreciam são maus desenvolvedores. Eles vão reclamar e migrar para outro ecossistema.
• Empregadores que não permitem que seus especialistas de TI escrevam nada em Python são maus empregadores. Eles perderão funcionários curiosos, que serão substituídos por programadores inexperientes que, embora concordem com tudo, arrastarão o software corporativo para o atoleiro. De qualquer forma, ele terá que ser reescrito, então talvez tivesse sido melhor investir um pouco em Python um pouco antes?
• A 1C é uma empresa comercial e implementa funcionalidades com base exclusivamente em seus próprios interesses e conveniência. Não se pode culpá-la por isso; as empresas são obrigadas a pensar no lucro; é a vida.
• A 1C lucra vendendo soluções para problemas de negócios, não para os problemas do desenvolvedor Vasya. Esses dois conceitos estão correlacionados, mas a prioridade é exatamente como eu disse. Quando o desenvolvedor Vasya estiver pronto para pagar por uma licença pessoal do 1C: ReSharper, isso acontecerá rapidamente. O "ReSharper" de A. Orefkov é a prova disso. Se o fornecedor o apoiasse em vez de combatê-lo, um mercado para software de desenvolvedores poderia surgir. Atualmente, existem apenas um concorrente e meio nesse mercado com resultados questionáveis, tudo porque a integração com IDEs é ruim e tudo é feito de forma improvisada.
• A prática de um especialista multitarefas se tornará coisa do passado. Os aplicativos modernos são volumosos demais para serem memorizados, tanto do ponto de vista do código quanto do ponto de vista de negócios. O servidor 1C também está se tornando mais complexo, tornando impossível acomodar todos os tipos de especialização em um único funcionário. Isso deve levar a um aumento na demanda por especialistas, o que, por sua vez, tornará a profissão de 1C mais atraente e resultará em salários mais altos. Se antes um Vasya três em um trabalhava por um salário, agora é preciso contratar dois Vasyas, e a competição entre eles pode impulsionar o nível geral de suas habilidades.

Conclusão

O 1C é um produto muito bom. Não conheço nenhum produto comparável na mesma faixa de preço. Por favor, me avisem nos comentários se souberem de algum. No entanto, a perda de desenvolvedores do ecossistema está se tornando cada vez mais perceptível, e é uma verdadeira "fuga de cérebros", não importa como se veja. A indústria precisa desesperadamente de modernização.
Se você é um desenvolvedor, não se prenda ao 1C e não pense que tudo é mágico em outras linguagens. Enquanto você for júnior, pode até ser. Mas assim que precisar resolver algo maior, terá que procurar soluções prontas por mais tempo e refiná-las com mais intensidade. Em termos da qualidade dos blocos de construção a partir dos quais você pode criar uma solução, o 1C é muito, muito bom.

E mais uma coisa: se você contratou um especialista em 1C, pode promovê-lo com confiança a analista líder. O conhecimento que ele tem da tarefa, da área temática e suas habilidades de decomposição são excelentes. Tenho certeza de que isso se deve justamente ao uso obrigatório de DDD no desenvolvimento em 1C. Eles são treinados para pensar principalmente no propósito da tarefa e nas conexões entre os objetos na área temática, além de possuírem formação técnica em tecnologias de integração e formatos de troca de dados.

Tenha em mente que não existe um modelo perfeito e cuide de si mesmo.
Bom para todos!

P.S.: Muito obrigado. espesúrico Agradeço a ajuda na preparação do artigo.

Apenas usuários registrados podem participar da pesquisa. Entrarpor favor

Você tem o nível 1C na sua empresa?

• 13,3%De forma alguma.71

• 30,3%Sim, mas apenas em algum lugar do departamento de contabilidade. Os sistemas principais estão em outras plataformas. 162

• 41,4%Sim, os principais processos de negócios são executados nele.

• 15,0%A tecnologia 1C precisa morrer, o futuro pertence à %technology_name%80

534 usuários votaram. 99 usuários se abstiveram.

Fonte: habr.com