1C - Добро и зло. Подреждане на точки в холивари около 1C

Приятели и колеги, напоследък в Habré зачестиха статии с омраза към 1C като платформа за разработка и изказвания на нейни защитници. Тези статии идентифицираха един сериозен проблем: най-често критиците на 1C го критикуват от позицията на „не го овладяват“, карайки проблеми, които де факто са лесно решени, и, напротив, не засягат проблеми, които са наистина важни, струващи обсъждане и не се решават от продавача. Вярвам, че има смисъл да се направи трезвен и балансиран преглед на платформата 1C. Какво може да прави, какво не може, какво трябва да прави, но не прави, и за десерт какво прави с гръм и трясък и вашите разработчици от %technology_name% ще правят сто години, като го изхвърлят повече от един годишен бюджет.

В резултат на това вие, като мениджър или архитект, ще можете да получите ясно разбиране за това каква задача ще бъде от полза за вас да използвате 1C и къде трябва да се изгори с гореща ютия. Като разработчик в света, който не е 1C, вие ще можете да видите какво има в 1C, което предизвиква шум. И като разработчик на 1C ще можете да сравните вашата система с екосистемите на други езици и да разберете местоположението си в координатната система за разработка на софтуер.

Под разфасовката има много дебели атаки срещу 1C, срещу критиците на 1C, срещу Java, .NET и изобщо... Вентилаторът е пълен, добре дошли!

За мен

Запознат съм с предмета на разговора от приблизително 2004 г. Програмирам може би от 6-годишен, от момента, в който получих книга за професор Фортран с комикси за котка, врабче и гъсеница. Анализирах програмите, които котката написа от снимките в книгата, и разбрах какво правят. И да, по това време нямах истински компютър, но имаше рисунка на разгъването на книгата и аз честно натисках хартиените бутони, въвеждайки командите, които бях шпионирал на котката X.

След това имаше BK0011 и BASIC в училище, C++ и асемблери в университета, след това 1C и след това толкова много други неща, които ме мързи да си спомням. През последните 15 години се занимавам основно с 1C, не само по отношение на кодирането, но и с 1C като цяло. Задаване на задачи, администрация и devops тук. През последните 5 години се занимавах със социално полезни дейности по отношение на разработването на инструменти за разработка и автоматизация за други потребители на 1C, писане на статии и книги.

Нека решим предмета на дискусията

Първо, нека да определим за какво ще говорим, тъй като буквите „1C“ могат да означават много неща. В този случай с буквите „1C“ ще имаме предвид изключително рамката за разработка „1C: Enterprise“ на модерната, осма версия. Няма да говорим много за производителя и неговите политики (но няма да обсъждаме конкретни приложения, написани с помощта на тази рамка). Технологията е отделна, приложенията, известни още като конфигурации, са отделни.

Архитектура на високо ниво 1C: Enterprise

Не напразно споменавам думата „рамка“. От гледна точка на разработчика платформата 1C е точно рамка. И трябва да го третирате точно като рамка. Мислете за него като за Spring или ASP.NET, изпълняван от някаква среда за изпълнение (съответно JVM или CLR). Така се случва, че в света на конвенционалното програмиране („не 1C“) разделянето на рамки, виртуални машини и специфични приложения е естествено, поради факта, че тези компоненти обикновено се разработват от различни производители. В света на 1C не е обичайно да се разграничава изрично рамката за разработка и самата среда за изпълнение, освен това специфични приложения, написани с помощта на рамката, също се разработват главно от самата 1C. В резултат на това възниква известно объркване. Следователно, в рамките на статията, ще трябва да разгледаме 1C от няколко страни наведнъж и да го класифицираме по няколко координатни оси. И във всяка координатна ос ще поставим лопата кафяво вещество и ще разгледаме характеристиките, предимствата и недостатъците на съществуващото решение.

Гледни точки на 1C

1C за купувача

Купувачът закупува система за автоматизация, с която може бързо да реши проблемите с автоматизирането на собствения си бизнес. Бизнесът може да бъде малък щанд или може да бъде голям холдинг. Ясно е, че нуждите на тези бизнеси са различни, но и двата се поддържат от единна кодова база на платформа.

За купувача на 1C това е бързо време за пускане на пазара. Бърз. По-бързо от Java, C# или JS. Средно аритметично. Около болницата. Ясно е, че уебсайт с визитна картичка, използващ React, ще се окаже по-добър, но бекендът на WMS система ще стартира по-бързо на 1C.

1C като инструмент

Всяко технологично решение има граници на приложимост. 1C не е език с общо предназначение; той не живее отделно от своята рамка. Препоръчително е да използвате 1C, когато имате нужда от:

