1С - Добро і зло. Розміщення точок у холіварах навколо 1С

1С - Добро і зло. Розміщення точок у холіварах навколо 1С

Друзі та колеги, останнім часом на Хабрі почастішали статті з хейтом на адресу 1С як платформи для розробки та виступами її захисників. Ці статті позначили одну серйозну проблему: найчастіше, критики 1С критикують її з позиції «не подужали», лаючи проблеми, які де-факто легко вирішуються, і, навпаки, не зачіпаючи проблеми, які дійсно важливі, стоять обговорення і не вирішуються вендором . Вважаю, що має сенс провести тверезий та зважений огляд платформи 1С. Того, що вона вміє, того, що вона не вміє, того, що вона мала б робити, але не робить і, на солодке — те, що вона робить на ура, а ваші розробники на %technology_name% будуть робити сто років, викинувши на вітер не один річний бюджет.

В результаті, ви, як керівник чи архітектор, зможете отримати чітке розуміння — для якого завдання вам буде вигідно взяти 1С, і де її треба випалювати розпеченим залізом. Як розробник світу «не 1С» ви зможете подивитися, а що там такого в 1С є через що сир-бор. А як розробник 1С зможете порівняти свою систему з екосистемами інших мов і зрозуміти своє розташування в системі координат софтверної розробки.

Під катом - маса товстих начерків на 1С, на критиків 1С, на Java, .NET і взагалі ... Вентилятор заправлений, ласкаво просимо!

Про себе

Я знайомий із предметом розмови приблизно з 2004 року. Програмую напевно років з 6, з того самого моменту, як у мене з'явилася книжка про професора Фортрана з коміксами про кота, горобця та гусеницю. Я розбирав програми, які писав кіт із картинок у книжці та з'ясовував, що вони роблять. І так, справжнього комп'ютера тоді не було, але на розвороті книжки був намальований і я чесно натискав паперові кнопки, вводячи команди, підглянуті у кота Ікса.

Далі був БК0011 і Бейсік у школі, С++ та асемблери в універі, потім 1С, а потім стільки всього, що вже й згадувати лінощі. Останні 15 років я переважно займаюся 1С, не тільки в частині кодингу, а взагалі 1С. Постановка завдань, адмінство та девопс сюди ж. Останні 5 років займаюся суспільно корисною діяльністю в плані розвитку інструментів розробки та автоматизації для інших 1С-ників, пишу статті та книжки.

Визначимося з предметом обговорення

Для початку давайте визначимося, про що піде мова, оскільки під літерами «1С» можна зрозуміти багато всього. В даному випадку, під літерами «1С» ми розумітимемо виключно фреймворк розробки «1C: Підприємство» сучасної, восьмої версії. Ми не багато говоритимемо про фірму-виробника та її політику (але трохи-таки доведеться), Ми не обговорюватимемо конкретні додатки, написані із застосуванням цього фреймворку. Технологія окремо, програми aka конфігурації окремо.

Високоврівнева архітектура 1С: Підприємства

Я не дарма згадую слово "фреймворк". З погляду розробника платформа 1С це саме фреймворк. І ставитись до нього треба саме як до фреймворку. Вважайте, що це Spring або ASP.NET, який виконується деяким середовищем виконання (JVM або CLR відповідно). Так вийшло, що у світі звичайного програмування («не 1С») поділ на фреймворки, віртуальні машини та конкретні програми виходить природним, тому що ці компоненти зазвичай розробляються різними виробниками. У світі 1С ж не прийнято виділяти в явному вигляді фреймворк розробки і власне рантайм, крім того, конкретні додатки, написані із застосуванням фреймворку, в основному, також розроблені самою ж фірмою 1С. У результаті виникає якась плутанина. Тому, в рамках статті нам доведеться розглянути 1С одразу з кількох сторін та класифікувати її за декількома координатними осями. І в кожній осі координат ми покладемо по лопаті коричневої речовини розглянемо особливості, переваги та недоліки рішення.

Погляди на 1С

1С для покупця

Покупець набуває системи автоматизації, де він зможе швидко вирішити завдання автоматизації власного бізнесу. Бізнес може бути маленьким скринькою, а може бути великим холдингом. Зрозуміло, що потреби цих бізнесів різні, але підтримується і те й інше єдиною кодовою базою платформи.

Для покупця 1С це швидкий time-to-market. Швидкий. Швидше, ніж на Java, C# або JS. В середньому. По лікарні. Зрозуміло, що сайт-візитка на реакті вийде краще, але бекенд WMS-системи швидше запуститься на 1С.

