Меня зовут Андрей Овсянкин, я – архитектор информационных систем. Периодически я меняю сферу деятельности и ухожу из 1С, но 1С при этом, как правило, из моей жизни никуда не уходит. Об этом и будет рассказ.
Для начала разберемся, в чем заключается работа программиста.
Программисты не нужны. Если вы мечтаете сменить сферу деятельности, нужно понимать, что программист – это капризный и дорогой посредник между бизнес-идеей и профитом.
Программиста терпят, потому что без него нельзя обойтись.
Код – это всего лишь инструмент реализации бизнес-идеи. У заказчика есть классная идея, он знает как заработать, но он вынужден мириться с тем, что ему нужно нанять программиста и терпеть, пока он все это напишет. Код – это инструмент реализации. Заказчику совершенно наплевать на каком языке его идея реализуется.
Например, если мы хотим повесить картину, что для этого нужно?
-
нужно взять дрель
-
просверлить дырку
-
забить гвоздь
-
повесить картину.
В этой последовательности есть лишняя деталь – это дрель. Она совершенно не нужна, потому что миру нужны дырки.
Если бы можно было пойти в магазин, купить пакет дырок, и прилепить их на стену, никто бы не додумался покупать дрель.
Программный код и программист в середине – ненужный посредник на пути к выручке.
Когда вы сверлите дырку под картину, то электрическое сопротивление обмотки двигателя дрели – неинтересная вам величина. То же самое с кодом и с фреймворками. Когда бизнес-заказчик заказывает какой-то код и автоматизацию, ему все равно на чем вы это будете делать. Ему нужен профит, а не язык программирования.
Если вы поменяете язык программирования, для бизнеса вы так и останетесь ИТ-отделом:
-
сроки и оценки – никуда не денутся;
-
баги и авралы, когда все сломалось, и все бегают как ошпаренные, – никуда не денутся;
-
нет никакой разницы, на каком языке вы делаете ошибки и опаздываете к дедлайну.
Даже с точки зрения удовольствия, работа программиста на другом языке совсем не отличается от работы программиста на 1С.
Как выглядит ИТ-отдел с точки зрения заказчика
Заказчик видит ИТ-отдел так:
-
всегда долго;
-
говорят непонятно;
-
делают не то;
-
постоянно возникают ошибки;
-
неудобный интерфейс;
-
да еще и дорого.
Обратите внимание, в этой формуле нет переменной «стек технологий».
Если вы думаете, что вредные и неправильные заказчики есть только у 1С-ников, вы ошибаетесь. Заказчики всегда одинаковые.
Опять же, в этой формуле нет переменной «стек технологий» – неважно, на чем вы будете писать: ваши заказчики всегда будут вас раздражать.
Если вы думаете, что перейдя в другой стек вы научитесь чему-то невиданному доселе у коллег-программистов, то вы тоже ошибаетесь.
Коллеги, которые пишут на других языках, не будут умнее вас. Они будут такими же, а может даже еще и хуже.
Я готов доказать тезисы, которые озвучил.
Расскажу свою историю – о том, как давным-давно программист 1С Андрей Овсянкин решил, что больше не хочет заниматься 1С и пойдет работать программистом на .NET.
Мой второй любимый язык программирования – это .NET. Первый – С++, а 1С – третий.
Я бросил 1С и устроился работать просто программистом: «Не хочу больше думать, хочу просто кодить в свое удовольствие. Просто отстаньте от меня, буду отдыхать».
Мою историю хорошо описывает название одной из книг Толкина – я сходил «туда и обратно».
1С-ники умнее, и я не шучу
В нашей отрасли во всех чатиках и форумах существуют такие мифы и легенды:
-
там интереснее работа;
-
там настоящая работа, а не только обслуживание бухгалтерии;
-
там больше платят;
-
1С – отстой;
-
на 1С нельзя сделать настоящее приложение.
На самом деле 1С-ники сильно умнее настоящих программистов. Я не шучу. Я там был.
Удивительно, но факт. «Настоящие» программисты слишком сильно заморачиваются с технической реализацией, сложностью алгоритмов, соблюдением SOLID, мыслями о том, сколько времени занимает добавление в список. В этот момент они теряют из вида понимание того, зачем им вообще ставится задача.
«Настоящие» программисты реально не понимают, что нужны не код и не программа, а достижение цели.
Они правда не понимают, зачем им поставлена задача. Они этим не интересуются. Из-за этого они теряют смысл того, что они пишут, и пишут не то.
В силу своей специфики работы у 1С-ника есть встроенный в голову хороший аналитик.
1С-ники привыкли работать от процесса и бизнес-функций – они сначала думают «зачем делать», а потом уже «что делать».
Джаверы, дотнетчики и ПХПешники делают наоборот. Они не знают «зачем» делают. Они читают спецификацию ТЗ, и по ней работают. Если ТЗ написано плохо, то результат идет на помойку. Почему-то в их отраслях это считается нормой – я не знаю, почему так происходит.
Порядка 80% программистов на PHP, на Java, на .NET просто берут задачу и делают. Им сказали: «Взорви все» – они возьмут и взорвут, «удали таблицу» – удалят. Потом внезапно: «Ой, что-то пошло не так, я не так понял смысл». Потом на запуске модули не стыкуются, пересылается не то и, в целом, происходит караул.
А главное, что код уже написан. Заказчику остается только притвориться, что он именно это и хотел, потому что зарплата уже оплачена и время потрачено.
Ограничения 1С работают во благо
Нам очень повезло с фреймворком 1С. Он очень помогает в мелочах, о которых мы даже не задумываемся, а те ребята ломают копья.
Обычно говорят, что в 1С нельзя сделать все, а вот на языке «таком-то» можно сделать все, что захочешь. Наверное, это правда. Но вы не просто сможете сделать все, а вам придется делать все.
Работа с базой данных
Посмотрим, как это проявляется в работе с базами данных.
Ограничения, которые накладывает на нас платформа 1С, – работают на самом деле во благо. Они не позволяют нам нагородить кучу ненужных сложностей и костылей.
-
Например, в 1С только одна база данных.
-
Все второстепенные источники данных работают либо через интеграцию, либо через веб-сервисы, либо как внешние источники данных.
-
Нет соблазна налепить интеграцию «прочитаем из базы соседей».
В других промышленных решениях такие интеграции в порядке вещей:
-
Никто не ограничивает количество баз, с которыми может работать приложение.
-
Там часто бывают интеграции по типу: «У наших соседей лежит база. Мы прямо из нее почитаем». Одна выборка из одной базы, другая – из другой, и выводим.
-
Потом другая команда удалила или переименовала какую-нибудь колонку в своей базе, и у вас все отвалилось. Они не будут вас уведомлять об изменениях. Это же их база, они не знают, что туда кто-то полез.
Поэтому начинают придумывать регламенты – «прежде, чем реструктуризировать таблицу, вы должны написать письмо на всех». Только никто эти письма не читает.
Для них это – норма жизни. Нам даже в голову не придет этим заниматься.
ORM-модель
То же самое с объектно ориентированной моделью – ORM-моделью, когда записи базы данных превращаются в объекты (справочники контрагентов и т.д.).
По моему мнению, в 1С ORM работает близко к идеалу:
-
это происходит легко и прозрачно – мы пользуемся объектной моделью и даже не задумываемся о том, как эти данные забираются из базы;
-
1С не пытается замести под ковер язык SQL – язык запросов 1С SQL-подобный;
-
С самых первых курсов, с младых ногтей всех 1С-ников натаскивают на производительность запросов и их оптимизацию.
1С-ников этому учат, а в других стеках работать с ORM не учат. Из-за этого промышленный ORM выглядит как костыли и ад.
-
Они пытаются совсем спрятать от программиста язык SQL. В результате, он даже не знает порой как писать на SQL.
-
То, что ему ORM-ка генерирует в виде запроса, очень легко превращается в миллион запросов в цикле, и он даже об этом не подозревает. Например, .NET-овская ORM-ка запросто может сделать запрос в цикле миллион раз и выдаст всего лишь незаметное предупреждение в лог (который будут читать, только когда продакшен встанет колом, ведь на машине программиста с тремя тестовыми записями в БД – все было хорошо).
-
Хочешь наименование ссылки – пиши явно. Для 1С наименование ссылки – это примитивная вещь: выбрал ссылки из базы данных, выводишь, а наименования сами подтянутся. У других программистов так не работает. Им нужно писать явно везде, каждый раз, всегда. Хочешь текстовое наименование? Выбирай текстовое наименование. С одной стороны, это вроде правильно, но с другой стороны сильно напрягает, и ты начинаешь скучать по 1С.
Еще один недостаток тех ORM-ок, у которых метаданные описываются в коде.
Объекты, которые моделирует программист – это не бизнес-объекты, не бизнес-модель, и не прообраз записи в базу. Это какие-то франкенштейны, в которых половина полей служебные, «чтобы в базу легло», а половина – «чтобы бизнес-логика работала».
Другие программисты не умеют строить модели данных и очень плохо проводят границы между доменами – где объект начинается, и где заканчивается.
Например, на слайде показан класс Customer (контрагент), у которого есть поля:
-
Id (ссылка)
-
Name (наименование)
-
BankId (ссылка на банк)
-
Bank (банк-объект)
-
Orders (заказы)
Вас не удивляет, что банк-объект находится сразу в контрагенте? Или что список заказов, который сделал контрагент, тоже находится сразу в объекте «контрагент»?
Мы в 1С понимаем, что список заказов не является частью контрагента – это просто его связанная какая-то сущность. Нам 1С логично, с помощью метаданных, помогает это настроить.
А другие программисты с легкостью могут налепить такой объект, который при считывании еще и всю историю заказов контрагента будет поднимать. И я не шучу, «настоящие» программисты даже не задаются мыслью: «А что не так?»
Мы лучше проектируем бизнес-модели, это просто факт – я с этим столкнулся на практике. Они не умеют проектировать модель данных. Понятно, что кто-то умеет, но в среднем – нет. Упрямо делают франкенштейнов с глазами на… не том месте, где стоило бы.
Архитектура
Логики «ПриЗаписи» или «ПередЗаписью» в большинстве ORM, как правило, нет.
Поэтому, чтобы объекты правильно работали, нужно прописывать очень много служебных обработчиков по бизнес-логике.
Например, вам в каждом справочнике придется прописывать, что есть табличная часть, которую нужно одновременно с ним читать и записывать.
Чтобы реализовать логику «подписки на изменение» – например, при записи что-то досчитать или послать в кафку какое-то сообщение – нужен еще один архитектурный слой, который будет этим заниматься.
И так – по каждому бизнес-объекту.
Вам придется вводить еще один архитектурный слой, что-то вроде «сервис» или «служба», который будет заниматься бизнес-логикой.
А ниже уже слой БД, который будет объекты бизнес-логики перекладывать в базу данных.
Все эти слои надо написать:
-
вручную;
-
без ошибок;
-
без привнесения ненужных ответственностей и без перемешивания ответственности между слоями;
-
срочно, потому что прибегает взволнованный менеджер и кричит. «нам нужно было это сделать еще вчера, пока вы будете это проектировать, поезд уйдет»;
Из-за этого никто ничего правильно не проектирует. Работает – и ладно.
Количество лапши и франкенштейнов, которые получаются в итоговом коде на Java или PHP в десятки раз страшнее, чем в 1С. И когда все встает «колом», рефакторить сильно сложнее.
Индексы
Вас возмущает, что в 1С нельзя управлять индексами?
В других стеках программирования вам придется управлять вообще всеми индексами.
Никто не создаст за вас даже примитивные индексы – вам об этом придется думать заранее и выяснять, какие индексы нужны.
Это еще не все. Из-за того, что обычные программисты избалованы ORM-ками и не знают SQL, они вообще не вдупляют, что такое индексы.
Я часто спрашиваю 1С-ников на собеседовании: «Что такое индекс в базе данных?». Худо-бедно мне отвечают. Кто-то правильнее, кто-то менее правильно, но отвечают.
Java и .NET программисты вообще не знают. Все, что они могут ответить: «Ну, индекс – это какая-то фигня в базе данных». И я сейчас не шучу. Там не считается позором этого не знать.
В других стеках программирования обычно есть DBA – админ, который следит за базой данных. Но он не понимает в коде, он понимает в базе данных.
Он видит, что какая-то выборка в базе начинает тормозить, и добавляет ядер. Или докидывает в базу индекс – при этом даже не говорит программистам, что что-то добавил. Он просто занимается тем, чтобы у него база данных жила.
Оптимизацией запросов занимаются редко.
-
Есть возможность добавить железа – добавляют. Не хватает индексов – DBA докидывает индексы. Программисты даже не знают, что они написали кривой запрос. Написали и написали – админ базы как-нибудь вывезет.
-
Но когда ради красивого запроса вы решите переписывать код, вам придется поменять часть бизнес-логики, а это сроки.
-
Тогда все переходят к пункту «добавим ядер и бог с ним», пока база не встанет совсем уже колом. И только тогда переписывают.
Клиент, Сервер и все-все-все
Когда вы вызываете серверный метод из клиента, для вас клиент-серверное взаимодействие происходит совершенно незаметно. Под капотом 1С делает за вас вообще все, и вы даже не думаете о том, как это происходит.
В других стеках программирования клиент-серверное взаимодействие выглядит следующим образом:
-
Есть JavaScript-приложение в браузере;
-
Есть сервер, с его моделью классов, бизнес-логикой и базой данных;
-
Между ними путешествует JSON.
Казалось бы, все, как в 1С. Но клиент в данном случае – это другое приложение. Его пишет другая команда, например, на React.
Другая команда вообще не интересуются, какая у вас бизнес-логика. Они ждут от вас только спецификацию, чтобы в этом ТЗ было написано «Поле Валюта должно быть недоступным, если снят флажок “Валютный договор”».
Вы должны будете написать ТЗ, чтобы они на JavaScript сделали такую клиентскую логику.
Простейшую задачу «Сделать поле недоступным, если стоит флажок» вы в одиночку сделать не сможете, ее решение займет у вас неделю.
-
Вам нужно будет составить ТЗ, проверить результаты работы фронтендеров, провести интеграционное тестирование.
-
Вы напишете сервис, выставите и задокументируете API, объясните им модель данных, какие поля у этого договора есть, в каком порядке их надо вывести на форму.
-
Фронтендеры будут делать задачу только по вашей спецификации. Они не хотят врубаться в бизнес-логику и в смысл задачи. Им надо рисовать кнопки, и чтобы от них отстали
Неделя – на выключение поля при установленном флажке! 1С-ник выполнит такую задачу за минуту и оставшееся время будет ругать 1С.
А потом вам, как серверному программисту, нужно:
-
десериализовать JSON;
-
получить объектные поля и превратить их в объект, который у нас называется «СправочникОбъект» (то, что ляжет в базу данных);
-
как правило, объект из JSON и объект в базе данных почти совпадают по полям, но не совсем, поэтому вам придется поля перекладывать по одному – при этом никакого «ЗаполнитьЗначенияСвойств» из коробки нет: придется все писать руками;
-
не забыть про логирование, про права доступа, техжурнал, телеметрию;
-
сформировать ответ клиенту.
И так по каждому объекту, и, конечно, вручную.
Вот так выглядит класс заказа с точки зрения бизнес-логики, базы данных и интерфейса – вроде один и тот же объект, их поля почти похожи, но приходится перекладывать все взад-вперед.
Итого – при организации клиент-серверного взаимодействия приходится тратить неоправданно много усилий:
-
Да, они все это пишут это с нуля, все слои.
-
Есть вспомогательные библиотеки, но они слишком универсальные, и ими надо уметь правильно пользоваться;
-
А программисты других стеков пользоваться этими библиотеками не умеют, поэтому часто перепутывают ответственности и запихивают туда половину бизнес-логики, а потом нереально найти, почему сумма отрицательная или поле получает не то значение.
-
Получается спагетти-код – летающий макаронный монстр будет доволен.
Роли и права
Роли – это бич не только других языков, но и 1С.
-
Мы тоже любим проектировать роли «потом».
-
Но у нас хотя бы есть роли.
-
А там ролей нет вообще – это значит, что и саму механику контроля прав тоже придется писать с нуля.
-
Сначала неправильно, и потом неправильно, но лучше.
Нет ничего хуже, чем вписывать права доступа потом, уже в готовое приложение. Потому что логика уже написана – и на клиенте, и на сервере, а мы начинаем придумывать, какие поля нужно показывать, а какие не нужно.
Роли и права – это сквозная функциональность, которая должна проектироваться с самого начала, на этапе бизнес-анализа, до появления первой строчки кода. Если у вас в принципе нет механики ролей, и вы ее пытаетесь как-то вписать потом, то получается такая каша в коде, что даже страшно.
В 1С изначально заложены механизмы для ролей и прав – мы можем проставить галочки доступа к объектам потом, хоть как-то это впихнуть.
А у них даже этого нет – им приходится все с нуля изобретать. И сроки опять затягиваются.
Мой любимый пример – как на 1С сохранить счет в PDF? Мы записываем табличный документ и сохраняем в PDF.
Как сохранить какой-то счет в PDF на Java? Бесплатной и хорошей библиотеки, чтобы скормить хороший макет в PDF нет ни на Java, ни на PHP, ни на .NET.
Есть приложение html2pdf.exe, которым пользуются все, потому что он бесплатный. Это внешний процесс: вы его запускаете, кидаете ему HTML, а он вам конвертирует в PDF. Он бесплатный, но медленный, и результат часто получается кривой.
Есть хорошие платные библиотеки. Причем, чем лучше библиотека, тем жаднее ее авторы.
Никто не даст вам хорошую библиотеку для формирования PDF, т.к. это увеличение бюджета. Вы будете есть кактус и плакать, но формировать PDF, вызывая внешний процесс.
Аналитика и постановка задач
1С-ники – очень хорошие аналитики. Если к вам прибежит нервный менеджер и начнет на вас ругаться, вы хотя бы сможете с ним поговорить на языке бизнеса.
В других стеках программирования очень плохие аналитики. Это правда.
1С-ники – лучшие аналитики из всех возможных. Они понимают бизнес и говорят на его языке. Они задают себе вопрос: «Зачем поставлена задача?».
Программисты на других языках не задают вопросов о задаче. Они ждут, что аналитик им принесет некий текст, и они сделают так, как этот текст поняли. Если аналитик плохой, то и код будет плохой.
А если еще и сроки горят, то: «а когда же мы код писать будем? Сократим время на написание ТЗ!».
В итоге получаем короткое ТЗ из трех слов – как понял, так и реализовал. Реализовал не то, переделываем. Плюс еще технологические сложности.
Разработка бизнес-приложений на других языках, по сравнению с 1С, – это катастрофические потери времени. Мне просто жалко время и бизнес, который это заказывает.
А как же Agile?
В этом плане хорош аджайл, но только если все играют по правилам.
Все будет работать, только если бизнес понимает, что такое спринты, и почему нельзя в середину спринта бахнуть еще пул задач.
Если бизнес в середине спринта говорит: «Все, о чем мы три дня назад договаривались – идет лесом. Берем новые задачи в спринт», то это нифига не аджайл.
Чаще всего происходит вторая ситуация. Реже, когда бизнес принял правила игры.
Вывод: аджайл работает только для сферического бизнеса в вакууме. В реальной жизни, он, к сожалению, хромает.
Стоит ли переходить из 1С на другие языки
Я рассказал всяких страшилок, и теперь вы, наверное, думаете, что из 1С не стоит переходить. Однако все не так просто.
Нужно взвешивать плюсы и минусы.
-
Например, в других языках есть объектно ориентированное программирование, классы, можно на низком уровне щупать байтики – это все очень интересно.
Но это не преимущество, а геморрой:
-
Как только дело доходит не до развлечения, а до конкретных задач с конкретными сроками, завязанными на вашу зарплату, то задача превращается в ужас, а не в развлечение.
-
Все придется пилить самому. Все то, что было естественным и простым в 1С, придется делать самому на другом языке.
-
Вы будете скучать по 1С, потому что потери времени на фигню будут просто катастрофические.
Правда, что там больше платят? Платят там по-разному. У меня есть информация только по Москве, так как я там живу.
Действительно, в Москве можно с ходу обнаглеть и попросить больше денег, но не всегда.
Я встречал Java-программистов, которые приходят на 100 тысяч рублей и встречал 1С-программистов, которые приходят на 200 тысяч рублей. Я не знаю от чего зависит такой разброс зарплат.
Зарплаты программистов во всех стеках плюс-минус одинаковые, с некоторым разбросом, сложившимся исторически. Правда, наверное, в том, что платят тем, кто помогает делать дырки на стенах. Тем, кто решает задачи, а не тем, кто пишет код.
Если ты помогаешь решать задачи – тебе платят. Если ты просто кодер – неважно, на чем ты пишешь, ты не нужен.
Цитата: «В 1С невозможно получить сложную масштабную задачу, а в других языках настоящий HighLoad». Это ерунда и чушь. Просто найдите себе нормального работодателя.
В основном, 90% «настоящего» программирования – это те же самые формочки, записи в базу данных, селекты. Отличий практически нет. Вы не почувствуете разницы с точки зрения каких-то там масштабных или сакральных задач.
Ну так переходить или нет
Конечно, переходить. Если тянет и хочется, надо пробовать. Вернуться всегда успеешь.
Будете ли вы больше получать?
Не факт. Сейчас очень активизировались эйчары, все время пишут письма и звонят. Рынок перегрет. Можно обнаглеть и попросить сходу какие-то деньги. Если справитесь, то справитесь. Не справитесь, вас выгонят и вернетесь в 1С. Пробовать надо, я считаю.
В 1С сейчас все стабильно, а сможете ли вы там?
Есть такой страх «смогу ли я?». Сможете. 1С-ники реально умнее. Вы умеете строить архитектуру данных и анализировать бизнес-процессы. Там этого никто не умеет.
Вы однозначно будете скучать по 1С.
Будете говорить: «Господи, неужели я должен неделю кодить то, что раньше делал за две минуты». Такие ситуации будут, и они будут тянуть назад.
Вы даже захотите написать свою 1С с мыслью: «Я же знаю как надо, я знаю как всем спасти жизнь!»
Вы будете писать свой 1С-подобный фреймворк. А потом прибежит менеджер и скажет: «Ты чем тут занимаешься?» Он даст вам втык, заставит написать костыль и захардкодить всякую ерунду. И в таком виде выйдет в продакшн, потому что красивая архитектура никому не нужна, нужен результат.
Навыки 1С-ника на порядок полезнее для бизнеса, чем навыки кодить какие-то сложные алгоритмы со структурами данных. Тем более, что в энтерпрайзе никто не кодит какие-то волшебные сложные алгоритмы, это миф. Там действует та же схема: сохранил, записал, добавил, прочитал.
1С-ник умеет «из коробки»:
-
понять, как надо проанализировать задачу;
-
как снять требования;
-
построить корректную модель данных;
-
определить, где не хватает контроля прав доступа;
-
спросить какая будет отчетность;
-
оптимизировать кривой SQL запрос, созданный ORM;
-
и многое другое, потому что у 1С-ника нет границ.
Вы точно справитесь. Вы не глупее всех этих снобов, которые считают, что 1С – не настоящее программирование. Это чушь.
Если кто-то все еще очкует, смотрите по своим силам. Если вы видите деньги и перспективы – переходите. Вернуться никогда не поздно.
Я вернулся, потому что мне интереснее видеть результаты своего труда и пользу. Мне не интересно кодить код для того, чтобы это хоть как-то заработало. Мне интереснее видеть глазами то, что я делаю и что это работает.
В 1С я получаю результат. Я не пишу код ради кода.
Код, как вы знаете из начала доклада, – не нужен. Нужен человек, который решает задачи бизнеса. А это именно вы! Все в ваших руках.
*************
Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.