• сървърно приложение
• приложение, където се появяват финанси
• с готов UI, ORM, Reporting, XML/JSON/COM/PDF/YourDataTransferingFormat
• с поддръжка за фонови процеси и задания
• със сигурност, базирана на роли
• със скриптова бизнес логика
• с възможност за бързо създаване на прототип и кратко време за пускане на пазара

Нямате нужда от 1C, ако искате:

• машинно обучение
• GPU изчисления
• компютърна графика
• математически изчисления
• CAD система
• обработка на сигнала (звук, видео)
• highload http разговори със стотици хиляди rps

1C като производствена компания

Струва си да разберете какъв е бизнесът на 1C като производител на софтуер. Компанията 1C продава решения за бизнес проблеми чрез автоматизация. Различни бизнеси, големи или малки, но това е, което тя продава. Средството за постигане на тази цел са бизнес приложенията. За счетоводство, ТРЗ и т.н. За писането на тези приложения компанията използва собствена платформа за разработка на бизнес приложения. Специално пригоден за общи задачи на същите тези бизнес приложения:

• финансово счетоводство
• лесно персонализиране на бизнес логиката
• широки възможности за интеграция в разнородни ИТ среди

Като производител, 1C вярва, че това е стратегията, която ви позволява да работите с партньори и клиенти в печеливш режим. Можете да спорите с това, но това е приблизително начинът, по който компанията се рекламира: готови решения за бизнес проблеми, които могат бързо да бъдат персонализирани от партньорите и интегрирани във всеки ИТ пейзаж.

Всички твърдения или желания за 1C като рамка трябва да се разглеждат изключително през тази призма. „Искаме OOP в 1C“, казват разработчиците. „Колко ще ни струва поддръжката на ООП в платформата, ще ни помогне ли това да увеличим продажбите на кутии?“ казва 1C. Отваря своята „призма“ за продажба на решения за бизнес проблеми:

- Хей, бизнес, искате ли ООП във вашия 1C?
- Това ще ми помогне ли да реша проблемите си?
- Кой знае...
- Тогава няма нужда

Този подход може да бъде добър или лош в зависимост от това кой го гледа, но това е просто така. Говорейки за факта, че няма функция X в 1C, трябва да разберете, че тя не е там по причина, а в контекста на избора „разходи за внедряване спрямо сума на печалбата“.

Технологична класификация

„Всъщност Odinesniks правят всичко възможно да използват най-добрите модели, внимателно подбрани от грижовни методолози и разработчици на платформата 1C.
Когато пишете своя глупав код за проста управлявана форма, в действителност използвате модел-изглед-контролер с двупосочно обвързване на данни в трислойна-данни-приложение машина, овкусени картографиране на обектни релации на високо ниво на основата декларативно описание на метаданникато има своя собствена независим от платформата език за заявки, ° С декларативен потребителски интерфейс, управляван от данни, пълна прозрачна сериализация и домейн-ориентиран програмен език.

Където разработчиците на 1C се различават от своите западни колеги, е в PR. Те обичат да дават на всяка глупост голямо име и да тичат наоколо с нея като мръсна торба.
А. Орефков

Платформата 1C има класическа 3-степенна архитектура, в центъра на която е сървърът на приложенията (или негова емулация за малко пари за дребни търговци). Като СУБД се използва MS SQL или Postgres. Има и поддръжка за Oracle и IBM DB2, но това е доста езотерично; никой не знае какво ще се случи, ако внедрите 1C на тези бази данни при средно и високо натоварване. Вярвам, че самият 1C не знае това.

Клиентската част е или тънък клиент, инсталиран на машината на потребителя, или уеб клиент. Основната характеристика е, че програмистите не пишат 2 различни кода, те пишат едно приложение, на един език, и можете да го показвате в браузъра, ако има желание или нужда. Кой иска истински пълен стек и един език за предната и задната част, node.js? Те така и не успяха да направят абсолютно същото до края. Съществува истински пълен стек, но ще трябва да го напишете в 1C. Ирония на съдбата, такива неща :)

Облачното SaaS решение 1C:Fresh също работи в режим на браузър, в който не можете да закупите 1C, а да наемете малка база данни и да следите продажбите на shawarma там. Само в браузъра, без да инсталирате или конфигурирате нищо.

Освен това има наследен клиент, който в 1C се нарича „обикновено приложение“. Наследството си е наследство, добре дошли в света на приложенията през 2002 г., но ние все още говорим за текущото състояние на екосистемата.

Сървърната част на 1C поддържа групиране и мащабиране чрез добавяне на нови машини към клъстера. Тук са счупени доста копия и ще има отделен раздел в статията за това. Накратко, това не е съвсем същото като добавянето на няколко точно същите екземпляра зад HAProxy.