1С як інструмент

Кожне технологічне рішення має межі застосування. 1С це не мова загального призначення, вона не живе окремо від свого фреймворку. 1С доцільно застосовувати коли вам потрібно:

  • серверний додаток
  • додаток, де фігурують фінанси
  • з готовим UI, ORM, Reporting, XML/JSON/COM/PDF/YourDataTransferingFormat
  • з підтримкою фонових процесів та завдань
  • із системою безпеки на основі ролей
  • зі скриптованою бізнес-логікою
  • з можливістю швидкого створення прототипу та низьким time-to-market

1З вам не потрібно, якщо ви хочете:

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

1С як фірма-виробник

Варто розуміти, в чому полягає бізнес фірми 1С як виробника софту. Фірма 1С продає розв'язання проблем бізнесу за рахунок автоматизації. Різного бізнесу, великого чи маленького, але вона продає саме це. Засобом досягнення цієї мети є бізнес-додатки. Для бухгалтерії, для обліку зарплати та ін. Для написання цих програм фірма використовує власну платформу розробки бізнес-додатків. Спеціально заточену під поширені завдання цих самих бізнес-додатків:

  • облік фінансів
  • легка кастомізація бізнес-логіки
  • широкі можливості інтеграції у гетерогенних IT-ланшафтах

Як виробник, фірма 1С вважає, що саме така стратегія дозволяє працювати з партнерами та клієнтами у режимі win-win. Можна сперечатися з цим, але приблизно так фірма себе просуває: готові вирішення проблем бізнесу, які можна швидко кастомізувати силами партнерів та вбудувати у будь-який IT-ландшафт.

Усі претензії чи хотівки до 1С, як до фреймворку, варто розглядати виключно через цю призму. "Хочемо ООП в 1С" кажуть розробники. «Скільки буде нам коштувати підтримка ООП у платформі, чи це допоможе нам збільшити продажі коробок?», каже фірма 1С. Відкриває свою «призму» продажу вирішення проблем бізнесу:

— Гей, бізнес, хочеш, щоб у твоїй 1С було ОВП?
— Це допоможе мені вирішити проблеми?
- Хтозна…
— Тоді не треба

Це підхід може бути хорошим або поганим, залежно від того, хто на нього дивиться, але він просто такий. Говорячи про те, що в 1С немає фічі Х, треба розуміти, що її немає не просто так, а в контексті вибору «вартість реалізації vs розмір профіту».

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

«Насправді одинесники щосили використовують найкращі патерни, ретельно відібрані дбайливими методистами та розробниками платформи 1С.
Коли ти пишеш свій тупий код для простенької керованої форми, насправді ти юзаєш model-view-controller с double-way data binding в three-layered-data-app-engine, присмачений high level object-relation-mapping на базі declarative metadata description, що має свій platform-independent query language, з declarative data-driven user interface, complete transparentі serialization і domain-oriented program language.

У чому розробники 1С відрізняються від західних колег, то це в піарі. Ті люблять будь-які фігні дати гучне ім'я і носитися з нею, як з писаною торбою.»
А. Орефков

Платформа 1С має класичну 3-ланкову архітектуру, в центрі якої сервер додатків (або його емуляція за мало грошей для дрібних крамарів). Як СУБД застосовується або MS SQL або Postgres. Є ще підтримка Oracle і IBM DB2 але це, швидше за езотерика, ніхто не знає що буде, якщо впроваджувати 1С на цих базах під середнім і високим навантаженням. Вважаю, не знає цього і сама фірма 1С.

Як клієнтська частина виступає або тонкий клієнт, що встановлюється на машину користувача, або веб-клієнт. Ключова особливість - програмісти не пишуть 2 різних коди, вони пишуть один додаток однією мовою, а ви можете виставити його в браузері, якщо є бажання або потреба. Хто там хотів справжнього фулстека та єдиної мови для фронту та бекенду, node.js? У них до кінця так і не вдалося зробити однаково. Справжній фулстек існує, але писати доведеться на 1С. Іронія долі, такі справи 🙂

У режимі браузера працює також хмарне SaaS рішення 1С: Fresh, в якому можна не купувати 1С, а взяти дрібну базу собі в оренду та вести там облік продажів шаурми. Просто в браузері, не встановлюючи та не налаштовуючи собі нічого.

Крім того, є легаси-клієнт, який в 1С називають «звичайний додаток». Легасі воно і є легасі, ласкаво просимо у світ додатків 2002 року, а ми все-таки про сучасний стан екосистеми.

