Переход из 1С в Java: что поменяется в инструментах и зарплате

Разработчик сравнивает Конфигуратор и IDEA, хранилище и Git, bash-скрипт и CI/CD

Переход из 1С в Java: что поменяется в инструментах и зарплате

Привет, Код. Меня зовут Арсений Чепик, я тимлид в Яндекс Путешествиях. Руковожу командой бэкенд-разработки (Java+Kotlin). Начинал я в 2014 году в компании с самописной 1С — и до сих пор считаю, что самописные решения разрабатывать интереснее типовых. Проработал там несколько лет, потом сменил ещё пару мест. Уходить из 1С задумался на рассвете удалёнок: в 1С до COVID удалённой работы не было вообще, строго офис. Java в тот момент выглядела иначе — удалёнка, европейский уровень оплаты, нормальные инструменты.

Выбор пал на Java, потому что она казалась мне более знакомой среди доступных вариантов. А когда я впервые увидел IntelliJ IDEA — после нескольких лет в Конфигураторе — сразу в неё влюбился. Ушёл из 1С в конкретный момент, когда стало понятно, что развить филиал в Европе не получится, а амбиции уже переросли потенциал компании. Можно было поменять одно 1С-место на другое, но раз уж менять — решил поменять и стек.

Дальше по четырём блокам — среда разработки, контроль версий, CI/CD, отладка и ИИ.

Среда разработки: один инструмент против экосистемы

В 1С стандартный инструмент — Конфигуратор. Он покрывает вообще всё: пишешь код, управляешь миграциями БД, выпускаешь обновления. Открыл одну программу — и работаешь. С одной стороны удобно, с другой — именно из-за этой самодостаточности вспомогательные инструменты в экосистеме 1С почти не развиваются. Зачем их делать, если и без них можно? Плюс написать что-то поверх 1С объективно сложнее, чем на Java — платформа закрытая.

Был ещё опыт использования EDT, Enterprise Development Tools. По сути, старая Eclipse IDE, переделанная под 1С. Поддерживает Git, при работе с кодом достаточно удобна. Но она очень ресурсоёмкая, а при работе с формами — просто неудобная. Попробовал и бросил.

В Java я пользуюсь IntelliJ IDEA. Главная её фича — умное построение индексов поиска, и это критически важно: умение быстро найти нужный код в большом проекте — это половина работы. VS Code тоже пробовал, но через пару дней вернулся. Теоретически можно потратить несколько дней, поставить расширений и получить что-то похожее на IDEA. Но зачем, если IDEA уже есть?

Написание кода, чистота архитектуры

В 1С пишут на русском языке

Почти все программы написаны на русском, и немного неудобно переключаться между раскладками, когда хочешь написать “Новый HTTPСоединение”. Зато гораздо проще читать, особенно если не знаешь английский. Иногда бывают забавные казусы, когда сервисное слово не подходит по роду к переменной: “Для Каждого Строка …”. Хочется просклонять “Каждого”, но нельзя. А еще 1С регистронезависима и нестрого конвенционна, можно писать имена переменных любым размером букв, и для 1С это будет одна и та же переменная.
Здесь  же хочу отметить отсутствие любого ООП — есть набор метаданных, ими и можно пользоваться. Расширить класс нельзя, вынести интерфейс нельзя. Поэтому код пишется проще, без дополнительных уровней абстракции. На самом деле, этого достаточно для решения бизнес-задач.

И третье, что касается кода, это семантика конструкций, в 1С они простые, старые, надёжные. Никаких модных лямбд, инлайн функций. Сразу понятно, как происходит обход коллекций.

Java противоположна — только английский язык

Написание кода строго конвенционно (IDE ругается, если переменная не lowerSnake, а класс не UpperSnake). Размер букв имеет значение, myVar и myvar – это разные переменные.

В основе Java лежит ООП, поэтому все классы наследуются, поэтому приходится думать про абстракцию и закладываться на наследников, из-за этого код сложнее писать. Но потом проще дописывать. Частое замечание на ревью для начинающих: “давай тут вынесем абстракцию наверх”.

Выше я подчеркнул про ограничения семантики в 1С, так вот Java поддерживает лямбды и инлайн функции. IDE сама предлагает следующие методы для обхода коллекции, поэтому классический обход коллекции “перебрать-отфильтровать-поменять-собрать” пишется в одну длинную строку, которую потом сложно прочитать. Но выглядит очень красиво, особенно на контрасте. Тот самый Code as Art. 

Полезный блок со скидкой

IntelliJ IDEA, Git, CI/CD, ИИ-агенты — каждый инструмент требует практики на реальных задачах, а не просто сравнения в статье. Если хочется разобраться, как всё это работает в Java-разработке, — держите промокод Практикума на любой платный курс: KOD (можно просто нажать). Он даст скидку при покупке и позволит сэкономить на обучении.

Бесплатные курсы в Практикуме тоже есть — по всем специальностям и направлениям, начать можно в любой момент, карту привязывать не нужно, если что.

Контроль версий: хранилище против Git

В 1С для групповой разработки есть хранилище конфигурации — это де-факто стандарт. Если работаешь в команде, пользуешься хранилищем, альтернатив особо нет. Инструмент встроен прямо в Конфигуратор, дополнительно ничего настраивать не нужно.