Рамката за разработка на приложения използва собствен език за програмиране, който приблизително прилича на леко подобрен VB6, преведен на руски. За хора, които мразят всичко руско, които не вярват, че „ако“ се превежда като „ако“, се предлага втората опция за синтаксис. Тези. Ако желаете, можете да го напишете в 1C по такъв начин, че да е неразличим от VB.

Този език за програмиране е основната причина за омразата на прякорите на 1C към тяхната платформа. Нека си признаем, не без причина. Езикът беше замислен възможно най-опростен, предназначен да изпълни мантрата „РАЗРАБЪЧИТЕЛИ, РАЗРАБОТЧИЦИ“ в мащаб поне в ОНД. Търговската същност на такова решение според мен е ясно видима: повече разработчици, по-голямо покритие на пазара. Това се сбъдна, според различни оценки от 45% до 95%. Веднага ще кажа, че писането на езика, който мислите, е наистина по-лесно. И знам доста езици за програмиране.

Да започнем с езика.

Език за програмиране 1C

Едновременно силната и слабата страна на системата. Осигурява лесно въвеждане и четливост. От друга страна, той не е актуализиран от пускането на версия 8 през 2002 г. и е морално остарял. Някой ще каже „основният недостатък е, че няма ООП“ и ще сгреши. Първо, ООП не харесва не само Нуралиев, но и Торвалдс. И второ, ООП все още съществува.

От гледна точка на разработчика, той има на разположение рамка с базови класове, показани в СУБД. Разработчикът може да вземе базовия клас „Директория“ и да наследи директорията „Клиенти“ от него. Той може да добавя към него нови класови полета, например INN и Address, а също така, ако е необходимо, може да замени (замени) методите на базовия клас, например метода OnWrite/AtRecord.

Рамката е проектирана по такъв начин, че рядко е необходимо по-дълбоко наследяване и ограничението в OOP според мен има смисъл. 1C се фокусира върху разработката, управлявана от домейн, и ви кара да мислите преди всичко за предметната област на разработваното решение и това е добре. Няма не само изкушение, но и нужда да пишете 10 различни DTO и ViewModel, само за да покажете някъде някои данни от домейна. Разработчикът на 1C винаги работи с един обект, без да претрупва контекста на възприятието с дузина класове с подобни имена, представляващи един и същ обект, но от различна страна. Всяко .NET приложение, например, задължително ще съдържа пет или два ViewModels и DTO за сериализиране в JSON и прехвърляне на данни от клиент към сървър. И приблизително 10-15% от кода на вашето приложение ще бъдат изразходвани за прехвърляне на данни от един клас в друг с помощта на химикалки или патерици като AutoMapper. Този код трябва да бъде написан и на програмистите трябва да бъде платено, за да го създадат и поддържат.

Оказва се, че езикът 1C е труден за разработване, без да се усложнява до нивото на масовите езици, като по този начин се губи предимството на простотата. Каква по същество е решена задачата на продавача: да издаде стандартно решение, което всеки ученик, хванат на улицата, може да персонализира с необходимото ниво на качество (т.е. завършен е случай, покриващ от щанд до голяма фабрика). Ако сте щанд, вземете ученик; ако сте фабрика, вземете гуру от вашия партньор в изпълнението. Фактът, че изпълнителните партньори продават студенти на цената на гуру, не е проблем с рамката. Архитектурно рамката трябва да решава проблемите и на двете, кодът на стандартните конфигурации (които продадохме на бизнеса с обещанието за персонализиране) трябва да може да бъде разбран от студент, а гуруто трябва да може да разбере каквото искате.

Това, което според мен наистина липсва на езика, което ви кара да пишете повече, отколкото можете, е това, което губи време, платено от клиента.

• Възможност за въвеждане на ниво, например TypeScript (в резултат на това по-развити инструменти за анализ на код в IDE, рефакторинг, по-малко обидни задръствания)
  Наличие на функции като първокласни обекти. Малко по-сложна концепция, но количеството типичен шаблонен код може да бъде значително намалено. Разбирането на кода от ученика, IMHO, дори би се увеличило поради намаляването на обема