Серверна частина 1С підтримує кластеризацію та масштабується за допомогою додавання нових машин у кластер. Тут зламано чимало копій і це буде окремий розділ у статті. Якщо коротко, то це не зовсім те, що і додати пару точно таких же інстансів позаду HAProxy.

Фреймворк прикладної розробки використовує власну мову програмування, яка приблизно нагадує злегка покращений VB6, перекладений російською мовою. Людям, які ненавидять все російське, які не вірять, що «if» перекладається, як «якщо» пропонується другий варіант синтаксису. Тобто. за бажання на 1С можна писати так, що на вигляд від VB не відрізнити.

1С - Добро і зло. Розміщення точок у холіварах навколо 1С

Ось ця сама мова програмування і є основною причиною хейту 1С-ників у бік своєї платформи. Скажімо прямо, не безпідставно. Мова замислювалася, як максимально проста, покликана виконати мантру «DEVELOPERS, DEVELOPERS» у масштабах хоча б СНД. Комерційна суть такого рішення, як на мене, проглядається чітко: більше розробників, більше охоплення ринку. Це відбулося за різними оцінками від 45% до 95%. Відразу скажу, що писати тією мовою, якою думаєш — реально легше. А я знаю чимало мов програмування.

З мови, мабуть, і почнемо.

Мова програмування 1С

Одночасно сильне та слабке місце системи. Забезпечує легке входження, читабельність. З іншого боку, не оновлювався з моменту виходу версії 8 у 2002 році та морально застарів. Хтось скаже «головний недолік — немає ОВП» і не матиме рації. По-перше, ОВП не любить не лише Нуралієва, а й Торвальдса. А по-друге, ОВП таки є.

З погляду розробника, у його розпорядженні є фреймворк з базовими класами, що відображаються на СУБД. Розробник може взяти базовий клас «Довідник» та успадкувати від нього довідник «Клієнти». Може додати до нього нові поля класу, наприклад, ІПН та Адреса, а також, якщо потрібно, може перевизначити (override) методи базового класу, наприклад метод OnWrite/ПріЗаписи.

Фреймворк складено в такий спосіб, що глибше успадкування потрібно рідко, і обмеження в ОВП, мій погляд, має сенс. 1С орієнтується на Domain Driven Development і змушує думати, в першу чергу, про предметну область розроблюваного рішення і це добре. Відсутня не тільки спокуса, а й необхідність писати 10 різних DTO та ViewModel тільки для того, щоб десь показати якісь дані з домену. Розробник 1С оперує завжди однією сутністю, не забиваючи собі контекст сприйняття десятком класів зі схожими назвами, що представляють ту саму сутність, але з іншого боку. Будь-яке .NET додаток, наприклад, буде обов'язково містити п'ят-другий ViewModel-ї та DTO для серіалізації в JSON і передачі даних з клієнта на сервер. І приблизно 10-15% коду вашої програми займе перекладення даних з одного класу в інший ручками або милицями на зразок AutoMapper. Цей код треба написати і програмістам заплатити за його створення та супровід.

Виходить, що мову 1С складно розвивати, не ускладнивши її до рівня мейнстрімних мов, втративши таким чином перевагу простоти. Яке ж по суті вирішується завдання вендора: видати типове рішення, яке зможе кастомізувати будь-який відловлений на вулиці студент із належним рівнем якості (тобто кейс охоплення від кіоску до великого заводу виконується). Якщо ти ларьок - візьми студента, якщо ти завод - візьми гуру у партнера-внедренца. Те, що партнери-впроваджувачі продають студентів за ціною гуру, це не проблема фреймворку. Архітектурно фреймворк повинен вирішувати завдання і тих, і інших, код типових конфігурацій (які ми продали бізнесу з обіцянкою кастомізації) має вміти розуміти студент, а гуру і так що хочеш зрозуміє.