В Java любая среда разработки поддерживает Git, любая команда его использует. Работал с GitHub, GitLab, в Яндексе своя система контроля версий — с точки зрения ежедневной работы они все примерно одинаковые. Поначалу непривычно после хранилища, но быстро привыкаешь и перестаёшь понимать, как вообще без этого жил.

Сторонние библиотеки, подключаемые модули

В 1С много чего встроено в стандартные механизмы платформы — например, там не только встроенная работа с БД, но даже механизм чат-ботов или возможность разработки мобильных приложений. Тут же минус — всё это устанавливается сразу, и занимает относительно много места на диске. Но гораздо большая проблема — это невозможность быстрого подключения дополнительных модулей. 

В 1С можно использовать стандартные конфигурации поставщика

Их еще называют “Типовые конфигурации”, например, Бухгалтерия Предприятия, самая известная), но их некорректно считать “сторонней библиотекой”, это отдельная программа, пусть даже можно поверх неё дописать что угодно. Другой вариант подключения дополнительных модулей – это практически единственная библиотека модулей для 1С, Библиотека Стандартных Подсистем. На данный момент в ней около 70 блоков, пять лет назад было 50. Совсем неудобный вариант (но используемый, потому что лучше нет) — копировать блоки кода между своими разработками.

В Java всё по-другому

В “чистой” программе на Java почти ничего нет. Если в Java нужно что-то сложнее математики, на помощь приходят импорты. Можно взять любую программу на Java из стороннего репозитория и подключить его к своему проекту в два движения – положить архив с программой рядом со своим кодом и написать “import”. Так подключаются все нужные механизмы, от работы с БД (да, чистая Java не умеет подключаться к БД) до чего угодно, хоть ИИ-агента внутри приложения. Количество репозиториев/модулей исчисляется миллионами, иногда даже быстрее написать свой, чем искать подходящий.

CI/CD и доставка изменений: bash-скрипт против автоматизации

Вот здесь разница между стеками ощущается больше всего.

В 1С никакого CI/CD нет. У нас в команде каждую ночь запускался Конфигуратор через bash-скрипт, который применял сохранённую конфигурацию. Сохранять конфигурацию должен был старший разработчик вручную, в конце рабочего дня. Забыл сохранить — изменения не приедут. Назвать это автоматизацией можно только с натяжкой.

В Java при настроенной инфраструктуре вообще не нужно думать о том, как доставить изменения до потребителя. CI/CD, автотесты, мульти-инстансы — всё это часть стандартного рабочего процесса, изменения едут сами после коммита.

Отладка и баги

В 1С язык нетипизированный, IDE не держит контекст объекта. Обратиться к полю, которого нет, очень легко — и узнаешь об этом не в момент написания кода, а позже, когда дойдёт до самотестирования. Написал сотню строк, а потом обнаружил, что где-то в середине была опечатка в названии поля.

В Java такого сценария нет по устройству языка. Статическая типизация работает прямо при написании: IDE видит, что поля нет, подсвечивает ошибку и предлагает исправление. До компиляции сломанный код не доедет. Это не ИИ, просто так работает система типов.

Если баг всё-таки пробрался в прод — разница между стеками исчезает. Оба дают стектрейс, встроенную отладку и логи. Дальше всё зависит от того, насколько аккуратно вы эти логи пишете.

ИИ-агенты в разработке

Три года назад, когда я работал в 1С, никаких ИИ-инструментов не было вообще. Сейчас я использую Opencode поверх нескольких моделей — Claude, GLM, ChatGPT, Gemini. Конкретные версии не пишу намеренно: они устареют раньше, чем вы дочитаете эту статью.

Разница в скорости ощутимая. Дорогой ИИ пишет код на Java из описания задачи за 40 секунд, дешёвый — за 15 минут. В 1С такого инструмента нет, там по-прежнему руками.

По порядку работы с агентами: сначала нужно научиться делать правильные промпты, описывать скиллы, управлять контекстом — всё это отрабатывается на бесплатных или дешёвых моделях. Только после этого берёте самую дорогую для того, чтобы вы могли отличить и пофиксить галлюцинации. Про локальные модели: я их не поднимал и не советую. По качеству вывода они проигрывают бесплатным облачным.

Что выбрать

Оба стека рабочие, но устроены по-разному — и это влияет не только на набор инструментов, но и на ежедневную работу.

Выбирайте 1С, если:

  • нужна самодостаточная среда без настройки инфраструктуры
  • работаете с российским бизнесом, где 1С — стандарт
  • групповая разработка через хранилище устраивает команду и заказчика

Выбирайте Java, если:

  • нужен нормальный CI/CD без bash-костылей
  • важна экосистема: Git, IDEA, автотесты, ИИ-агенты
  • планируете расти в сторону DevOps или распределённой архитектуры

Главное отличие не в синтаксисе. В 1С инфраструктура встроена и не требует решений — это её сила и её ограничение одновременно. В Java её нужно собрать, зато потом она работает без вашего участия.

Что советую ещё почитать по теме: 

Автор: Арсений Чепик
Вам может быть интересно
medium