• Литерали за универсална колекция, инициализатори. Същото нещо - намаляване на количеството код, който трябва да бъде написан и/или погледнат с очите ви. Попълването на колекциите отнема над 9000% от времето за програмиране на 1C. Писането на това без синтактична захар е дълго, скъпо и податливо на грешки. Като цяло количеството LOC в решенията на 1C надхвърля всички възможни граници в сравнение с наличните отворени рамки и като цяло всички ваши корпоративни Javas заедно. Езикът е многословен и това се изражда в количеството данни, памет, IDE спирачки, време, пари...
• накрая конструкции Имам хипотеза, че тази конструкция липсва поради факта, че не са намерили успешен превод за нея на руски :)
• Собствени типове данни (без OOP), аналози на Type от VB6. Това ще ви позволи да не въвеждате структури, като използвате коментари в BSP и магически методи, които конструират тези структури. Получаваме: по-малко код, подсказка чрез точка, по-бързо решение на проблема, по-малко грешки поради печатни грешки и липсващи свойства на структури. Сега въвеждането на потребителски структури почива изцяло на екипа за разработка на Standard Subsystem Library, който, за негова заслуга, внимателно пише коментари за очакваните свойства на предадените параметрични структури.
• Без захар при работа с асинхронни повиквания на уеб клиента. callback-hell под формата на ProcessingNotifications е временна патерица, причинена от внезапна промяна в API на основните браузъри, но не можете да живеете така през цялото време; предимството на „разбирането на асинхронния код от учениците“ се губи все повече и повече. Добавете липсата на поддръжка за тази парадигма в основната IDE и нещата стават още по-лоши.

Това е един от належащите проблеми, ясно е, че списъкът може да бъде много по-голям, но не трябва да забравяме, че това все още не е език с общо предназначение, не изисква многонишковост, ламбда функции, достъп до GPU и бърз изчисления с плаваща запетая. Това е скриптов език за бизнес логика.

Програмист, който вече е работил много с този език, разглежда js или c#, се отегчава в рамките на този език. Това е факт. Има нужда от развитие. От другата страна на скалата за доставчика е цената за внедряване на посочените функции спрямо увеличението на приходите след внедряването им. Тук нямам информация какво надделява в момента в очите на компанията.

Среда за развитие

И тук нещата не вървят гладко. Има две среди за разработка. Първият е конфигураторът, включен в доставката. Втората е среда Enterprise Development Tools или накратко EDT, разработена на базата на Eclipse.

Конфигураторът предоставя пълен набор от задачи за разработка, поддържа всички функции и е основната среда на пазара. Освен това е морално остарял, не се развива, според слуховете - поради размера на техническия дълг в себе си. Ситуацията може да се подобри чрез отваряне на вътрешен API (под формата на приятелство с Снежен човек А. Орефкова или на самостоятелна основа), но това не е така. Практиката показва, че общността ще напише свои собствени функции в IDE, стига доставчикът да не се намесва. Но имаме това, което имаме. Конфигураторът беше страхотен през 2004-2005 г., много напомняше на Visual Studio от онези времена, на места беше дори по-готин, но беше заседнал в онези времена.

Освен това обемът на средното стандартно решение е нараснал няколко пъти оттогава и днес IDE просто не може да се справи с количеството код, с който се захранва. Използваемостта и възможностите за рефакторинг дори не са нулеви, те са на червено. Всичко това не добавя ентусиазъм към разработчиците и те мечтаят да се преместят в други екосистеми и да продължат да кодират глупости там, но в приятна среда, която не ви плюе в лицето с поведението си.

Като алтернатива се предлага IDE, написана от нулата, изградена върху Eclipse. Там източниците, както във всеки друг софтуер, живеят под формата на текстови файлове, съхраняват се в GIT, клонове за изтегляне на заявки и всичко това. Недостатъкът е, че не е напуснал бета статус от много години, въпреки че става все по-добър с всяко издание. Няма да пиша за недостатъците на EDT, днес е минус, утре е фиксирана функция. Уместността на такова описание бързо ще изчезне. Днес е възможно да се развива в EDT, но е необичайно да сте подготвени за определен брой грешки в IDE.

Ако погледнете ситуацията през гореспоменатата „1C призма“, ще получите нещо подобно: пускането на новата IDE не увеличава продажбите на кутии, но изтичането на РАЗРАБОТЧИЦИ може да бъде намалено. Трудно е да се каже какво очаква екосистемата по отношение на комфорта на разработчиците, но Microsoft вече прецака мобилните разработчици, като им предложи услугите си твърде късно.

Управление на развитието

Всичко тук е значително по-добро, отколкото при писането на код, особено напоследък, когато усилията на общността извадиха на светло проблемите на автоматизацията на администрацията, стартираха прототипи, призоваващи за изхвърляне на 1C хранилището в купчината на боклука и използване на git, бързо обвинение, преглед на кода , статичен анализ, автоматично разгръщане и др. Към платформата са добавени много функции, които повишават нивото на автоматизация на задачите за разработка. Въпреки това, всички тези функции бяха добавени само и изключително за разработването на нашите собствени големи продукти, когато стана очевидно, че не можем без автоматизация. Имаше автоматични сливания, тристранно сравнение с KDiff и всичко това. Стартиран в Github gitconverter, който, честно казано, беше идеологически отвлечен от проекта gitsync, но модифициран, за да отговаря на процесите на компанията доставчик. Благодарение на упоритите момчета от отворения код, автоматизацията на разработката в 1C стартира. Отворен API за конфигуратора, IMHO, също би изместил моралната изостаналост на основната IDE.