Чого, на мій погляд, реально не вистачає в мові, що змушує писати більше, ніж можна було б, те, що марить час, оплачуваний замовником.

  • Можливість типізації на рівні, наприклад, TypeScript (як наслідок більш розвинені засоби аналізу коду в IDE, рефакторинг, менше образливих косяків)
    Наявність функцій як об'єктів першого класу. Трохи більш складна концепція, але кількість boilerplate-code із типових можна було б сильно скоротити. Розуміння коду студентом, імхо, навіть підвищилося б за рахунок скорочення обсягу
  • Літерали універсальних колекцій, ініціалізатори. Те саме — зниження обсягу коду, який треба написати та/або переглянути очима. Наповнення колекцій це over 9000% часу програмування на 1С. Писати це без синтаксичного цукру довго, дорого та error-prone. Взагалі, кількість LOC у рішеннях на 1С перевершує всі мислимі межі в порівнянні з доступними відкритими фреймворками і взагалі всіх ваших ентерпрайз Джав разом узятих. Мова багатослівна, а це вироджується в обсяг даних, пам'ять, гальма IDE, час, гроші.
  • конструкції finally У мене є гіпотеза, що ця конструкція відсутня через те, що не підібрали вдалого перекладу її російською мовою 🙂
  • Власних типів даних (без ООП) аналогів Type з VB6. Дозволить не типізувати структури за допомогою коментарів у БСП та чарівних методів, що конструюють ці структури. Отримуємо: менше коду, підказку через точку, швидше розв'язання задачі, менше помилок по друкарських помилках та відсутнім властивостям структур. Зараз типізація структур користувача лежить повністю на команді розробки Бібліотеки Стандартних Підсистем, яка, на честь для себе, ретельно пише коментарі щодо очікуваних властивостей структур параметрів, що передаються.
  • Відсутність цукру під час роботи з асинхронними викликами на веб-клієнті. callback-hell у вигляді Обробка Оповіщення це тимчасове милице, викликане раптовою зміною API основних браузерів, але жити так весь час — не можна, перевага «розуміння студентом» асинхронного коду втрачається все сильніше. Додайте сюди жодну підтримку цієї парадигми до основної IDE і все стане ще гірше.

Це з насущних проблем, зрозуміло, що список може бути куди більшим, але не треба забувати, що це все-таки не мова загального призначення, там не треба багатопоточності, лямбда-функцій, доступу до GPU та швидких обчислень з плаваючою точкою. Це мова скриптування бізнес-логіки.

Програмістові, який вже багато попрацював із цією мовою, заглянув у js або c# стає нудно в рамках цієї мови. Це факт. Йому потрібен розвиток. На іншій чаші терезів у вендора лежить вартість реалізації зазначених фіч vs збільшення виручки після їх впровадження. Тут у мене немає жодної інформації про те, що в очах фірми зараз переважує.

Середовище розробки

Тут все також не гладко. Серед розробки існує дві. Перша, це входить до складу Конфігуратор. Друга — середовище Enterprise Development Tools, що розробляється на базі Eclipse, скорочено EDT.

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

Крім того, обсяг середнього типового рішення з того часу зріс у кілька разів і сьогодні IDE тупо не справляється з тим обсягом коду, яким її годують. Юзабіліті та можливості рефакторингу навіть не на нулі, вони в мінусі. Все це не додає ентузіазму розробникам і вони мріють звалити в інші екосистеми і продовжувати говнокодити там, але вже в приємному середовищі, яке не плює тобі в морду своєю поведінкою.

Як альтернатива, пропонується написана з нуля IDE, побудована на базі Eclipse. Там вихідники, як і в будь-якому іншому софті живуть у вигляді текстових файлів, зберігаються в GIT, гілки-пулреквести, все ось це. З мінусів — уже котрий рік не виходить із статусу бети, хоча з кожним релізом стає дедалі краще. Про мінуси EDT не писатиму, що сьогодні мінус, завтра виправлена ​​фіча. Актуальність такого опису швидко зійде нанівець. На сьогоднішній день розробляти в EDT можна, але незвично потрібно бути готовим до деякої кількості багів IDE.

Якщо подивитися на ситуацію через згадану «призму 1С», то виходить приблизно таке: продаж коробок вихід нової IDE не підвищує, але відтік DEVELOPERS-ів можливо скоротить. Що чекає на екосистему з погляду комфорту розробника сказати складно, але Microsoft вже одного разу профукав мобільних розробників, надто пізно запропонувавши їм свої послуги.

Управління розробкою

Тут все суттєво краще, ніж у написанні коду, особливо останнім часом, коли стараннями спільноти на світ були витягнуті проблеми автоматизації адміністрування, запущені прототипи, що закликають викинути на смітник сховище 1С та користуватися git, швидким blame, code-review, статичним аналізом, автодеплоєм та etc. У платформу було додано багато фічі, що підвищують рівень автоматизації завдань розробки. Однак, всі ці фічі були додані тільки і виключно для розробки власних великих продуктів, коли стало очевидним, що без автоматизації вже ніяк. З'явилися авто-злиття, тристороннє порівняння KDiff-ом і таке інше. На гітхабі запущено gitconverter, який, поклавши руку на серце, був ідеологічно стягнутий з проекту gitsync, але доопрацьований під процеси компанії-вендора. Завдяки впораним хлопцям із open-source автоматизація розробки в 1С зрушила з мертвої точки. Відкрите API конфігуратора, імхо, зрушила б моральну відсталість основний IDE.

