Меня зовут Чаусов Антон и я ведущий программист. Разрабатываю на 1С с 2011 года, с того же времени преподаю программирование. Более пяти лет работал руководителем отдела разработки, но вернулся обратно в программирование. Являюсь экспертом по технологическим вопросам 1С.
Моя статья посвящена развитию фундаментальных знаний в IT для программистов 1С. В ней я разберу классический стереотип о том, что «1С-ники – не программисты»: откуда у него растут ноги, почему он сложился, как это решить и нужно ли решать в принципе. Обсудим, для чего на практике нужны фундаментальные знания в IT. В конце я порекомендую несколько книг, которые положат начало пути в «настоящие программисты».
1С-ник – не программист?
В сфере IT часто возникает стереотип, что 1С-ники – не программисты. Почему он возникает, на мой взгляд?
За что мы любим 1С:
-
Низкий порог входа. Благодаря этому большинство попали в 1С. Конечно, есть люди с большой IT-базой, но многие пришли именно из-за низкого порога входа.
-
Массовость 1С. 1С нужна везде – и для крупных внедрений, и для сопровождения маленького ларька.
-
Простые задачи. Можно просто создавать внешние обработки и отчеты. Этого будет достаточно. Кейс из жизни: пришел на собеседование человек и говорит, что у него 15 лет практики программистом 1С. Спрашиваю: «А что умеешь делать?». Отвечает: «Писать отчеты, обработки и иногда обновлять конфигурацию». Больше человек не умел ничего и 15 лет нормально работал.
-
1С близок к бизнесу. И это хорошо: мы понимаем, как устроен бизнес, бизнес-процессы.
«Войтишники» в 1С появились еще до того, как это стало мейнстримом. Бухгалтер, который решил разобраться в 1С и сам все переделать – классика с 2010-х годов (а может, и раньше). Благодаря интернет-образованию в других языках программирования сейчас все больше таких же «войтишников».
Как следствие – застой и консерватизм в головах у 1С-ников. Специалист уходит на стабильный и комфортный для него уровень дохода и на нем замирает.
На практике мы наблюдаем странно организованный код:
-
Зачем-то задается переменная, потом пишется запрос, а потом меняется значение переменной – нигде не переопределяется. Человек где-то увидел, что так написали, и так же написал. Зачем – непонятно.
-
Архитектура регистров – тоже классика: когда верхние измерения почему-то становятся «удалить».
Парадокс Блаба и его влияние
Парадокс Блаба заключается в том, что программист, который умеет работать с одним языком программирования, прекрасно понимает, чем его язык лучше любого более слабого, и абсолютно не понимает, чем он хуже более развитых языков. Решение любой задачи он видит только на этом самом блабе – и не видит более простого, правильного или оптимального решения.
Для нашей области это не только про язык 1С, но и про инструменты, которые мы используем, и даже про конфигурацию. Условно: если я знаю «Бухгалтерию предприятия», зачем мне изучать «Зарплату и управление персоналом»? Я что-нибудь сделаю на костылях в БП, чтобы зарплата считалась так, как нужно.
Пути развития технических навыков
Какие пути развития я вижу для становления «настоящего тру-программиста»? Важный дисклеймер: я ни в коем случае не пропагандирую, что не нужно изучать предметную область. Но если хочется развиваться именно как технический специалист, то больше внимания надо уделять хардскиллам.
Изучение новых языков программирования
Авторы книги «Программист-прагматик» Дэвид Томас и Эндрю Хант предлагают ежегодно изучать один новый язык. Не обязательно до уровня Middle или Junior+ – просто, чтобы понимать, как он работает. Также не обязательно браться за сложные языки. Можно начать с близких: Python, JavaScript, OneScript и т.д.
Изучение смежных технологий
Если изучение других языков программирования вам кажется избыточным, можно посмотреть на технологии, связанные с 1С. Я проводил опрос среди знакомых разработчиков и многие ни разу не заглядывали в СУБД, чтобы узнать,как выглядит база данных 1С на уровне СУБД. Очень полезно изучить этот вопрос. Это сразу выведет вас на новый уровень в написании запросов.
Освойте юнит-тестирование и сценарные тесты. Можно поговорить с командой тестирования вашей компании. Освойте работу в EDT, Git и посмотрите, как выглядит Linux.
Изучение фундаментального IT
Разберитесь с паттернами программирования, архитектурными подходами, изучите классические алгоритмы. Прочитайте книги по программированию, не только по 1С, а что-то более классическое.
Участие в жизни сообщества
Участвуйте в конференциях, перечитывайте стандарты 1С и ищите курсы на новые темы, даже если они не касаются текущих задач. Ведь к вам может прийти заказчик с запросом: «Мне нужен Telegram-бот». Вы скажете: «А я умею, сейчас сделаем». После всего этого постарайтесь не уйти на другой стек. Нам нужны хорошие программисты в 1С!
Практическая польза: примеры из опыта
Зачем все это на практике и как это помогает в работе? Во-первых, это структурирует ваше понимание. Как следствие, код, который вы пишете, продукты, которые делаете, становятся более структурированными и легко поддерживаемыми.
Разберем конкретные примеры.
Удаление элементов из «огромного массива»
Задача: удалить все отрицательные числа. При решении в лоб (удаление с начала) остается необработанный элемент из-за сдвига коллекции.
Классическое решение: удаление с конца. Проходим массив с конца, удаляем отрицательные элементы и при перестановке у нас не остается необработанных элементов.
Усложнение: массив настолько большой, что едва помещается в памяти; операцию нужно выполнить максимально быстро с минимальной перестановкой. Последовательность элементов не важна.
Решение: обход массива с двух концов (начало и конец). Находим первое отрицательное значение слева и первое положительное справа, меняем их местами. В итоге все отрицательные оказываются в конце массива, и их можно удалить за одну операцию без сдвигов. Для больших массивов работает значительно быстрее. Важно отметить, что оптимальность такого решения зависит от размера массива и железа, нужно экспериментировать.
Конкатенация vs СтрШаблон и СтрСоединить
Соединение строк часто пишут через конкатенацию. Почему это неправильно? Строка в 1С – не примитивный тип, это массив символов. Конкатенация – сложение только двух массивов. Каждая операция сложения создает новый массив в памяти.
Стандарт 782: для сложения длинных строк или массовой конкатенации нужно использовать СтрШаблон или СтрСоединить. В других языках есть аналоги, такие как StringBuilder.
При замере скорости выявилось, что конкатенация 300 000 строк через «;» выполняется в ~150 раз медленнее, чем через СтрСоединить. Таким образом, понимание устройства строки и работы СтрСоединить на порядки ускоряет решение.
Поиск циклов в орграфе
Задача: по ориентированному графу необходимо рассчитать сроки, исключив ситуации, когда потомок влияет на родителя. При этом решение должно работать на клиенте, отображаться на форме и поддерживать ввод до 50 000 задач.
Наше первое решение работало до 1000 элементов, после оптимизации – до 15 000. Этого оказалось недостаточным.
Решение: применение алгоритма Тарьяна для поиска сильно связных циклов. Алгоритм:
-
Вершины помечаются цветами: белый (не посещена), синий (в обработке), фиолетовый (обработана).
-
Обход графа. При попадании в синюю вершину – обнаружен цикл.
-
Вершина без исходящих ребер помечается фиолетовой.
Реализация на 1С оказалась в 5 раз компактнее предыдущего решения и легко справилась с 50 000 элементов, исключив лишние проходы.
Юнит-тестирование vs отладка
На том же проекте с графом задач при добавлении новых условий отладка стала занимать больше времени, чем написание кода. Необходимо было шагами проходить этапы, считать даты, сравнивать.
Решение: Написали обработку-тест. В табличный документ вводятся ожидаемые даты, связи задач. Запускается тест: зеленый – хорошо, красный – ошибка. Отладка ускорилась в разы.
Как развитие этого подхода мы начали писать тесты заранее (TDD подход). Сейчас для подобных задач я бы использовал Yaxunit. Благодаря ему на текущем проекте с большим покрытием тестами при изменении архитектуры падающие тесты предотвращают попадание проблемного кода в master.
Сборочные линии (DevOps)
Инструмент – например, готовая библиотека Jenkins-lib – может показаться ненужным, пока его не попробуешь. Классическая сборочная линия получает проект из репозитория Git, собирает, прогоняет тесты, разворачивает на тестовые стенды. Тем самым избавляет от ручных действий.
Пример из жизни: при создании Merge Request из ветки разворачивается новая база, она публикуется на веб-сервисе и тестировщику в Telegram прилетает ссылка: «Вот база, вот задача, тестируй». Все это происходит до попадания кода в master. С Jenkins или GitLab CI/CD можно делать больше.
Микросервисная архитектура
Мы привыкли, что 1С – это монолит, который автоматизирует все (ERP, УХ и т.д.). Наша компания решила пойти по пути разбиения на сервисы (не обязательно на микросервисы в чистом виде). Теперь отдельные сервисы реализуют свою логику, обмениваются данными. В общей базе (хранилище) собираются готовые данные.
Преимуществом такого подхода является то, что любой сервис можно обновить или заменить отдельно. Обслуживание системы стало проще, хотя разработка стала сложнее из-за обменов.
В 1С такой подход уже применялся. Кто работал с этим, наверняка помнит: выходит новая версия отчетности, но клиент не готов обновлять бухгалтерию. Что мы делали: полностью вырезали модуль отчетности, удаляли связанные с ним формы, затем вставляли их отдельно в конфигурацию и отдавали клиенту не измененную основную конфигурацию, но с новыми модулями отчетности.
Паттерны программирования
Паттерны программирования и архитектурные паттерны уже стали трендом в определенных кругах 1С-разработчиков. Более того, многие из вас используют их, даже не осознавая этого — просто потому, что сама платформа 1С к этому располагает. Здесь важно перейти от неосознанного применения к осмысленному — тогда можно будет задействовать дополнительные возможности.
Возьмем, к примеру, Layered Architecture (многослойную архитектуру). Подход, при котором логика отображения формы остается на самой форме, а бизнес-логика выносится в общие модули или модули менеджеров, знаком многим. Но не все задумываются, что это и есть Layered Architecture.
Заключение
Если вы работаете на внедрении/поддержке типовых конфигураций и соблюдаете стандарты разработки, все вышесказанное может быть для вас избыточным. Но если хотите расти дальше как технический специалист, попадать на сложные и интересные проекты, тогда я рекомендую:
-
Поддерживать знания в актуальном состоянии;
-
Планировать обучение и развитие хардскиллов;
-
Расширять кругозор и насмотренность в программировании;
-
Стараться всегда смотреть на задачи сверху, не бояться выходить за рамки стандартных подходов 1С.
Рекомендуемые материалы
-
«Программист-прагматик: путь от подмастерья к мастеру» — Эндрю Хант, Дэвид Томас
-
«Чистый код: создание, анализ и рефакторинг» — Роберт Мартин
-
«Совершенный код: мастер-класс» — Стив Макконнелл
-
«Архитектура корпоративных программных приложений» и «Рефакторинг. Улучшение существующего кода» — Мартин Фаулер
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.