Днес съхраняване на източници на 1C в git с ангажименти, свързани с проблеми в Jira, рецензии в Crucible, бутон за натискане от Jenkins и доклади Allure за тестване на код в 1C и дори статичен анализ в SonarQube - това далеч не е новина, а по-скоро мейнстрийм в компаниите, където има много разработка на 1C.

администрация

Тук има какво да се каже. Първо, това е, разбира се, сървър (1C сървърен клъстер). Чудесно нещо, но поради факта, че е напълно черна кутия, документирана достатъчно подробно, но по специфичен начин - овладяването на стартирането на непрекъсната работа в режим на високо натоварване на няколко сървъра е част от няколко избрани, които носят медал с надпис „Експерт по технологични въпроси”. Струва си да се отбележи, че по принцип администрирането на 1C сървър не се различава от администрирането на всеки друг сървър. Това е мрежово базирано, многопоточно приложение, което консумира памет, процесор и дискови ресурси. Предоставя широки възможности за събиране на телеметрия и диагностика.

Проблемът тук е, че продавачът не предлага нищо особено по отношение на готови решения за точно тази диагностика. Да, има 1C: Instrumentation and Control Center, дори са доста добри, но са много скъпи и не всеки ги има. Има редица разработки в общността за свързване на Grafana, Zabbix, ELK и други неща от стандартния администраторски набор, но няма нито едно решение, което да отговаря на мнозинството. Задачата очаква своя герой. И ако сте бизнес, който планира да стартира на 1C клъстер, имате нужда от експерт. Собствен отвътре или отвън, но ти трябва. Нормално е да има отделна роля с компетенции за работа със сървър, не всеки потребител на 1C трябва да знае това, просто трябва да разберете, че такава роля е необходима. Да вземем за пример SAP. Там програмист най-вероятно дори няма да стане от стола си, ако бъде помолен да конфигурира нещо на сървъра на приложения. Може просто да е глупав и няма да се срамува. В методологията на SAP има отделна роля на служител за това. По някаква причина в индустрията 1C се смята, че това трябва да се комбинира в един служител за същата заплата. Това е заблуда.

Недостатъци на 1C сървър

Има точно един минус - надеждност. Или, ако предпочитате, непредсказуемост. Внезапното странно поведение на сървъра вече стана тема за разговори. Универсално средство за защита - спиране на сървъра и изчистване на всички кешове - дори е описано в наръчника на експерта и дори се препоръчва пакетна книга, която прави това. Ако вашата система 1C започне да прави нещо, което дори теоретично не трябва да прави, време е да изчистите кеша на данните за сесията. Според моята оценка има само трима души в цялата страна, които знаят как да управляват 1C сървър без тази процедура и не споделят тайни, защото... живеят от това. Може би тяхната тайна е, че почистват данните от сесиите, но не казват на никого за това, пич.

В противен случай сървърът 1C е същото приложение като всяко друго и се администрира почти по същия начин, като четете документацията и чукате на тамбурата.

докер

Полезността от използването на контейнеризиран 1C сървър в производството все още не е доказана. Сървърът не е групиран чрез просто добавяне на възли зад балансира, което намалява ползите от производствената контейнеризация до минимум и практиката на успешна работа в контейнери в режим на високо натоварване не е установена. В резултат на това само разработчиците използват Docker+1C за настройка на тестови среди. Там е много полезен, приложен, позволява ви да играете с модерни технологии и да си починете от унинието на конфигуратора.

Търговски компонент

От инвестиционна гледна точка, 1C ви позволява да решите проблема с бързото стартиране на бизнес идеи поради широките възможности на класовете приложения. 1C извън кутията дава много прилично отчитане, интеграция с всичко, уеб клиент, мобилен клиент, мобилно приложение, поддръжка на различни СУБД, вкл. безплатни, междуплатформени както сървърни, така и инсталирани клиентски части. Да, потребителският интерфейс на приложенията ще бъде жълт, понякога това е минус, но не винаги.
Избирайки 1C, бизнесът получава набор от софтуерни решения, които им позволяват да създават много широка гама от приложения, както и много разработчици на пазара, които искат по-малко пари от Javaists и в същото време дават резултати по-бързо.