На сьогоднішній день, зберігання вихідних 1С в git з прив'язкою коммітів до завдань в Jira, ревью в Crucible, накатка кнопкою з Дженкінса та звіти Allure про тестування коду в 1С і навіть статичний аналіз у SonarQube — це вже далеко не новина, а, швидше, мейнстрім у компаніях, де є багато розробки на 1С.

адміністрування

Ось тут є багато про що сказати. По-перше, це, звичайно ж сервер (кластер серверів 1С). Чудова штука, але за рахунок того, що це повністю чорна скринька, документована досить докладно, але специфічним чином – подолати запуск безперебійної роботи в режимі highload на кількох серверах – це доля обраних, які носять медаль із написом «Експерт з технологічних питань». Варто зазначити, що в принципі адміністрування сервера 1С не відрізняється від адміністрування якого-небудь іншого сервера. Ця мережна багатопотокова програма, що споживає пам'ять, процесор і дискові ресурси. Надає широкі можливості для збору телеметрії та діагностики.

Проблему тут становить те, що вендор не пропонує нічого особливого щодо готових рішень для цієї самої діагностики. Так, є 1С: КВП та ЦУП, вони навіть і непогані, але сильно платні і є не у всіх. У співтоваристві є низка напрацювань щодо підключення графани, заббікса, ELK та іншого з типового набору адміну, але єдиного рішення, яке влаштує більшість, — ні. Завдання чекає на свого героя. А якщо ви бізнес, який планує запуститися на кластері 1С, вам потрібен Експерт. Свій усередині або з боку, але потрібний. Це нормально, що є окрема роль, з компетенціями роботи сервера, не кожен 1С-ник повинен це знати, просто треба розуміти, що така роль потрібна. Візьмемо, наприклад, SAP. Там програміст, швидше за все, навіть зі стільця не встане, якщо йому на сервері програм запропонують щось налаштувати. Він може тупо не вміти, і йому соромно не буде. У методології SAP є окрема роль співробітника під це. Чомусь у галузі 1С вважається, що це має поєднуватися в одному співробітнику за ту саму зарплату. Це помилка.

Мінуси сервера 1С

Мінус рівно один – надійність. Або, якщо завгодно, непередбачуваність. Раптові дивацтво поведінки сервера вже стали притчею в язицех. Універсальний засіб — зупинка сервера та чищення всіх кешів навіть описані в настільній книзі експерта і навіть рекомендований батничок, який робить це. Якщо у вас 1С почала робити те, чого не повинна робити навіть теоретично, - час чистити кеш сеансових даних. За моєю оцінкою, людей, які вміють експлуатувати сервер 1С без цієї процедури - у всій країні людини три, і вони не діляться секретами, т.к. із цього живуть. Можливо, їхній секрет у тому, що вони чистять сеансові дані, але нікому не говорять про це, гигиг.

В іншому, сервер 1С це така ж програма, як будь-яке інше і адмініструється приблизно так само, за допомогою читання документації та стуку в бубон.

Docker

Корисність застосування контейнеризованого сервера 1С у продакшені поки що не доведена. Сервер не кластеризується простим додаванням нід за балансувальником, що зводить переваги контейнеризації продакшена до мінімуму, а практика успішної експлуатації в контейнерах у режимі highload не напрацьована. У результаті докером+1С користуються тільки розробники для підняття тестових середовищ. Там це зело корисне, застосовується, дозволяє грати з сучасними технологіями та відпочивати від зневіри конфігуратора.

Комерційна складова

З погляду інвестицій - 1С дозволяє закрити завдання швидкого запуску бізнес-ідей за рахунок широких можливостей прикладних класів. 1С з коробки дає вельми гідний Reporting, інтеграцію з будь-чим, веб-клієнт, мобільний клієнт, мобільний додаток, підтримку різних СУБД, в т.ч. безкоштовних, кросплатформеність як сервера, так і клієнтських частин, що встановлюються. Так, UI додатків буде жовтим, іноді це мінус, але далеко не завжди.
Вибираючи 1С, бізнес отримує набір програмних рішень, що дозволяють будувати дуже широкий спектр додатків, а також безліч розробників на ринку, які хочуть грошей менше ніж джавісти і при цьому швидше видають результат.

Наприклад, завдання надіслати клієнту рахунок у PDF вирішується за годину роботи студента. Те саме завдання на .NET вирішується покупкою пропрієтарної бібліотеки, або парою днів або тижнів кодингу суворого бородатого розробника. Іноді, і те, й інше відразу. І так, я говорив лише про формування PDF. Ми не сказали, звідки цей рахунок узагалі з'явиться. Веб-фронтендер повинен надолужити форму, куди оператор вб'є дані, бекендер повинен буде створити dto-моделі для передачі JSON, моделі для складування в базу даних, структуру самої бази даних, міграції на неї, формування графічного відображення цього самого рахунку і тільки потім - PDF. На 1С, все завдання цілком, з повного нуля, робиться за годину рівно.

Повноцінна облікова система дрібного кіоску з одним бізнес-процесом купив/продав робиться години за 3. Зі звітністю з продажу, обліком товару за купівельною та продажною цінами, у розбивці за складами, контролем прав доступу, веб-клієнтом та мобільним додатком. Гаразд, про додаток загнув, із додатком не за 3 години, за шість.

Скільки часу займе це завдання у розробника .NET з моменту встановлення visual studio на чистий комп'ютер до демонстрації замовнику? А щодо вартості розробки? Отож.

Сильні сторони 1С, як платформи

1С сильна не тому, що в ній щось конкретне найкраще у світі. Навпаки, у кожній окремій підсистемі можна знайти цікавіший аналог у світовому софті. Однак, за сукупністю факторів, я не бачу платформи аналогічної 1С. Саме в цьому полягає комерційний успіх. Плюси платформи розкидані по ній і добре видно, коли бачиш, як це робиться в інших платформах. В основному, це навіть не фічі, а навпаки - відмова від фічі на користь однієї конкретної парадигми. Декілька прикладів:

  1. Unicode. Що, млинець, може бути простіше? Не треба в 2019 році використовувати однобайтні ASCII кодування (крім інтеграції з дрімучою legacy). Нізащо. Але ж немає. Все одно хтось в якійсь таблиці використовує однобайтний varchar і додаток матиме проблеми з кодуванням. У 2015 році у gitlab відвалювалася LDAP-авторизація через неправильну роботу з кодуванням, у JetBrains IDE досі не скрізь працює з кирилицею в іменах файлів. 1С якісна ізоляція прикладного коду від шару роботи з БД. Там не можна типізувати таблиці на низькому рівні і косяки малокомпетентних джуніорів на рівні БД там неможливі. Так, там можливі інші косяки малокомпетентних джуніорів, але різноманітність проблем значно менша. Ви мені зараз скажете, що у вас програма спроектована правильно і шар доступу до БД ізольований як належить. Подивіться у свій корпоративний самописний Java-додаток ще раз. Уважно і чесно. Совість не мучить? Тоді я за вас радий.
  2. Нумерація документів/довідників. В 1С вона точно не гнучка і не найкраща. Але що роблять у банківському софті і в самописних системах обліку — ну це просто морок. То identity встромлять (і потім "ой, а чому у нас дірки"), то навпаки, зроблять генератор, який працює з блокуванням на рівні СУБД (і стане вузьким місцем). Насправді, досить складно зробити це, здавалося б, просте завдання - наскрізний нумератор сутностей, з розрізом унікальності по деякому набору ключів, префіксацією, так щоб це не блокувало базу при паралельному введенні даних.
  3. Ідентифікатори записів у БД. 1С ухвалила вольове рішення - всі ідентифікатори посилань абсолютно синтетичні і все тут. І немає проблем із розподіленими базами та обмінами. Розробники інших систем уперто ліплять щось типу identity (вона ж коротше!), тягнуть їх у GUI, поки не прийде час робити кілька пов'язаних інстансів (і тут на них чекає відкриття). У вас такого нема? Чесно?
  4. Списки. У 1С є досить вдалі механізми перегортання (великих) списків та навігації за ними. Відразу обмовлюся - при правильному застосуванні механізму! Взагалі тема досить неприємна, вона ідеально не вирішується: тут або інтуїтивно і просто (але ризик величезних рекордсетів на клієнті), або тій чи іншій кривизні пейджингу. Ті, хто робить пейджинг часто роблять його криво. Ті, хто робить чесний скроллбар – кладуть базу даних, канал та клієнта.
  5. Керовані форми. Безперечно, у веб-клієнті інтерфейс працює не те щоб ідеально. Але працює. А ось для багатьох інших облікових та банківських систем зробити віддалене робоче місце – це проект рівня підприємства. Застереження: на щастя для тих, хто спочатку зробив на Інтернеті, це не торкнеться.
  6. Мобільний додаток. З недавніх пір ви можете писати і мобільні додатки, перебуваючи в тій самій екосистемі. Тут трохи складніше, ніж з веб-клієнтом, специфіка пристроїв змушує писати спеціально під них, проте, ви не наймаєте окрему команду мобільних розробників. Якщо потрібно додаток для внутрішніх потреб компанії (коли мобільне рішення корпоративного завдання важливіше за жовтий дизайн UI) — просто користуєтеся тією ж платформою з коробки.
  7. Reporting. Під цим словом я розумію не BI-систему з великими даними та лагом на ETL-процес. Йдеться про оперативні звіти персоналу, що дозволяють оцінити стан обліку тут і зараз. Залишки, взаєморозрахунки, пересортицю тощо. У 1С з коробки поставляється система звітів з гнучким налаштуванням угруповань, фільтрів, візуалізації на стороні користувача. Так, на ринку є аналоги крутіші. Але не в рамках рішення все-в-одному і за ціну часом вище, ніж рішення все-в-одному. А частіше навіть навпаки: тільки reporting, але дорожче, ніж платформа, і гірше за якістю.
  8. Друкарські форми. Ну вирішите на .NET завдання відправки зарплатної відомості в PDF співробітникам на пошту. Нині ж завдання друку товарних накладних. А зі збереженням їх копій у той же PDF? Для 1С-ника виведення у PDF будь-якого макета це +1 рядок коду. А значить + 40 секунд робочого часу, замість днів чи тижнів іншою мовою. Макети друкованих форм в 1С дуже зручні в розробці і досить потужні, щоб конкурувати з платними аналогами. Так, напевно, в табличних документах 1С не так багато можливостей з інтерактиву, не можна швидко отримати 3D діаграму з масштабування за допомогою OpenGL. Але воно точно треба?