Например, задачата за изпращане на PDF фактура до клиент може да бъде решена за един час студентска работа. Същият проблем в .NET може да бъде решен чрез закупуване на собствена библиотека или няколко дни или седмици кодиране от строг, брадат разработчик. Понякога и двете наведнъж. И да, говорех само за генериране на PDF. Дори не сме казали откъде ще дойде тази сметка. Уеб фронтендърът трябва да създаде формуляр, в който операторът ще въвежда данните, бекендърът ще трябва да създаде dto модели за прехвърляне на JSON, модели за съхранение в базата данни, структура на самата база данни, миграция към нея, формиране на графичен показване на същия акаунт и едва след това - PDF. На 1C цялата задача, от нулата, се изпълнява точно за един час.

Пълноценна счетоводна система за малък щанд с един бизнес процес закупено/продадено за 3 часа с отчитане на продажбите, отчитане на стоки по покупни и продажни цени, разбити по склад, контрол на правата на достъп, уеб клиент и мобилно приложение. . Добре, забравих за приложението, като приложението не след 3 часа, след шест.

Колко време ще отнеме тази задача на .NET разработчик от инсталирането на визуално студио на чист компютър до демонстрирането му на клиента? Какво ще кажете за цената на разработката? Същото нещо.

Силните страни на 1C като платформа

1C е силен не защото има нещо специфично за него, което е най-доброто в света. Напротив, във всяка отделна подсистема можете да намерите по-интересен аналог в световния софтуер. Въпреки това, въз основа на комбинация от фактори, не виждам платформа, подобна на 1C. Тук се крие търговският успех. Предимствата на платформата са разпръснати из нея и са най-ясно видими, когато видите как това се прави в други платформи. По принцип това дори НЕ са характеристики, а напротив - отхвърляне на характеристики в полза на една конкретна парадигма. Няколко примера:

1. Unicode. Какво, по дяволите, може да бъде по-просто? Няма нужда да се използват еднобайтови ASCII кодировки през 2019 г. (освен за интеграция с древни наследени). Никога. Но не. Както и да е, някой в ​​някаква таблица използва еднобайтов varchar и приложението ще има проблеми с кодирането. През 2015 г. LDAP авторизацията на gitlab се провали поради неправилна работа с кодировки; JetBrains IDE все още не работи с кирилица в имената на файловете. 1C осигурява висококачествена изолация на кода на приложението от слоя база данни. Там е невъзможно да се въвеждат таблици на ниско ниво и там са невъзможни задръствания на некомпетентни младши на ниво база данни. Да, там може да има други проблеми от некомпетентни юноши, но разнообразието от проблеми е много по-малко. Сега ще ми кажете, че вашето приложение е проектирано правилно и нивото за достъп до базата данни е изолирано, както трябва да бъде. Погледнете отново вашето корпоративно персонализирано Java приложение. Отблизо и честно. Мъчи ли ви съвестта? Тогава се радвам за теб.
2. Номериране на документи/справочници. В 1C определено не е най-гъвкавият и не е най-добрият. Но това, което правят в банковия софтуер и в самостоятелно написаните счетоводни системи - е, това е просто мрак. Или идентичността ще бъде заседнала (и тогава „ох, защо имаме дупки“), или напротив, ще направят генератор, който работи със заключване на ниво СУБД (и ще стане тясно място). Всъщност е доста трудно да се направи тази на пръв поглед проста задача - изброител от край до край на обекти, със секция за уникалност, базирана на определен набор от ключове, префикс, така че да не блокира базата данни при паралелно въвеждане на данни .
3. Идентификатори на записи в базата данни. 1C взе волево решение - всички идентификатори на връзки са абсолютно синтетични и това е всичко. И няма проблеми с разпределените бази данни и борси. Разработчиците на други системи упорито създават нещо като самоличност (това е по-кратко!), Влачат ги в GUI, докато дойде време да създадат няколко свързани екземпляра (и тогава те ще бъдат открити). Нямате ли това? Честно казано?
4. Списъци. 1C има доста успешни механизми за прелистване на (големи) списъци и навигиране през тях. Веднага да направя резервация - с правилно използване на механизма! Като цяло темата е доста неприятна, не може да бъде решена идеално: или е интуитивна и проста (но има риск от огромни записи на клиента), или странирането е с една или друга кривота. Тези, които правят страниране, често го правят криво. Тези, които правят честен скролбар, добавят база данни, канал и клиент.
5. Управлявани формуляри. Без съмнение в уеб клиента интерфейсът не работи перфектно. Но работи. Но за много други счетоводни и банкови системи създаването на отдалечено работно място е проект на ниво предприятие. Отказ от отговорност: за щастие на тези, които първоначално са го направили в мрежата, това няма да се отрази.
6. Мобилно приложение. Наскоро можете също да пишете мобилни приложения, докато сте в същата екосистема. Тук е малко по-сложно, отколкото с уеб клиент; спецификата на устройствата ви принуждава да пишете специално за тях, но въпреки това не наемате отделен екип от мобилни разработчици. Ако имате нужда от приложение за вътрешните нужди на компания (когато мобилното решение на корпоративен проблем е по-важно от жълтия дизайн на потребителския интерфейс), просто използвате същата платформа от кутията.
7. Докладване. С тази дума нямам предвид BI система с големи данни и забавяне на ETL процеса. Това се отнася до отчетите на оперативния персонал, които ви позволяват да оцените състоянието на счетоводството тук и сега. Салда, взаимни разплащания, прекласифициране и др. 1C излиза от кутията със система за отчитане с гъвкави настройки за групиране, филтри и визуализация от страна на потребителя. Да, на пазара има по-хладни аналози. Но не в рамките на решение „всичко в едно“ и на цена, понякога по-висока от решението „всичко в едно“. И по-често дори е обратното: само отчитане, но по-скъпо от цялата платформа и по-лошо като качество.
8. Формуляри за печат. Е, използвайте .NET, за да решите проблема с изпращането на фишове за заплати в PDF формат на служителите по имейл. И сега задачата за отпечатване на фактури. Какво ще кажете за запазване на техните копия в същия PDF? За псевдоним на 1C извеждането на всяко оформление в PDF е +1 ред код. Това означава + 40 секунди работно време, вместо дни или седмици на друг език. Оформленията на печатни формуляри в 1C са невероятно лесни за разработване и достатъчно мощни, за да се конкурират с платените аналози. Да, вероятно няма много интерактивни възможности в 1C електронни таблици; не можете бързо да получите 3D диаграма с помощта на OpenGL. Но наистина ли е необходимо?