Все це лише жменька прикладів, коли обмеження функціональних можливостей або реалізація з компромісами виявляється важливою архітектурною перевагою у майбутньому. Навіть компромісний чи не найефективніший варіант - він уже є в коробці і сприймається як даність. Його самостійна реалізація буде або неможливою (бо такі рішення треба приймати на початку проекту, а там не до того, та й взагалі архітектора немає), або декількома дорогими ітераціями. У кожному з наведених пунктів (а це далеко не повний перелік архітектурних рішень) можна накосячити і закласти обмеження, що блокують масштабування. У будь-якому випадку вам, як бізнесменові, треба переконатися, що ваші програмісти, роблячи «систему з нуля», мають прямі руки і зроблять тонкі системні моменти відразу добре.

Так, як і в будь-якій іншій складній системі сама 1С так само має рішення, які в тих чи інших аспектах блокують масштабування. Однак, повторюся, за сукупністю факторів, за вартістю володіння, за кількістю вже заздалегідь вирішених проблем — я не бачу на ринку гідного конкурента. За одну і ту ж ціну ви отримуєте фреймворк фінансового додатку, кластеризований балансований сервер, з UI та веб-мордою, з мобільним додатком, зі звітністю, інтеграцією та купою ще чогось. У світі Java ви наймаєте команду фронт-енду, бекенда, налагоджуєте низькорівневі косяки самописного серверного коду і окремо платите за 2 мобільні програми під 2 мобільні ОС.

Я не кажу, що 1С вирішить усі кейси, але для внутрішнього корпоративного застосування, коли не треба брендувати UI — що ще потрібно?

Ложка дьогтю

Напевно, склалося враження, що 1С врятує світ та інші способи написання корпоративних систем — неправильні. Це зовсім негаразд. З точки зору бізнесмена, якщо ви вибираєте 1С, то, крім швидкого time-to-market, необхідно врахувати і наступні мінуси:

  • Надійність сервера. Потрібні справді якісні фахівці, здатні забезпечувати його безперебійну роботу. Мені невідома готова програма підготовки таких спеціалістів від вендора. Є курси для підготовки до складання іспиту «Експерт», але цього, як на мене, недостатньо.
  • Підтримка. Дивись попередній пункт. Щоб мати підтримку від вендора, її треба купити. Чомусь у галузі 1С це не прийнято. А у SAP майже обов'язково до придбання і нікого це не бентежить. Без корпоративної підтримки і без експерта в штаті - з глюками 1С можна залишитися наодинці.
  • Все-таки на 1С не можна зробити зовсім усе. Це інструмент і як кожен інструмент має межі застосовності. У ландшафті з 1С дуже бажано мати «не 1С-нутого» системного архітектора.
  • Хороші 1С-ники коштують не дешевше за хороших програмістів іншими мовами. Хоча, поганих програмістів наймати дорого незалежно від мови, якою вони пишуть.

Розставимо крапки

  • 1С це фреймворк швидкої розробки додатків (RAD) для бізнесу та заточений під це.
  • Триланка з підтримкою основних СУБД, клієнтським UI, дуже непоганим ORM та репортингом
  • Широкі можливості щодо інтеграції із системами, які вміють те, чого 1С не вміє. Бажаєте машинного навчання - візьміть Python, а результат злийте в 1С http або RabbitMQ
  • Не треба прагнути робити все на 1С, треба розуміти її сильні сторони та використовувати їх у своїх цілях
  • Розробники, які тяжіють до копання в технологічних фремворках-гаджетах, і до переробки кожні N років на новий двигун - в 1С нудьгують. Там усе дуже консервативно.
  • Нудьгують розробники і через дуже маленьку турботу про них з боку фірми виробника. Нудна мова, слабка IDE. Вони потребують модернізації.
  • З іншого боку, розробники, які не можуть знайти собі розвагу за допомогою застосування та вивчення іншої технології, що подобається, — погані розробники. Вони будуть нити і перейшовши в іншу екосистему.
  • Роботодавці, які не дозволяють своїм 1С-никам запиляти щось на Пітоні, — погані роботодавці. Вони втратять співробітників з допитливим розумом, а на їхнє місце прийдуть monkey-кодери, які, будучи з усім згодні, затягнуть корпоративний софт у болото. Його все одно доведеться переписати, то чи могло б краще трохи раніше трохи інвестувати в Пітон?
  • 1С комерційна компанія і впроваджує фічі виходячи з власних інтересів та доцільності. Її не можна в цьому звинувачувати, бізнес повинен думати про прибуток, таке життя
  • 1С заробляє тим, що продає вирішення проблем бізнесу, а не розроблювача Васі. Ці два поняття корелюють, але пріоритет саме такий, який я сказав. Коли розробник Вася готовий платити за особисту ліцензію на 1С: Решарпер — він з'явиться досить швидко, «Решарпер» О. Орефкова тому підтвердження. Якби вендор підтримував його, а не боровся з ним — дивишся виник ринок софту для розробників. Зараз на цьому ринку півтора гравця з сумнівними результатами і через те, що інтеграція з IDE негативна і все робиться на милицях.
  • Практика фахівця-багатоверстатника піде в небуття. Сучасні програми занадто об'ємні, щоб пам'ятати їх і з боку коду, і з боку бізнесового використання. Сервер 1С також ускладнюється, утримати всі види експертизи в одному співробітнику не можна буде. Це має спричинити затребуваність фахівців, а значить привабливість професії 1С-ника та зростання окладів. Якщо раніше Вася три-в-одному працював за одну зарплату, то тепер потрібно наймати двох Вась та конкуренція серед Вась може підштовхнути загальне зростання їхнього рівня.

Висновок

1С дуже гідний продукт. У своєму ціновому діапазоні я взагалі не знаю аналогів, напишіть у коментарях, якщо такі є. Однак, відтік розробників з екосистеми стає все помітнішим, а це «витік мозку», як не крути. Галузь прагне модернізації.
Якщо ви розробник - не зациклюйтесь на 1С і не думайте, що в інших мовах все чарівно. Поки ти джун може бути. Як тільки треба вирішувати щось більше — готові рішення доведеться шукати довше і допилювати інтенсивніше. За рівнем якості «кубиків» з яких можна побудувати рішення — 1С дуже хороша.

І ще якщо до вас прийшов найматися 1С-нік, то 1С-ніка можна сміливо ставити на посаду ліда аналітиків. Розуміння завдання, предметної галузі, навичок декомпозиції вони розвинене прекрасно. Впевнений, що це за рахунок примусового застосування DDD у створенні на 1С. Людина навчена думати про сенс завдання в першу чергу, про зв'язки між об'єктами предметної області, при цьому має технічний бекграунд за інтеграційними технологіями та форматами обміну даними.

Усвідомлюйте, що ідеального фреймворку не існує і бережіть себе.
Всім добра!

PS: велике дякую speshuric за допомогу у підготовці статті.

Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.

Ви маєте 1С на підприємстві?

  • 13,3%Взагалі нет.71

  • 30,3%Є, але лише у бухгалтерії десь. Основні системи на інших платформах162

  • 41,4%Так, основні бізнес-процеси працюють на ній221

  • 15,0%1С має померти, майбутнє за %technology_name%80

Проголосували 534 користувачів. Утрималися 99 користувачів.

Джерело: habr.com

Додати коментар або відгук