Това са само няколко примера, при които ограничаването на функционалността или внедряването на компромиси се оказва важно архитектурно предимство в бъдеще. Дори компромис или не най-ефективният вариант - той вече е в кутията и се приема за даденост. Независимото му изпълнение ще бъде или невъзможно (тъй като такива решения трябва да се вземат в началото на проекта, а няма време за това и изобщо няма архитект), или няколко скъпи итерации. Във всяка от изброените точки (и това не е пълен списък с архитектурни решения) можете да прецакате и да въведете ограничения, които блокират мащабирането. Във всеки случай, вие, като бизнесмен, трябва да сте сигурни, че вашите програмисти, когато правят „система от нулата“, имат здрави ръце и ще се справят незабавно добре с фините системни проблеми.

Да, както във всяка друга сложна система, самата 1C също има решения, които блокират мащабирането в определени аспекти. Въпреки това, повтарям, въз основа на комбинация от фактори, цената на притежание и броя на проблемите, които вече са решени предварително, не виждам достоен конкурент на пазара. За същата цена получавате рамка за финансово приложение, клъстерен балансиран сървър, с UI и уеб интерфейс, с мобилно приложение, с отчети, интеграция и куп други неща. В света на Java вие наемате преден и бекенд екип, отстранявате грешки на ниско ниво от домашно написан сървърен код и плащате отделно за 2 мобилни приложения за 2 мобилни ОС.

Не казвам, че 1C ще реши всички случаи, но за вътрешно корпоративно приложение, когато няма нужда да брандирате потребителския интерфейс - какво друго е необходимо?

Полет в мехлема

Вероятно сте останали с впечатлението, че 1C ще спаси света и че всички други начини за писане на корпоративни системи са погрешни. Изобщо не е така. От гледна точка на бизнесмен, ако изберете 1C, тогава в допълнение към бързото време за пускане на пазара, трябва да вземете предвид следните недостатъци:

• Надеждност на сървъра. Необходими са наистина качествени специалисти, които да осигурят нейната непрекъсната работа. Не ми е известно да има готова програма за обучение на такива специалисти от доставчика. Има курсове за подготовка за експертен изпит, но това според мен не е достатъчно.
• Поддържа. Вижте предишния параграф. За да имате поддръжка от доставчика, трябва да го купите. По някаква причина това не е прието в 1C индустрията. А със SAP това е почти задължителна покупка и не притеснява никого. Без корпоративна поддръжка и без експерт в персонала можете да останете сами с проблемите на 1C.
• Все пак не можете да правите абсолютно всичко с 1C. Това е инструмент и като всеки инструмент има граници на приложимост. В пейзажа на 1C е много желателно да имате „не-1C“ системен архитект.
• Добрите 1C прякори не са по-евтини от добрите програмисти на други езици. Въпреки това, лошите програмисти са скъпи за наемане, независимо от езика, на който пишат.

Нека разделим точките

• 1C е рамка за бързо разработване на приложения (RAD) за бизнеса и е пригодена за това.
• Тристепенна връзка с поддръжка за основни СУБД, потребителски интерфейс на клиента, много добра ORM и отчитане
• Широки възможности за интеграция със системи, които могат да правят това, което 1C не може. Ако искате машинно обучение, вземете Python и изпратете резултата на 1C чрез http или RabbitMQ
• Няма нужда да се стремите да правите всичко с помощта на 1C, трябва да разберете силните му страни и да ги използвате за собствените си цели
• Разработчиците, които гравитират към копаене в джаджи на технологична рамка и препроектиране на всеки N години към нов двигател, са отегчени от 1C. Там всичко е много консервативно.
• Разработчиците също са отегчени, защото има много малко грижи за тях от производителя. Скучен език, слаба IDE. Те изискват модернизация.
• От друга страна, разработчиците, които не могат да намерят забавление чрез използване и изучаване на друга технология, която харесват, са лоши разработчици. Ще хленчат и ще се преместят в друга екосистема.
• Работодатели, които не позволяват на своите 1C прякори да пишат нещо на Python, са лоши работодатели. Те ще загубят служители с любознателни умове и на тяхно място ще дойдат кодери на маймуни, които, въпреки че са съгласни с всичко, ще завлекат корпоративния софтуер в блатото. Все пак ще трябва да се пренапише, така че може би е по-добре да инвестираме малко в Python малко по-рано?
• 1C е търговска компания и прилага функции единствено въз основа на собствените си интереси и целесъобразност. Не можете да я обвинявате за това, бизнесът трябва да мисли за печалбата, това е животът
• 1C прави пари, като продава решения за бизнес проблеми, а не за проблемите на разработчиците на Вася. Тези две концепции корелират, но приоритетът е точно това, което казах. Когато разработчикът Вася е готов да плати за личен лиценз за 1C: Resharper, той ще се появи доста бързо, „Resharper“ от А. Орефкова е доказателство за това. Ако доставчикът го поддържаше, а не се бореше срещу него, щеше да се появи пазар за софтуер за разработчици. Сега има един и половина играчи на този пазар със съмнителни резултати и всичко това, защото интеграцията с IDE е отрицателна и всичко се прави на патерици.
• Практиката на многомашинен оператор ще изчезне в забрава. Съвременните приложения са твърде големи за запомняне както от страна на кода, така и от страна на бизнес употребата. 1C сървърът също става все по-сложен; ще бъде невъзможно да се поддържат всички видове експертиза в един служител. Това трябва да доведе до търсене на специалисти, което означава привлекателността на професията 1C и увеличение на заплатите. Ако преди Вася работеше три в едно за една заплата, сега трябва да наемете двама Васи и конкуренцията между Васи може да стимулира общото нарастване на тяхното ниво.

Заключение

1C е много достоен продукт. В моя ценови диапазон изобщо не знам аналози, пишете в коментарите, ако има такива. Отливът на разработчици от екосистемата обаче става все по-осезаем и това е „изтичане на мозъци“, както и да го погледнете. Индустрията е гладна за модернизация.
Ако сте разработчик, не се вкопчвайте в 1C и не мислете, че всичко е магическо на други езици. Докато си младши може би. Щом трябва да се реши нещо по-мащабно, ще трябва по-дълго да се търсят готови решения и да се довършват по-интензивно. По отношение на качеството на „блоковете“, от които може да се изгради решение, 1C е много, много добър.

И още нещо - ако 1C псевдоним дойде при вас, за да наемете, тогава 1C псевдонимът може безопасно да бъде назначен на позицията на водещи анализатори. Тяхното разбиране на задачата, предметната област и уменията за разлагане е отлично. Сигурен съм, че това се дължи именно на принудителното използване на DDD в разработката на 1C. Човек е обучен да мисли преди всичко за значението на дадена задача, за връзките между обектите на предметната област и в същото време има технически опит в интеграционните технологии и форматите за обмен на данни.

Знайте, че идеалната рамка не съществува и се погрижете за себе си.
Браво на всички!

PS: Благодаря ви много спешурик за помощ при подготовката на статията.

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Имате ли 1C във вашето предприятие?

• 13,3%Съвсем не.71

• 30,3%Има, но само в счетоводството някъде. Основни системи на други платформи162

• 41,4%Да, върху него работят основните бизнес процеси221

• 15,0%1C трябва да умре, бъдещето принадлежи на %technology_name%80

534 потребители гласуваха. 99 потребители се въздържаха.

Източник: www.habr.com