Смена подрядчика — это всегда стресс. Предыдущая команда уносит с собой знания о проекте, документация (если она вообще была) устарела, а новые разработчики смотрят на код и задают неудобные вопросы. В худшем случае вы теряете месяцы на разбор чужого кода вместо развития продукта.

В этой статье мы предложим конкретный алгоритм, как провести передачу проекта с минимальными потерями. Вы получите систему оценки состояния проекта, методику расчёта реальной стоимости перехода и готовый чек-лист из 25 пунктов для приёмки. Материал будет полезен CTO и CEO, которые уже меняют подрядчика или планируют это сделать в ближайшее время.

Почему это больно: типичные сценарии

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

Кейс: как 2 недели превратились в 4 месяца

Компания N — интернет-магазин бытовой электроники с оборотом 200+ млн рублей в год. Сайт на Битрикс, интеграция с 1С:Управление торговлей, около 50 000 SKU. Предыдущий подрядчик — небольшая студия из трёх человек — работал с проектом 4 года.

В какой-то момент студия сообщила, что закрывается. Дали месяц на передачу дел. Казалось бы, достаточно — ведь всё должно быть задокументировано за 4 года?

Реальность оказалась другой:

• Документации не было вообще. Ни схемы архитектуры, ни описания бизнес-логики, ни даже списка кастомных доработок.
• Комментариев в коде — ноль. 200+ файлов кастомных компонентов без единого пояснения, зачем они нужны.
• Интеграция с 1С — на костылях. Стандартный обмен «доработан» на стороне Битрикс на 70%, логика разбросана по 15 файлам, часть — в обработчиках событий, часть — в агентах, часть — в кронах.
• Доступы — у разработчика на ноутбуке. Root-пароль от сервера знал только один человек, и он уже нашёл новую работу.

Результат: новая команда потратила 4 месяца только на то, чтобы разобраться в проекте и стабилизировать его. Бюджет на «передачу» вырос в 3 раза от первоначальной оценки. Два критичных бага в интеграции с 1С «стреляли» ещё полгода.

Красные флаги при приёмке проекта

Если вы видите хотя бы 3 пункта из этого списка — готовьтесь к сложной передаче:

• Код не в Git (или в Git, но без осмысленной истории коммитов)
• Нет тестового сервера — все изменения катятся сразу на прод
• Деплой через FTP вручную
• Бэкапы «делает хостинг» (а вы ни разу не проверяли)
• Пароли хранятся «в голове» или, ещё хуже, в чате
• Предыдущий подрядчик не может объяснить, как работает интеграция с внешней системой (например, 1С)
• На вопрос «где документация?» отвечают «код — лучшая документация»
• Обновления Битрикса не ставились больше года
• В папке /local/ — хаос из десятков файлов без структуры

Система оценки проекта: 5 уровней зрелости

Прежде чем считать стоимость перехода, нужно понять, с чем вы имеете дело. Мы используем простую систему из 5 уровней — она позволяет за один день оценить состояние проекта и спрогнозировать трудозатраты.

Таблица уровней зрелости

Риск-множитель — это коэффициент, на который нужно умножить базовую оценку трудозатрат. Если вы оцениваете задачу в 100 часов, а проект на уровне 2, реально уйдёт 250–300 часов.

Как определить уровень за 1 день: экспресс-аудит

Вот чек-лист из 15 пунктов. Каждый «да» — это 1 балл. Посчитайте сумму и определите уровень.

Инфраструктура (5 пунктов):

1. Все доступы (хостинг, домены, сервисы) задокументированы и переданы
2. Есть Git-репозиторий с историей коммитов за последний год
3. Существует тестовый сервер (dev или stage)
4. Бэкапы настроены и проверены (вы восстанавливали хотя бы раз)
5. Есть мониторинг (хотя бы uptime и базовые метрики)

Код и архитектура (5 пунктов):

1. Структура /local/ соответствует стандартам Битрикс ( https://docs.1c-bitrix.ru/ )
2. Кастомные компоненты имеют понятные названия и лежат в правильных папках
3. Нет хардкода паролей и ключей в коде
4. Composer/npm используются для управления зависимостями
5. Обновления ядра Битрикс ставились в последние 6 месяцев

Документация и процессы (5 пунктов):

1. Есть описание архитектуры (хотя бы схема)
2. Задокументирована бизнес-логика нетривиальных модулей
3. Есть инструкция по деплою
4. Ведётся трекер задач с историей
5. Проводятся код-ревью (хотя бы для критичных изменений)

Интерпретация результатов:

• 0–3 балла → Уровень 1 (Хаос)
• 4–6 баллов → Уровень 2 (Базовый)
• 7–10 баллов → Уровень 3 (Управляемый)
• 11–13 баллов → Уровень 4 (Зрелый)
• 14–15 баллов → Уровень 5 (Передаваемый)

Из практики: 80% проектов, которые к нам приходят на поддержку — это уровни 1–2. Уровень 4–5 встречается только у компаний с собственной in-house командой или у тех, кто изначально выстраивал процессы.

Методика расчёта стоимости перехода

Теперь переведём всё в деньги. Вот формула, которую мы используем:

Стоимость перехода = (Базовая оценка × Риск-множитель) + Скрытые затраты

Компоненты базовой оценки

1. Технический аудит — 40–80 часов

• Анализ кодовой базы
• Проверка безопасности
• Оценка технического долга
• Документирование текущего состояния

2. Восстановление/создание документации — 20–100 часов

• Схема архитектуры
• Описание интеграций
• Бизнес-логика кастомных модулей
• Инструкции по деплою и обслуживанию

3. Настройка инфраструктуры — 16–40 часов

• Развёртывание dev/stage-окружения
• Настройка CI/CD
• Перенос репозитория и настройка процессов
• Настройка мониторинга и алертов

4. Онбординг команды — 40–80 часов на разработчика

• Изучение проекта
• Разбор кастомных решений
• Погружение в бизнес-логику
• Первые задачи под присмотром

Скрытые затраты (о которых часто забывают)

Простой бизнеса во время передачи В переходный период скорость разработки падает в 2–3 раза. Новые фичи откладываются, баги фиксятся медленнее. Если ваш бизнес зависит от скорости изменений — закладывайте это в расчёт.

Юридические расходы

• Права на код: кому принадлежит то, что написал подрядчик?
• NDA и передача данных
• Расторжение договора с предыдущим подрядчиком

Потеря данных и конфигураций Если доступы не были переданы корректно — часть данных может быть утеряна. Восстановление конфигураций внешних сервисов (платёжки, доставка, CRM) может занять недели.

Технический долг, который вскроется позже После передачи обязательно всплывут проблемы, которые не были видны на этапе аудита. Закладывайте буфер 20–30% на неожиданности.

Чек-лист приёмки проекта: 25 пунктов

Этот чек-лист можно использовать как акт приёма-передачи. Пройдитесь по каждому пункту вместе с предыдущим подрядчиком и зафиксируйте статус.

Блок A: Доступы и инфраструктура

1. Хостинг/сервер — root-доступ, панель управления

2. Домены — доступ к регистратору, DNS-записи

3. SSL-сертификаты — где выпущены, когда истекают

4. Почтовые сервисы — SMTP, транзакционные письма

5. CDN — доступ и настройки (если используется)

6. Внешние API — платёжные системы, доставка, CRM

7. Мониторинг — доступы к сервисам мониторинга

8. Бэкапы — где хранятся, как восстанавливать

Блок B: Кодовая база

9. Git-репозиторий — полная история коммитов

10. Ветки — структура веток (prod, dev, feature)

11. Лицензия Битрикс — ключ, срок действия, на кого оформлена

12. Сторонние модули — лицензии, исходники, контакты разработчиков

13. Composer/npm — зависимости актуальны, lock-файлы в репозитория

14. Кастомные компоненты — список с кратким описанием

15. Интеграции — 1С, CRM, ERP: схема обмена, расписание, логи

Блок C: Документация

16. Архитектура — схема компонентов и их взаимосвязей

17. Бизнес-логика — описание нетривиальных модулей

18. Инструкция по деплою — шаги для выкатки изменений

19. Известные проблемы — workarounds, костыли, технический долг

20. Контакты — ключевые люди (разработчики, менеджеры, заказчики)

Блок D: Данные и безопасность

21. Бэкап БД — актуальный дамп базы данных

22. Выгрузка контента — медиафайлы, документы

23. Логи — логи за последние 3–6 месяцев

24. Аудит безопасности — результаты последнего сканирования

25. Смена паролей — все пароли изменены после передачи

Из практики: Пункт 25 критически важен. Мы видели случаи, когда бывший подрядчик (или его уволенный сотрудник) заходил на сервер спустя месяцы после передачи. Меняйте ВСЕ пароли: сервер, база данных, админка Битрикс, FTP, панель хостинга, внешние сервисы.

Переходный период: как не уронить прод

Даже идеальная передача документов не гарантирует, что новая команда сразу начнёт работать на полную мощность. Нужен переходный период — и его тоже надо правильно организовать.

Параллельная работа двух команд

Оптимальный вариант — 2–4 недели параллельной работы. Старая команда ещё доступна для вопросов, новая уже погружается в проект.

Как это организовать:

• Выделите конкретные часы для созвонов (например, ежедневный стендап в 11:00)
• Фиксируйте все ответы в письменном виде (Telegram, Битрикс24)
• Новая команда ведёт «дневник» — записывает всё неочевидное, что узнаёт
• Старая команда не берёт новых задач, только отвечает на вопросы и фиксит критичные баги

Заморозка крупных изменений

На время передачи (и ещё 2–4 недели после) — никаких больших релизов. Только:

• Критичные баги, влияющие на продажи
• Баги безопасности
• Мелкие правки контента

Всё остальное — в бэклог. Это болезненно для бизнеса, но попытка делать крупные изменения на незнакомом проекте заканчивается ещё большими проблемами.

Приоритеты переходного периода

1. Первые 2 недели: стабилизация. Понять, как всё работает, не сломать ничего критичного.
2. Недели 3–4: поддержка. Начать закрывать текущие баги и мелкие задачи.
3. Недели 5–8: нормализация. Выйти на плановую скорость разработки.
4. Месяц 3+: развитие. Начать закрывать технический долг и делать улучшения.

Эскалационная матрица

Договоритесь заранее, что делать в критических ситуациях:

KPI для новой команды на первые 90 дней

Не требуйте сразу подвигов. Разумные KPI для переходного периода:

Месяц 1:

• Все критичные баги закрываются в течение 24 часов
• Uptime не ниже 99%
• Документация текущего состояния готова

Месяц 2:

• Время реакции на задачи — не более 4 часов
• Закрыто 80% бэклога багов
• Dev-окружение полностью настроено

Месяц 3:

• Скорость разработки — 70–80% от плановой
• Первые улучшения инфраструктуры (CI/CD, мониторинг)
• План по закрытию технического долга

Заключение

Смена подрядчика — это не катастрофа, а управляемый процесс. Да, он требует времени и денег. Но правильный подход позволяет:

• Сократить время адаптации с месяцев до недель
• Снизить риски потери данных и простоя
• Сэкономить бюджет за счёт точной оценки вместо «примерно»

Главное правило: инвестиция в качественную передачу окупается в 3–5 раз на последующей поддержке. Проекты, принятые «на скорую руку», потом годами тянут за собой проблемы и перерасход бюджета.

Если вы сейчас в процессе смены подрядчика или планируете это сделать — используйте чек-лист и методику из этой статьи. А если нужна помощь с аудитом или приёмкой проекта — мы проведём экспресс-оценку за 1–2 дня и дадим честную картину того, с чем вы имеете дело.

В классическом интернет-магазине техническая реализация предполагает продажу товара только от одного юрлица, но это бы означало с точки зрения бухгалтерии необходимость переместить товар с одного юрлица на другое, что является не только головной болью бухгалтера, но и предполагает денежные потери на такой транзакции.

Важность реализации функционала разделения оплаты

1. Упрощение бухгалтерского учета

Разделение платежей между двумя юридическими лицами позволяет более четко отслеживать финансовые потоки. Каждое юридическое лицо может вести отдельный бухгалтерский учет, что упрощает процесс отчетности и минимизирует риски ошибок. Это особенно актуально для компаний, работающих в разных регионах, где налоговые правила могут значительно отличаться.

2. Снижение налоговых рисков

Разделение оплат позволяет более эффективно управлять налоговыми обязательствами. Каждое юридическое лицо может оптимизировать свои налоговые расходы в соответствии с действующим законодательством. Это снижает риск налоговых проверок и штрафов, так как каждая компания отвечает только за свои финансовые операции.

3. Гибкость в управлении финансами

Разделение платежей дает возможность более гибко управлять финансами. Например, одно юридическое лицо может заниматься продажами одних групп товаров, а другое — других групп товаров, к примеру от разных поставщиков.

4. Легкость в масштабировании бизнеса

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

Настройка функционала разделения оплаты

Теперь поговорим о том, как же всю эту красоту настроить технически на платформе Bitrix.

В настройках платежных систем мы добавили два способа оплаты. В нашем случае это платежные системы с ID 10 и 11:

Обработчик, название и описание у них одинаковые:

Отличаются только настройки платежной системы, которые были предоставлены Paykeeper:

Затем мы внесли изменения в шаблон страницы оформления заказа, в нашем случае это компонент sale.order.ajax. Мы сделали, чтобы для пользователя отображалась всегда одна из платежный систем.

То есть, если в корзине есть товары, которые принадлежат только первому складу или обоим складам одновременно, то в этом случае отображалась платежная система с ID 10.

В остальных случаях c ID 11.

Таким образом, если у пользователя в корзине были товары только с первого или только со второго склада, то алгоритм оформления заказа никак не менялся с точки зрения пользователя. Ему автоматически подставлялась необходимая платежная система, и далее он оформлял заказ, проходя штатный механизм Битрикс.

Вся магия начиналась, когда у пользователя в корзине были товары с обоих складов. Так как Битрикс при оформлении заказа всегда создает одну оплату, то нам необходимо сразу после оформления заказа разделять ее на две отдельных оплаты.

Для этого мы в файле init.php на событие OnSaleOrderSaved создаем обработчик, в котором все изменения делаем для только для новых заказов:

Далее получаем заказ, товары из него и коллекцию оплат:

Товары складываем в массив $arBasketItems, чтобы потом с ним было проще работать:

Затем проверяем, на каких складах содержатся товары из массива $arBasketItems , и сохраняем итоговую сумму товаров по складам в массиве $arBillSum:

Ключами массива $arBillSum являются ID складов, хранящиеся в Битрикс. В нашем случае есть два склада с ID 1 и 2.

Мы проверяем, если в заказе есть товары с обоих складов, то в этом случае делаем разбиение на два счета:

Из текущей суммы оплаты вычитаем стоимость товаров, принадлежащих ко второму складу. Данная стоимость хранится в переменной $arBillSum[2]:

Теперь создаем вторую оплату. ID 11 — это идентификатор второй платежной системы в Битрикс:

Сохраняем заказ:

После этого пользователь попадает в личный кабинет на страницу данного заказа, которая реализована через стандартный компонент sale.personal.order.detail:

Вверху мы выводим сообщение, в котором подробно описываем, почему у данного заказа две оплаты.

Ниже у него выводится две кнопки на оплату, а в правой части отображаются товары данного заказа, разбитые на две части.

Оплату мы принимаем через систему PayKeeper и на сайте используем ее модуль. Этот модуль, к сожалению, не поддерживает корректную работу при оплате двух счетов, поэтому нам пришлось его немного кастомизировать.

Для этого необходимо внести изменения в файле /bitrix/modules/ooopaykeeperprocessing.paykeeperpayment/install/bitrix/

modules/sale/handlers/paysystem/paykeeper/handler.php :

• в методе initiatePay(), чтобы сумма оплата бралась не как сумма заказа, а как сумма конкретной платежки,
• в методе cart(), который формирует данные для чека — в него мы добавили проверку, чтобы он также возвращал не все товары, а только те, которые относятся к конкретной платежке.

После установки модуля этот файл будет скопирован в папку /bitrix/modules/sale/handlers/paysystem/paykeeper/handler.php — через нее он будет подключаться при оплате.

Если у вас остались вопросы, с удовольствием ответим на них в комментариях!

В мире разработки ПО существует множество платформ, предназначенных для тренировки и совершенствования навыков программирования. Но до текущего момента ни на одной из них не было возможности решать задачи на 1С. Теперь такая платформа существует.

Если же вас интересуют вакансии Java-разработчика, ознакомьтесь с этим предложением от Сбера по ссылке → Java-разработчик.

Функционал

1. Платформа предлагает широкий спектр задач для решения на языке программирования 1С для разного уровня сложности. Это позволяет как начинающим, так и опытным разработчикам проверить и улучшить свои навыки.
2. Редактор кода: удобный онлайн-редактор кода с подсветкой синтаксиса позволяет комфортно работать над решением задач. Вам не нужно устанавливать дополнительное ПО, для того, чтобы начать.
3. Тестирование решений: система автоматически проверяет ваш код на корректность и эффективность, а также информирует об ошибках.
4. Статистика и рейтинг: пользователи могут отслеживать свой прогресс, просматривать статистику прохождения задач и сравнивать свои результаты с другими участниками.

Преимущества

1. Уникальность: платформа специализируется на языке 1С, что делает ее уникальной и ценной для специалистов, работающих с этим языком.
2. Обучение и развитие: решение задач по программированию на 1С помогает улучшить понимание языка, умение использовать его особенности и повысить профессиональный свой уровень.
3. Сообщество: платформа объединяет сообщество разработчиков, где можно обсудить задачи, делиться опытом и учиться у других.

В целом, система будет интересна всем, кто интересуется программированием на языке 1С и стремится к развитию своих навыков. Начинающий разработчик или опытный специалист, здесь всегда есть место для обучения, практики и роста! Присоединяйтесь, будет интересно!

Вот краткое саммари по видео:

1. 1С – это не только бухгалтерия и игры, но и язык программирования, автоматизация бизнес-процессов и платформа для различных видов бизнеса.
2. Платформа 1С включает типовые и нетиповые конфигурации, а разработка ведется на встроенном языке программирования.
3. Продукция 1С охватывает практически все функции бизнеса и государственных организаций, что обеспечивает постоянный спрос на 1С-разработчиков.
4. Разработчики 1С занимаются внедрением и сопровождением программ в организациях, а их вакансии разнообразны и требуют сертификации.
5. Зарплата 1С-разработчиков зависит от квалификации и опыта, их обязанности включают не только программирование, но и работу с клиентами.
6. Для устройства на работу 1С-программистом требуются технические знания, понимание бухгалтерского учета и бизнес-процессов.
7. Несмотря на стереотипы, 1С-разработчики могут успешно переходить в другие области программирования, такие как DevOps.

Ниже представлена текстовая версия ролика, выполненная нейросетью.

Что первое приходит на ум при упоминании 1С? Компания, бухгалтерия, игры. Да, все так, только еще это язык программирования, автоматизация бизнес-процессов и сама платформа, на которой все это работает, включая десятки программ для различных видов бизнеса.

История 1С

С момента появления компании в 1991 году изменилось многое. Сейчас 1С это не про бухгалтеров, это про полноценную разработку. А такие вакансии, как 1С-разработчик или 1С-аналитик, стали привычными вакансиями …на рынке труда. Чтобы понять задачи, которые таким программистам предстоит решать, нужно внести немного ясности и разобраться с тем, как в 1С вообще всё устроено. Во-первых, есть сама компания под названием 1С, а есть платформа 1С с точно таким же названием.

Это программа с закрытым исходным кодом, в которой работают другие программы от 1С, называемые конфигурациями. Бывают они типовые и нетиповые.

Типовые и нетиповые конфигурации 1С

Типовые — это конфигурации, разработанные самой компанией 1С. Она сама их поддерживает и сама выпускает новые версии. Например, сюда относятся бухгалтерия, зарплата и управление персоналом, управление торговлей и множество других.

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

Почему 1С популярен в России

Хорошо, но почему вообще 1С смог стать таким востребованным и популярным в России и СНГ? Дело в том, что продукция компании 1С охватывает практически все функции бизнеса и государственных организаций. Что порождает огромное количество клиентов, которые никогда не оставят 1С разработчика без дела.

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

Можно сколько угодно говорить, что это слишком узкоспециализированное направление в программировании, где еще и код на русском языке. Но если мы посмотрим на рынок в целом, то заметим, что очень многие направления уже давно стали точно такими же узкоспециализированными областями со своим стеком инструментов.

Например, верстка, базы данных, Data Science со своими фреймворками и так далее. Каждое из этих направлений не является универсальным, и перейти из одного в другое, не переучиваясь, конечно же, невозможно. То же самое касается и разработчиков 1С. Как и во многих направлениях, программисты в 1С не столько создают новые продукты, сколько работают с уже готовыми. Они занимаются внедрением и сопровождением программ 1С в организации, то есть совмещают в себе обязанности программиста и системного администратора.

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

Специализации 1С-программистов

Кто-то работает с бухгалтерией, кто-то занимается связкой 1С с интернет-магазинами, а кто-то настраивает мобильные приложения для кладовщиков и курьеров. Чтобы устроиться работать 1С программистом, нужно выучиться и подтвердить свою квалификацию как специалиста. Осуществляется это с помощью сертификаций, которые сама компания 1С и проводит. Выдавая сертификат, она ручается перед своими заказчиками, что специалист достаточно обучен и умеет работать с продуктами. Дают эти сертификаты преимущественно при приеме на работу.

Делятся они на два типа. Это 1С профессионал и 1С специалист. Первый проверяет теоретические знания программиста. Знания самой платформы и одной из типовых конфигураций, например, бухгалтерии. Второй проверяет практические знания после получения сертификата профессионал.

Зарплаты 1С-программистов

Что касается зарплат, то здесь, как и заработок любого программиста, зависит от его квалификации и опыта. Согласно статистике, стажёры получают зарплату от 40 до 70 тысяч рублей, программисты с опытом до 3 лет имеют возможность получать до 180 тысяч, а ведущие разработчики с опытом от 3 лет …выше могут рассчитывать на 200-300 тысяч и больше.

Эти зарплаты сопоставимы с любым другим языком программирования, вроде того же JavaScript, PHP и так далее. Что нужно знать, чтобы устроиться таким специалистом?

Во-первых, это техническая база. Кроме знаний платформы и конфигурации самого языка 1С, требуются знания по работе с базами данных, знания языка SQL и знания языка запросов к базе данных 1С.

Во-вторых, кроме технических знаний, нужно разбираться в основном бухгалтерского и налогового учёта в области законодательства и финансов, ну и понимать бизнес-процессы на самом предприятии.

Хоть 1С это действительно довольно замкнутая система со своим набором инструментов и знаний, это не значит, что 1С-разработчики не смогут при желании уйти в другое направление в программировании.

Практика показывает, что 1С разработчики при необходимости без проблем меняют как языки программирования, так и целое направление своей работы, уходя, например, в DevOps. Все сложности строятся только на стереотипах и неуверенности в себе.

https://www.youtube.com/@AlekOS

1. Альфа-тестирование
2. Бета-тестирование
3. Сценарное и исследовательское тестирование
4. Дымовое тестирование
5. Тестирование в мире 1С
6. Тестирование и комплексные проекты

Самой трудоемкой частью работы по созданию нового ПО является вовсе не написание кода, а процесс его отладки и исправления ошибок. Код пишут люди, а люди не могут не ошибаться. По статистике, на каждую тысячу строк кода приходится от 5 до 15 ошибок, и вот отлавливание этих ошибок и занимает львиную долю времени. Именно для этого и существует отладка. Что такое альфа- и бета-тестирование, мы сейчас и узнаем.

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

После того, как отдельные программные модули готовы, они объединяются в некое единое целое. Это еще не полнофункциональная программа, но она уже способна работать и выполнять, хотя бы частично, свои главные задачи. Такой вариант программы называют альфа-версией.

Альфа-тестирование

Альфа-тестирование — это этап отладки и проверки альфа-версии программы, а люди, которые будут заниматься ее тестированием — альфа-тестерами. Это могут быть штатные тестировщики компании или люди, которые работают по договору, но это квалифицированные специалисты, умеющие работать со специализированным ПО и пользоваться специальными методиками.

По окончании работы с альфа-версией выпускается бета-версия. Она представляет собой реально работающую версию программы с полным функционалом. И задача бета-тестов – оценить возможности и стабильность работы программы с точки зрения ее будущих пользователей. Поэтому на роль бета-тестеров приглашаются просто люди, имеющие опыт работы с программами такого типа или, что еще лучше, с предыдущей версией этой же программы. Обычно у компаний уже есть определенный круг лиц, с которыми они постоянно сотрудничают.

Бета-тестирование

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

И наконец, может быть объявлено открытое бета-тестирование (ОБТ), когда на роль бета-тестеров приглашают всех желающих. Чтобы подключиться к этому процессу, обычно достаточно оставить заявку на сайте производителя и заполнить анкету.

Некоторое отклонение от изложенного порядка допускают компании, выпускающие онлайн-игры. Они нередко начинают привлекать к тестированию своих будущих пользователей еще на стадии альфа-тестов. Связано это с особенностями программирования онлайн-игр. Игровой мир состоит из огромного количества карт, персонажей, оружия, предметов, но «играбельность» нового мира можно проверить и при минимальном наборе всего перечисленного. Это и позволяет привлекать к работе геймеров на ранних стадиях проекта.

Надо сказать, что разработчики не испытывают недостатка в желающих принять участие в такой работе – геймеры народ азартный и каждый желает первым познакомиться с новой игрой (кстати, почему могут тормозить игры читайте здесь). Такого рода сотрудничество приносит пользу обеим сторонам, ведь исправления проще сделать в процессе работы, а не когда она уже завершена, а замечания и пожелания пользователей позволяют сделать игру лучше и интересней.

А уж когда дело доходит до открытого бета-тестирования, там и вообще нет отбоя от желающих. Помимо всего прочего, производитель обычно сохраняет бета-тестерам после перехода на финальную версию их достижения и регалии, заработанные при тестировании. В результате они имеют немалую фору по сравнению с другими игроками, не говоря уже о заработанном игровом опыте.

Сценарное и исследовательское тестирование

Также существуют и другие классификации тестирования: сценарное (scripted) и исследовательское (exploratory).

Основная особенность сценарного тестирования в том, что вы начинаете с того, что делите задачу на этапы (подготовка, выполнение, завершение и пр.) и затем стараетесь производить все действия согласно этим этапам. То есть этот подход можно охарактеризовать как «я думаю на этим заранее и затем выполняю».

Исследовательское тестирование подразумевает совершенно иной подход – разработка процесса тестирования происходит непосредственно во время работы. Тестирование начинается с некой важной точки, в процессе появляются другие важные точки тестирования, и каждый раз специалист решает, какая из них наиболее важна и в каком направлении двигаться дальше. То есть продумывание и запуск тестов происходят в постоянном взаимодействии.

Некоторые люди полностью полагаются на сценарное тестирование и считают исследовательское тестирование опасным. Другие, наоборот, используют исследовательское тестирование и считают сценарное чем-то из прошлого. Я думаю, правы и неправы и те, и другие. Оба подхода могут иметь ценность, но это зависит от ситуации.

Однако эти два подхода к тестированию – не единственные. Кроме них существуют другие подходы, которые находятся где-то между ними.

Почему я расположил их в таком порядке? Исследовательское тестирование практически не требует подготовки, а к сценарному тестированию нужно серьезно готовиться. А, например, сессионное находится где-то посередине – оно требует подготовки, но не столь большой.

Профессиональный тестировщик должен знать о каждом из этих подходов и понимать, какой из них лучше всего подойдет в каждом конкретном случае.

Дымовое тестирование

Еще выделяют такой вид тестирования, как «дымовое».

Smoke-тестирование можно назвать «проверкой сборки», т.к. с помощью дымовых тестов мы проверяем работоспособность и стабильность сборки.

Преимущества Smoke-тестирования:

• простота выполнения тестирования;
• обнаружение дефектов на ранних этапах;
• повышение качества системы;
• экономия времени и ресурсов при тестировании;
• минимизация рисков интеграции.

Чем различаются Smoke, Sanity и регрессионное тестирование

Smoke проверяет рабочее состояние новой сборки. Sanity-тестирование проверяет изменения, которые были сделаны в текущей сборке. Регресс проводится для проверки всего функционала, который был затронут в ходе изменения в текущей сборке.

Дымовое тестирование можно выполнить на любой сборке. Sanity и Регресс выполняются только на стабильных сборках.

Smoke-тестирование может выполняться как разработчиками, так и тестировщиками. Sanity и Регресс выполняются только тестировщиками.

Smoke-тестирование обязательно проводится для каждой новой сборки. Sanity-тестирование делают, только если нет времени на более глубокое регрессионное тестирование. Регрессионное тестирование выполняется всегда, когда нет ограничения во времени.

Как выполняется смоук-тестирование

Smoke-тестирование выполняется при каждой новой сборке. Для этого специалисты определяют минимальный набор тест-кейсов для критически важного функционала. На этапе написания тест-кейсов выделяют приоритетность и серьёзность кейса. В Smoke-прогон входят кейсы с Priority High и Severity Critical — как правило, это основные пользовательские сценарии, набор кейсов для проверок интеграционных модулей.

К примеру, у нас в системе используются сторонние модули для скачивания документов, отображения карт, отправки писем, регистрации через интеграционную систему. Эти кейсы добавлены в Smoke-прогон. Тестировщики должны убедиться, что все критически важные функции работают правильно: подключены ли модули, выполняют ли они свою основную функцию. К примеру, при проверке модуля скачивания документов нужно убедиться, что документ скачивается, а что конкретно в нем отображено – уже задача для регресса.

Тестирование в мире 1С

Как можно заключить из сказанного, тестирование – это очень сложный и, зачастую, процесс поиска без гарантированного результата в силу объективной сложности современных информационных систем, а не рутинное дело, как может показаться на первый взгляд. В мире 1С используется весь спектр технологий тестирования. В последние годы все чаще и чаще упор делается на автоматизированное тестирование, для вымещения «человеческого фактора» и повышения скорости выхода релизов программных продуктов.

На мой взгляд, в практике внедрений продуктов 1С в фирмах-партнерах все же недостаточно внимания уделяется человеческому тестированию и тестированию в широком толковании данного процесса. Под термином «тестирование» обычно понимается процесс проверки функциональности программы после внесения изменений в ее конфигурации на уровне кода. То есть программист внес изменения в программу на основании прописанной аналитиком задачи, которая, в свою очередь, ставится на основе пользовательских требований, собранных в ходе анализа. Я еще пропустил стадию проектирования, но она происходит не всегда.

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

Таким образом, повышается роль технологий тестирования, в т.ч. для снижения фактора «дружественного огня». Также нужно понимать, что тестирование – это всегда проблема репрезентативности и ресурса, также как в социологических опросах. Невозможно опросить всех людей, всегда делается максимально репрезентативная выборка, и чем она меньше и репрезентативнее – тем лучше результат.

Тестирование и комплексные проекты

Однако процесс тестирования имеет более глубокий смысл, в особенности в проектной сфере комплексной автоматизации. Давайте вернемся к этапам классического проектного внедрения:

1. анализ и сбор требований к ПО;
2. проектирование и моделирование;
3. разработка технического решения;
4. подготовка в опытной эксплуатации ПО;
5. опытная эксплуатация.

Бывает опытную эксплуатацию заменяют терминов «опытно-промышленная», но мы не будем придираться к мелочам, сейчас для нас это незначительный момент. Если подходить к процессу тестирования узко, то данный процесс зашит в этапе 3, т.е. после каждой разработки или доработки кода аналитики, ставившие задачи программистам, должны оттестировать выполнение задач. Тем не менее тестирование ведь проводится не только проектной командой, тестирование проводится и на следующих этапах уже самими пользователями, на этапах 4 и 5. Что следует из их названия. Причем организация данного расширенного тестирования приобретает высокое значение, потому как с одной стороны решает ресурсную проблему, он повышает степень «неприятия изменений» со стороны пользователей. Это процесс влияния негативных социальных настроений при внедрении новых бизнес-приложений и учетных систем. Найти баланс между этими двумя факторами жизненно важно.

Более того, не только 3, 4, 5 этапы содержат в себе значительный объем работ по тестированию. На этапе анализа и сбора требований проектная команда также занимается по сути тестированием, проверкой тех же требований на соответствие будущей технической конфигурации. На этапе анализа бизнес-логики удобнее всего фиксировать требования сценарным методом. Другими словами, нужно выстроить описание бизнес-логики в сценарий по максимально возможно мелко нарезанным шагам, это дает повышенный уровень точности и снижает долю неопределенности.

Так, грамотная проектная команда уже на этапе сбора требований, выстраивает все требования к новой информационной системе в сценарном виде (по шагам рабочего процесса). Это дает более системную картинку и привносит наглядность по местам возможных потенциальных противоречий, что бывает крайне часто, т.к. разные функции не обращают внимание на работу своих смежников.

Далее такой сценарий дорабатывается уже на этапе проектирования будущего технического решения и становится основой для приемочного тестирования, как отдельных доработок конфигурации, так и в целом приемочны испытаний всей системы. По этому же сценарию можно производить нагрузочные испытания, а затем и разработать автоматизированные тесты.

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

Как разнообразить работу уже существующих программ на 1С и какие фичи «прикрутить» к базовому софту — рассказал Матвей Серёгин, системный архитектор сервиса «1С:БухОбслуживание», «1С», автор курса «1С-программист: с нуля до middle» и преподаватель Нетологии.

Типовые и нетиповые решения 1С

Под «типовыми» решениями обычно понимают универсальные приложения для управления предприятиями, ведения регламентированного учета, управления кадрами, внутренними документами и т.д. Что такое «нетиповые» решения в этой связи понять тоже довольно просто: это все те конфигурации, которые были разработаны бизнесом с нуля самостоятельно под свои потребности, либо на «голой» платформе, либо с использованием библиотек. Также существуют тиражные решения для конкретных отраслей (например, сельского хозяйства) или стран, с учетом специфики местного законодательства (например, бухгалтерия Казахстана).

На практике «типовое» решение почти всегда кастомизируют, добавляя в него новые объекты, методы, функции, подсистемы. Поэтому на большинстве предприятий используют стандартные решения с несколькими дополнительными или модифицированными нетиповыми функциями. В этой связи сложно сказать, стало ли решения «нетиповым» после того, как предприятие, например, взяло разработанную 1С типовую бухгалтерию и подкрутило пару элементов кода.

Внешние компоненты 1С

Чтобы адаптировать сервисы 1С под задачи конкретного бизнеса, разработчики выходят за рамки типовых возможностей. Одно из распространенных решений — подключение внешних компонентов. Это библиотеки на системных языках, через которые платформа может взаимодействовать с операционной системой. Они позволяют автоматизировать технологические и бизнес-процессы — интеграцию кассового или промышленного оборудования, сбор лидов, обработку данных клиентов с помощью методов машинного обучения.

Отличный пример практически полной автоматизации с помощью 1С и внешних компонентов можно найти в такой тривиальной процедуре, как взвешивание КАМАЗА на промышленных весах перед выездом. Часто этот процесс полностью завязан на человеке: машина заезжает, оператор вводит цифру весов и ее номер в 1С. Здесь автоматизации ноль и есть риск ошибок. Но если через внешнюю компоненту запрограммировать 1С считывать показания весов и через алгоритмы машинного обучение подключить сервис, который будет по камерам считывать номер машины и ее расположение на весах (верное или неверное), заводить данные в систему, то человека-оператора из этого процесса можно будет вообще убрать.

Для достижения подобной автоматизации потребуется работа со встроенным языком платформы 1С. Например, Python помогает интегрировать алгоритмы машинного обучения и ИИ, C++ задействуют для обеспечения максимальной скорости процессов. Расширяемая среда разработки 1С:EDT также поддерживает язык программирования Java, который позволяет прописывать плагины, обеспечивая еще большую гибкость в выборе инструментов. А взаимодействие между внешними сервисами и 1С осуществляется по сетевым протоколам.

Протоколы, которые поддерживает 1С

Самый востребованный сетевой протокол, поддерживаемый 1С — HTTP. Если же планируется большая нагрузка на приложение, приходится дополнительно задействовать брокеры сообщений. Раньше разработчики использовали сторонние решения (RabbitMQ, Apache Kafka). Но теперь у 1С появился свой брокер — 1С:Шина, поэтому в большинстве случаев использование сторонних продуктов не требуется.

Интеграция с мобильными приложениями в большинстве случаев происходит через HTTP, что позволяет обмениваться данными напрямую. А для быстрой отправки пушей прямо в приложение используются промежуточные решения на PHP или Python. Для решения задач по расширению интерфейса внутри платформы используются веб-приложения, написанные на JavaScript. Это позволяет создавать внутри 1С отдельные формы, которые не только выглядят графически привлекательно, но и обеспечивают функциональную гибкость.

Кроме того, по HTTP работают интеграции с ботами (ChatGPT) и Алисой от Яндекса. Также HTTP предпочитают мессенджеры (тот же Telegram или WhatsApp, «ВКонтакте»).

Но иногда приходится задействовать WebSocket – это протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером. Пока у 1С нет полноценной поддержки этого протокола, хотя это и планируется в одной из следующих версий, так что приходится использовать промежуточный код — например, на PHP, Golang или Python.

Еще один протокол, который используют для интеграции 1С с брокерами сообщений (ПО для связи между приложениями, системами и службами, помогающее им обмениваться информацией друг с другом) – это AMQP. Протокол использует термин “vhost”, поэтому для каждого обмена данными между несколькими очередями создается отдельный виртуальный хост в брокере.

Брокер гарантирует надежность доставки сообщений путем использования подтверждений. Если отправитель подтверждает отправку сообщения, то оно попадает в очередь. Это означает, что можно быть уверенным, что сообщение не потеряется или не будет отправлено неправильно.

Безграничные возможности для интеграций

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

Можно даже интегрировать с 1С умную колонку “Алису” и отдавать распоряжения системе голосом. Условно вы просыпаетесь, включаете кофеварку и говорите: «Алиса, расскажи мне о ключевых показателях». Алиса обращается к 1С и, пока вы пьете кофе, рассказывает о том, что происходит в вашем бизнесе. Если в каком-то показателе есть отклонение, вы можете попросить Алису рассказать о нем подробнее.

Другим инструментом, интеграция которого в 1С становится все более популярна и о котором мы писали выше, становится искусственный интеллект. Многие фичи платформа может предложить уже сейчас, а какие-то возможности появятся в ближайших релизах. Но уже сейчас понятно, что с помощью ИИ в системе 1С можно будет (или уже можно) решать следующие задачи:

• Распознавание текста. В контексте 1С речь, разумеется, о распознавании первичных документов (сканы накладных, актов и т.п.). Раньше этим занимались менеджеры и бухгалтеры и делали это вручную. Теперь эту заботу берет на себя сервис на базе машинного обучения, который распознает документ и передает его в 1С. А человеку остается только проверить некоторые важные части, где ИИ мог ошибиться.

• Распознавание и синтез речи. Уже сейчас с 1С можно интегрировать облачный продукт с функциями потокового и файлового распознавания, который преобразует речь на русском и английском языках в текст. А скоро в 1С появится возможность полноценной интеграции голосовых помощников на основе ИИ, что позволит пользователям взаимодействовать с программой голосом. Это сделает использование 1С еще более удобным: например, менеджер по продажам, заполняя договор, может попросить у программы голосом открыть реквизиты клиента. Или бухгалтер, составляя отчет, попросит статистику за определенный период. Для слаженной работы двух сервисов — распознавания и синтеза речи — разработчик должен написать алгоритм, который по ключевым словам будет понимать характер запроса, «доставать» из базы данных нужную информацию, преобразовывать ее в нужный вид и передавать механизму синтеза речи.

• Прогнозирование спроса — еще один полезный инструмент на базе ИИ, который интегрируется в 1С. С помощью математических моделей и ML сервис на основе данных прогнозирует, что и когда в предстоящем году будут покупать. Это позволяет освободить от рутинных расчетов маркетологов, которые могут сосредоточиться на проработке стратегии продаж.

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

Например, сейчас в тренде генеративные нейросети. В будущем кажется логичным добавить интеграцию с Chat GPT, Midjourney или аналогами. Она значительно облегчит задачу тем, кто занимается составлением писем, рассылок и прочей документации. Чтобы не тратить время на обращение к сервисам самостоятельно и получить текст или картинку от нейросети всего за несколько секунд, запрос можно будет направить непосредственно в 1С.

Как стать разработчиком 1С

Учитывая потенциал программных решений 1С, умеющие работать с этими продуктами специалисты всегда будут востребованы. Статистика неумолима: спрос на таких сотрудников растет каждый месяц. И если год назад количество вакансий превышало 8 тысяч, то сейчас их уже больше 11 тысяч.

Чтобы стать одним из таких разработчиков, для начала нужно освоить саму платформу и научиться применять базовые инструменты 1С. После этого уже можно говорить о специализации и прикладном программировании. Например, специалист интеграции 1С с мобильными приложениями должен знать, как отправлять пуши, как сделать микро-сервис, как работает WebSocket и HTTP. У того, кто занимается интеграцией решений машинного обучения, уже совсем другие компетенции — он должен владеть Python с его библиотеками и фреймворками, SQL для операций с большими объемами данных, хорошо ориентироваться в различных средах разработки.

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

Эзотерические языки привлекают разработчиков своей оригинальностью, креативностью и часто юмористическим подходом. Эти языки могут использовать необычные символы, слова или концепции для написания программного кода.

Мы наткнулись на репозиторий GitHub, в котором собраны программы Hello World на разных эзотерических ЯП, и решили показать их вам в этой подборке.

Squirrel

Это код на языке программирования Squirrel, который был создан в 2003 году. Squirrel — динамический, высокоуровневый интерпретируемый язык, разработанный для встраиваемых систем и видеоигр.

1C

Язык программирования 1С основан на высокоуровневом языке запросов, который легко понять и использовать.

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

Вот, почему автор включил 1С в свою подборку:

Да, он считается рабочим, и не эзотерическим, но нам нем так мало пишут (в плане работает людей), что он уже как эзотиреческий xD

ArnoldC

ArnoldC – это необычный язык программирования, в котором синтаксис и ключевые слова основаны на фразах Арнольда Шварценеггера из его фильмов.

ArnoldC предлагает ограниченный набор функций и возможностей, но специально разработан для развлечения. Он не предназначен для серьезного использования.

Brainfuck

Brainfuck – это экстремально минималистичный, тьюринг-полный, интерпретируемый язык программирования, который был создан для вызова трудностей и обучения программированию.

Он использует всего лишь 8 команд, которые представляют простейшие операции, такие как перемещение по памяти, увеличение/уменьшение значения ячейки памяти и ввод/вывод данных.

Chef

Chef – это необычный и шуточный язык программирования, который имитирует написание рецептов для приготовления блюд.

Код на языке Chef структурирован в виде рецептов с ингредиентами, шагами приготовления и кулинарными терминами. Использование языка требует понимания кулинарных терминов и общей структуры приготовления блюд.

Doge

Язык программирования Doge – это шутливый и неформальный язык, вдохновленный интернет-мемом с изображением пса породы шиба-ину.

Он использует нестандартный синтаксис, основанный на фразах и выражениях из популярных мемов.

Emoji

Язык программирования Emoji – это экспериментальный язык, в котором используются символы эмодзи вместо традиционных кодовых конструкций. Каждый эмодзи представляет определенную операцию или значение.

L33t

Язык программирования L33t (или Leet) – это неформальный язык, основанный на замене букв на числовые или специальные символы, чтобы создать эффект “хакерского” стиля. Он используется в основном в сообществах хакеров и геймеров для шифрования и сокрытия кода.

L33t не является популярным языком для разработки, но может быть интересным для создания прикольных эффектов или шуток внутри сообществ.

Rockstar

Язык программирования Rock (или Rockstar) – это необычный и шутливый язык, вдохновленный рок-музыкой и знаменитыми рок-исполнителями.

Вместо традиционных ключевых слов и операторов, в Rock используются песенные стили и фразы, чтобы написать программный код.

ShinobiScript

Это — язык программирования от автора репозитория, операции в котором переименованы на манер японского языка и отсылают к аниме.

TeaScript

Ещё один язык программирования от автора репозитория. По всей видимости, он подражает британской вежливости во время чаепития в пять часов вечера.

YoptaScript

YoptaScript – это юмористический и пародийный язык, созданный с целью подражать языку гопников и подчеркнуть связанные с ними стереотипы.

Он содержит множество шуток, карикатурных синтаксических конструкций и абсурдных функций.

Zombie

Вместо обычных команд и операторов, Zombie использует слова и фразы, связанные с зомби-апокалипсисом, чтобы создать легко узнаваемый и запоминающийся синтаксис.

DuckyScript

Язык программирования, который используется для написания скриптов для устройств Rubber Ducky.

Rubber Ducky – это USB-устройство, которое может эмулировать клавиатуру и выполнять автоматические действия на компьютере. DuckyScript позволяет записать последовательность нажатий клавиш и команд, которые могут быть автоматически выполнены на целевом компьютере при подключении Rubber Ducky.

LOLCODE

LOLCODE – это эзотерический язык программирования, который использует фразы из интернет-мемов и популярных шуток для написания кода.

Вместо стандартных ключевых слов LOLCODE использует фразы вроде “HAI” (приветствие), “KTHXBYE” (прощание), и “VISIBLE” (для вывода на экран).

Заключение

Если вам понравилась подборка, зайдите на репозиторий и оцените его.

И обязательно напишите в комментариях, какие ещё эзотерические языки вы знаете, которые не были упомянуты в статье — мы их изучим и, может быть, напишем про них отдельную статью. ?

Гипермаркет загородной жизни «Новый дом» состоит из двух частей. Первая часть посвящена покупке загородной недвижимости. Вторая — продаже услуги строительства домов по готовым проектам.

Остановимся на первой части. На сайте можно купить участки, коттеджи, таунхаусы, дуплексы. Продавцами являются компании-застройщики.

Клиенту было важно автоматизировать работу с продавцами недвижимости и загрузку объектов на сайт.

Схема автоматизации

Данные по объектам вносятся продавцами в Google-форму. Далее информация об объекте недвижимости складывается в таблицу с функцией редактирования. Менеджеры агентства недвижимости проверяют, дополняют информацию об объекте и разрешают его выгрузку на сайт.

У клиента есть несколько категорий объектов: поселки; участки; дома, таунхаусы, дуплексы. Каждая вкладка — это набор объектов определенной категории со своими параметрами. Символом * клиент отмечает в таблице поля, которые необходимо вывести на сайт. Поля без этого символа используются для внутренних нужд и на сайт не выгружаются.

Объекты из каждой категории перемещаются в соответствующие категории на сайте.

После отметки «Да» в столбце «Поселок проверен и готов к размещению» парсер заберет объект и выгрузит на сайт.

Каждую ночь парсер забирает данные из Google Таблиц и загружает на сайт.

После продажи объекта, в Google Таблицах менеджер обновляет статус на «Продан». Потом парсер обновляет данные в справочнике сайта, и объект остается на сайте со статусом «Продан» и не выводится в доступных для покупки.

Как работает парсер

Парсер позволяет работать с Google Таблицами посредством их API.

Через него происходит прием данных из Google Таблиц на сторону Битрикс.

Для выгрузки данных из Google Таблиц через функционал «именованные диапазоны» столбцам мы назначили уникальные символьные коды, определяющие их категорию (поселки, участки, дома/таунхаусы/дуплексы) и свойство.

Далее через скрипт получили столбцы, у которых существуют «именованные диапазоны» и провели их обработку.

Каждое значение ячейки столбца идет в аналогичное его коду в «именованном диапазоне» свойство на сайте.

Например, столбец с кодом именованного диапазона WATERPOOL подтягивается в свойство WATERPOOL («Бассейн») на сайте.

Еще одна особенность — возможность загрузки фотографий через Google Таблицы. Для этого код в «именованном диапазоне» должен быть вида «PHOTO_#КОД_СВОЙСТВА#», а само значение ячейки — ссылкой на Google Диск.

На этом уровне мы использовали API Google Диска для получения загруженных на Google Диск фотографий.

Как хранятся данные на стороне «1С-Битрикс»

1. Разделы в каталоге — это поселки, которые идут из отдельной категории «Поселки» таблицы Google Docs.

2. Все элементы — это внутреннее наполнение поселков: участки, коттеджи, дома, таунхаусы. Получается, каждый элемент принадлежит какому-либо поселку.

3. Свойства элементов и объектов — это столбцы из таблицы Google Docs.

Для поиска по объектам используется модуль elasticsearch. Запросы к нему идут через внешнюю оболочку, предназначенную для работы с «1С-Битрикс».

Хранение данных elasticsearch происходит в специальной карте индекса для инфоблока каталога.

После выполнения парсинга сырые данные элементов через метод $indexer->put попадают в наш индекс.

Соответственно, для дальнейшей фильтрации по данному индексу, вместо стандартных запросов «1С-Битрикс» по API «1С-Битрикс», также необходимо пользоваться конструкцией $indexer->search со своими параметрами.

Разработанный функционал позволяет клиенту экономить время менеджеров, исключить ошибки при переносе данных и заниматься более творческими и сложными задачами.

Если есть вопросы, пишите в комментариях.

В админке «1С-Битрикс» на странице обновления есть такое сообщение:

Для CMS Bitrix версия PHP 7.Х устарела. Исправления функциональных ошибок и ошибок безопасности Bitrix для этой версии больше не выпускает. Компания предлагает всем своим клиентам обновиться.

Это сообщение расстроило разработчиков. Переход на новую версию PHP очень болезненно воспринимается для легаси кода, так как есть важные обновления синтаксиса PHP, ломающие обратную совместимость. Многие модули из маркетплейса давно заброшены и не адаптированы под новые версии PHP.

Готовимся к обновлению

Ориентировочно на обновление ядра с большим прыжком в версиях PHP закладывается от 15-20 часов. Если проект «запущен», их может не хватить. Добавляем страховочный запас 10-15 часов исходя из объема легаси.

Составляем полный чеклист проверки функционала сайта, чтобы не забыть протестировать.

Рядовые шаги для обновления «1С-Битрикс»:

1. Обновить Bitrix локально, исправить баги после обновления.
2. Обновить версию PHP локально, исправить баги.
3. Обновить на тестовом стенде, если первые два пункта не выполнялись сразу на тесте.
4. Исправить баги после тестирования.
5. Обновить на бою.
6. Исправить баги после обновления на бою.

Несколько важных деталей, которые нужно учесть перед началом обновления:

— До версии 22.500.700 ядра Bitrix можно спокойно обновляться на PHP 7.4, проблем с обратной совместимостью внутри ядра не найдено.

— Шаг 6 почти неизбежен, потому что на 100% проверить тестовый стенд не удастся. Чаще всего есть какой-то код, который отрабатывает в процессе интеграции с боевой площадкой. Если тестовой площадки для интеграции вовсе нет, тогда можно проверить ее только фиктивно, например, через Postman. Все равно придется проверить работоспособность на бою.

— В 9 из 10 случаев проект развернут не в Docker, следовательно нет возможности проставить нужные параметры PHP при обновлении с помощью версионного контроля или обновления утилит для него. Можно только фиксировать его отдельно в копии конфигурационных файлов или в списке утилит для установки.

Шаг 1. Обновляем Bitrix на локальном хосте

Начинаем обновление Bitrix на локальном хосте или на удаленном тестовом сервере.

Базы данных (БД) и ядро должны быть свежими, чтобы исключить ошибки, не связанные с обновлением Bitrix. На локальный хост или тест накатываем свежий бэкап ядра с БД через restore.php, публичная часть не обязательна. Если бэкап сгенерировать не удается, помогут утилиты mysqldump и rsync с опцией delete.

В административной части на странице /bitrix/admin/site_checker.php?lang=ru в разделе «Тестирование базы данных» ошибок быть не должно.

Обновление ядра и модулей мы оставляем на плечи системы обновления Bitrix, исправление кода проекта — на версионный контроль.

Проблемы, которые могут возникнуть в процессе обновления:

1. Ошибка в синтаксисе PHP. При обновлении может зацепиться какой-нибудь обработчик события, чаще всего для построения кастомного типа свойства инфоблока.

Решение. Лезть в код и фиксить ошибку. Каждую такую ошибку фиксировать у себя в доке, чтобы можно было быстро сделать исправление при обновлении на тесте и на бою. Как только ошибка будет исправлена, можно продолжить обновление.

2. Ошибка в MySQL. Пользователю БД может не хватать прав для обновления таблиц или выполнения команд типа set innodb_strict_mode=ON. Либо конфигурация сервера может не соответствовать боевому.

Решение. Выполнить нужные конфигурации БД, например, выделить для БД больше буферной памяти или расширить права доступа пользователя под которым общается Bitrix с БД. Перезапустить обновление.

3. Заблокирована система обновлений. Ошибка частая, так как тестовые хосты имеют открытый доступ из интернета. Bitrix обнаруживает такие хосты и блокирует систему обновления не по лицензии.

Решение. На время обновления на тестовые хосты повесить базовую авторизацию или вовсе выключить их. Написать в техподдержку Bitrix запрос на удаление ошибки обновления. После этого — продолжить обновление.

4. Не хватает прав на изменение файлов. Распространенная проблема Linux, когда у пользователя сервера не хватает прав, чтобы создать или изменить нужные файлы ядра. Это особенно заметно при обновлении ядра.

Решение. Настроить конфигурацию сервера, чтобы он работал от имени текущего пользователя, не рутом. Выполнить рекурсивную смену прав в ядре командой chown -R. После таких операций проблема должна уйти и можно продолжить обновление.

Как только обновление прошло успешно, переходим наобновление модулей потомуже принципу.

Если модуль платный и лицензия истекла, ее нужно продлить. Если ошибка после обновления модуля не пропала, то модуль необходимо удалить. Если править модуль, то в дальнейшем его нельзя будет корректно обновить.

Если модуль очень старый и давно не обновляется, его придется перенести в локальную область и содержать самостоятельно.

После успешного обновления Bitrix и модулей переходим в публичную часть, проверяем основной важный функционал сайта, фиксим ошибки PHP или конфликты с API Bitrix и модулей.

Приступаем к обновлению версии PHP после обновления Bitrix и проверки работы проекта.

Здесь может возникнуть больше всего сложностей, так как кодовая база ссылалась на «помощь» со стороны PHP 7.4. Код, который раньше выполнялся на PHP 7.4 с предупреждениями, на PHP 8.2 будет падать с фатальной ошибкой. Это позволит определить нерабочий функционал.

Основные критичные для Bitrix ошибки, которые вылезают после обновления версии PHP:

1. Нестатические методы для обработчиков событий. В PHP 8.2 больше нельзя вызывать нестатические методы через статический синтаксис. Это касается обработчиков событий. Если они находятся внутри класса в виде функции, то, чтобы ошибка ушла, в каждую такую функцию нужно будет добавить public static.

2. Статический вызов нестатических методов. Ряд модулей в проекте были перенесены в локальную область уже очень давно, синтаксис сильно устарел. Было много методов через чистый function, поэтому нужно добавлять к каждому методу public static.

3. Строгая типизация при работе с стандартными функциями PHP. В PHP 8.2 нельзя передавать в функцию count() значения типа null или string. В нашем случае компонент Menu был построен на вложенных массивах внутри параметра ADDITIONAL_LINKS. Так делать нельзя, так как в ядре Bitrix проверка выполняется через Rel2Abs — она принимает на вход строку, но не массив. Этот функционал был переписан через дополнительные параметры.

4. Обращение к строке как к массиву. В шаблонах часто возникают старые ошибки с ключом VALUE для вывода значения свойств. Оно не у всех есть, поэтому страница падает.

5. Старые обработчики событий Bitrix, которые ссылаются на несуществующие классы/методы. Обработчики событий модуля регистрируются не через код, а записываются в таблицу b_module_to_module в БД. Если когда-то был использован кастомный модуль, который меняли так, что доступа к обработчикам нет; или модуль был удален на уровне кодовой базы, а из БД ничего не стиралось — здесь это проявится, возникнут фатальные ошибки при попытке их исполнения. Решение простое: корректируем эти обработчики события в БД или удаляем строки вовсе. Можно это сделать сразу на бою/тестовом хосте, чтобы после обновления не натыкаться на такие проблемы.

В процессе исправления ошибок очень важно не забывать, что главная задача — обновление ядра и версии PHP. Рефакторить код на этом этапе НЕ НУЖНО.

Шаг 2. Проверяем на тестовом контуре

Автотестов и каких-либо тестов на написанный код в Bitrix чаще всего нет. А разработчик может обнаружить только столько проблем, на сколько он наткнется. Поэтому обязательно нужно делать проверку на доступном заказчику/тестировщику тестовом хосте.

Выполняем обновление на тестовом хосте, если проблем на локальном больше найти не можем:

• собираем в версионный контроль все изменения кодовой базы проекта,
• на тесте выполняем обновление ядра, смену версии PHP, подтягиваем через версионный контроль исправления кода,
• отдаем сайт на проверку тестировщику или заказчику.

При тестировании важно отсеивать только ошибки, связанные с обновлением.

1. Если ошибка воспроизводится и на бою, выносим в отдельную задачу.
2. Если ошибка связана с тем, что проект развернут на тестовом хосте, игнорируем, так как настройка тестового стенда будет отдельной задачей.
3. Если наблюдаются просадки по производительности, это нормально — тестовый хост на несколько порядков медленнее прода.

Проверка на тестовом хосте не даст гарантии, что на тесте новых проблем не будет, так как часто нет возможности проверить интеграции или обмен с «1С-Битрикс».

На тесте необходимо также тщательно проверять весь функционал, как илокально. Обычно натесте появляются новые ошибки, которые неудалось обнаружить локально.

Если на проекте есть тестировщик, то ему нужно проверить весь функционал сайта, включая формирование фидов. А при наличии тестовых площадок — еще и общение с внешними системами.

На практике возникали проблемы с интеграциями, в частности с генерацией фидов разной степени важности, ошибками в обработчиках событий при интеграции с внешними площадками. Их обнаруживали только на бою, что очень расстроило заказчика. Поэтому важно проявлять проактивность и следить за выполнением агентов на тесте или cron-скриптов. Скорее всего после смены версии PHP поменялась версия и PHP CLI. Поэтому необходимо проверить работу всех cron-скриптов.

Шаг 3. Обновляем Bitrix на бою

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

На проде обновление Bitrix занимает от 1 до 5 часов. Многое зависит от объема проекта и потенциальных багов, на которые можно наткнуться после, даже с учетом проверок на тесте.

Предварительно проверяем работу системы обновлений Bitrix на бою, так как в нужное время она может заблокироваться и придется переносить время обновления. Техподдержка работает с 10:00 до 19:00.

Обновляем систему в неактивные часы в начале или в середине рабочей недели.

Обычно обновление планируют в 20:00-21:00, чтобы было меньше пользователей., т.к. сайт в это время будет недоступен.

Выполняем стандартные шаги обновления Bitrix:

1. Закрываем публичную часть. В настройках главного модуля жмем кнопку «Закрыть доступ для посетителей». У всех пользователей, кроме админов, будет заблокирован доступ к публичной части. Это делается для того, чтобы в процессе подготовки бэкапа не появились новые заказы или отзывы, которые потеряются, если придется восстанавливаться из бэкапа.
2. Делаем полный бэкап сайта. Чтобы ускорить процесс, рекомендуем исключить из бэкапа папку Upload, а также разделы с кэшем Bitrix и другими бэкапами сайта.
3. Обновляем Bitrix и модули по аналогии с локальной и тестовой версией. Проверяем результат в публичной части.
4. Обновляем версию PHP, тянем через версионный контроль исправления кода, выполняем проверку в течении 10-15 минут на наличие ошибок PHP. Важно их быстро обнаружить и исправить. Для быстрого деплоя таких «хотфиксов» рекомендуем настроить удаленный деплой через IDE, например, PHPStorm. Это позволит править файлы не через файловую систему, а быстро находить проблемные места и вносить корректировки через развернутый проект. После окончания работ все изменения можно будет собрать на бою через версионный контроль и залить в репозиторий.
5. Открываем публичную часть, проверяем работу сайта, запускаем тесты и проводим ручное тестирование критичного функционала, правим ошибки, следим за логами Bitrix на наличие скрытых ошибок. На этом этапе можно сказать, что обновление успешно завершено. В течении суток может что-то всплыть, поэтому оставляем сайт на ночь. На следующий день смотрим на логи ошибок, правим.

Важно не забывать, что ошибки рано или поздно закончатся, поэтому относиться к ним нужно спокойно и размеренно. Ведь код, который раньше выполнялся с предупреждениями, скорее всего был построен неверно или интерпретировался не явно, поэтому функционал мог сбоить или не работать. А теперь часть легаси может актуализироваться и возобновить работу.

Если всплыла ошибка катастрофических масштабов на бою, то останавливаем обновление, закрываем публичную часть, разворачиваем резервную копию Bitrix, которую мы сделали перед обновлением. Если есть изменения, ломающие обратную совместимость, откатываем исправления кода.

Основные подводные камни при обновлении до PHP 8.2

У Bitrix есть остроспецифические проблемы, кроме очевидных для каждого этапа:

1. Обмен с 1С. При обновлении или создании товаров из 1С могут «посыпаться» товары с неверно объявленными свойствами. Например, для типа строка передается массив. Это видно в логах PHP, но исправлять нужно либо на уровне Bitrix, либо на уровне 1С. Чаще исправляем на стороне сайта, внесение изменений в 1С чревато серьезными последствиями.

2. Плавающие ошибки. Часто функционал отрабатывает через раз — то ли в count() передается массив, то ли просто значение null. Это классический пример небезопасного программирования. Для понимания обычно хватает проверки на тип данных.

3. Нестандартное обращение с API Bitrix. У нас все расписано на примере компонента меню Bitrix, файл меню был дополнен руками для создания вложенных массивов. Это только одна из возможных проблем, когда приходится переписывать работу компонента через что-то, что не отваливается при запуске.

4. Обмен с интегрируемыми системами. Чаще всего интеграция Bitrix с внешней системой реализуется модулем с маркетплейса, который обновляет создавшая его команда. Обновление интеграции сводится к обновлению модуля Bitrix из админки. Бывает, что интеграцию пишет команда разработки для определенной задачи, тогда и ее обновление в идеале должна сделать команда перед обновлением Bitrix.

С какими ошибками вы сталкивались при обновлении? И как их решали? Пишите в комментариях.

Я выполнял различные задачи от поддержки сервисов горнолыжного комплекса Лаура до внедрения автоматизированной системы учета сети рознично-оптового цветочного бизнеса, в конечном счете дорос до главного разработчика 1С. В это время я постоянно развивался, готовился к сдаче разных экзаменов.

В итоге успешно окончил окончил международные курсы по CISCO, в итоге я получил 7 сертификатов профессионала и  2 сертификата специалиста по 1С, которые, честно признаюсь, дались мне нелегко.

Было вложено много моих сил в то, чтобы стать специалистом 1С и казалось бы, желаемого я достиг.

Переезд в пандемию

Я не из тех, кто остается на достигнутом, когда я понял, что дошел предела в 1 С, то решил что-то поменять и  идти дальше. В конце 2019  я пошел на переподготовку в онлайн-школу GeekBrains, я хотел погрузится в программирование глубже, систематизировать свои знания в языке python. На тот момент я работал в компании НАО “Красная поляна” как ведущий разработчик 1С.

Через какое-то время пришел к выводу, что для моего развития необходим еще и переезд. Летом 2020 года я переехал в Санкт-Петербург из Сочи и устроился в компанию ТИТАН-2 как программист 1С в разгар пандемии ковид-19. Это был крупный международный проект по строительству атомной станции в Турции, несомненно, этот опыт для меня был развивающим и еще раз показал, что всегда есть куда расти.

Как ушел в Python

Работая в Санкт-Петербурге, я продолжал проходить курсы по Python. Обучение проходило в дистанционном формате, но все равно требовало моего времени и усилий, конечно, я изучал и дополнительную литературу, задавал вопросы, старался дойти до сути и глубокого изучать проходимые темы. В конечном счете я сдал итоговую работу и получил диплом о переподготовке.  Параллельно я искал работу и проходил довольно много собеседований в поиске места для души и развития.

Как стал Тимлидом разработки на Python

Я проработал не в одном проекте в качестве разработчика на Python. В какой-то момент перешел в компанию “РОСБАНК” на должность разработчика, тогда я зарабатывал намного меньше возможного и желаемого.

Спустя несколько месяцев работы в компании случился переломный момент, в который я взял на себя ответственность и повел за собой команду.  В дальнейшем я стал тимлидом разработки, на данный момент в моей команде: 4 разработчика, 1 девопс инженер, 1 дизайнер и 2 тестировщика. Недавно наш продукт: “Инвестиционная платформа Advisors’ Axiom” занял 3 место в номинации “Кейс года” от премии Ruward Award 2023.

Совет от меня

Часто людям бывает страшно начинать что-то новое, кажется, что не получится/ неохото выходить из зоны комфорта. В таком случае, вы скорее всего не имеете цели или оно вам действительно пока не нужно. Но если вам кажется, что вы уже достигли желаемого, значит дошли до конца и стоит выбрать другую дорогу, пусть это будет другой язык программирования, должность или еще что-то. В новой дороге  много интересного и мой опыт это подтверждает. Я уверен, что и к этой моей истории будет продолжение, так как нет предела совершенству. А вам я желаю начать писать свое продолжение прямо сейчас и принимать шаги для его исполнения.

В своей работе мы постоянно ищем интересные и нужные решения. Одно из них — использование дробного количества товара в «1С-Битрикс» для продажи, к примеру, тканей или сыпучих материалов.

Преимущества продажи дробного количества

1. Экономия. Особенно важно для клиентов, которые работают над небольшими проектами или имеют ограниченный бюджет, либо когда товар стоит дорого (ткани бывают очень дорогие).
2. Сокращение отходов. Клиенты могут заказывать материалы в точных количествах.
3. Повышение удовлетворенности и лояльности клиентов. Клиенты получают больше контроля над своими покупками.

Процесс внедрения

Расскажем, как мы внедрили функцию продажи дробного количества на сайте Manders (интернет-магазин красок, обоев, тканей, лепнины, популярный поставщик декоративных материалов ведущих мировых брендов на российском рынке).

При разработке интернет-магазина необходимо было предусмотреть возможность использования дробного количества товара при добавлении в корзину.

Это потребовало изменение кода. В «1С-Битрикс» есть встроенная возможность использования коэффициента единицы измерения для дробного количества через поле ‘RATIO’ у товара, но выгрузка этого поля из «1С» на момент разработки интернет-магазина не поддерживалась. По официальной информации, на данный момент некоторые последние версии «1С» данный функционал уже поддерживают.

Как решить проблему с RATIO

Проблему с выгрузкой поля ‘RATIO’ у товара из «1С» решили следующим образом.

В разделе административной части «Магазин → Настройки → Единицы измерения» выгружаются отдельные единицы измерения для разных видов товаров. Также единица измерения импортируется из «1С» в поле товара CML2_BASE_UNIT.

Нам требовался дробный коэффициент единицы измерения только при использовании единицы измерения «метр погонный» у товара.

При добавлении/обновлении товара обработчики (OnAfterIBlockElementAdd/OnAfterIBlockElementUpdate) перехватывают товары с определенной единицей измерения в поле CML2_BASE_UNIT.

После этого мы получали текущий коэффициент запросом:

В случае, если он отличался/не был создан, мы обновляли/создавали свой коэффициент через:

и:

соответственно.

При желании коэффициент можно передавать в отдельном свойстве каждого товара, а после — перехватывать при добавлении/обновлении товара.

Таким образом можно изменять коэффициент единицы измерения товара в случае невозможности его передачи из «1С».

Внедрение функции продажи дробного количества товара было успешным. Она не только улучшила пользовательский опыт на сайте, но и помогла выделить сайт нашего клиента среди конкурентов и повысить лояльность клиентов. Как веб-студия, мы стремимся постоянно совершенствовать сайты наших клиентов и предоставлять им инструменты, необходимые для успеха на конкурентном онлайн-рынке.

Наша команда INDEXIS в 2022 году выпустила проект NEDRARU.RU на системе «1С-Битрикс». Эта онлайн-площадка позволяет купить, продать, сдать в аренду участок недр или месторождение, а также найти надежных поставщиков и подрядчиков.

Как работает система подписания документов на портале

На портале во время проведения аукционов участвуют 3 стороны: портал, создатель аукциона и участник аукциона. У любого пользователя, который зарегистрировался на сайте как владелец объекта, есть возможность создать аукцион по опубликованному им объекту на продажу или аренду.

Для юридического проведения аукционов между площадкой, создателем аукциона и участниками аукциона необходимо, чтобы все стороны подписали документы посредством электронной цифровой подписи (ЭЦП). Создателю и участнику аукциона необходимо заранее самостоятельно оформить ЭЦП в любом аккредитованном удостоверяющем центре.

Документы для аукциона подписываются на сайте аккредитованного удостоверяющего центра (далее — «Сервис»).

Как мы выбирали удостоверяющий центр

Мы обратились в несколько аккредитованных удостоверяющих центров. Как оказалось, не все центры готовы заниматься интеграцией своего инструментария во внешние сервисы, так как это не их профильная услуга. Нашим предложением заинтересовались коллеги в «Инфотекс Интернет Траст». Для сотрудничества с нами сервис выделил опытного специалиста. Мы остались довольны, смогли оперативно и качественно реализовать все задачи:

1. Автоматическая регистрация пользователя в сервисе «Инфотекс Интернет Траст» с передачей данных о нем с портала.
2. Передача документов на подпись с портала и формирование ссылки на подпись для участников.
3. Получение статуса подписи (прошла успешно / не подписан) с сервиса «Инфотекс Интернет Траст» на портал.

Описание технической части процесса

Мы провели интеграцию с сервисом через создание клиентской части на PHP в «1С-Битрикс». Клиентская часть взаимодействует с сервисом по API.
Работа с сервисом «Инфотекс Интернет Траст» состоит из двух частей:

1. Взаимодействие с API саморегистрации пользователей для проверки и регистрации новых пользователей на портале «Инфотекс Интернет Траст».
2. Взаимодействие с API передачи документов.

Оба API выполнены в архитектурном стиле REST и описаны по спецификации OpenAPI. Отличие между ними — в типе аутентификации. В первом случае для проверки запросов используется идентификатор вашей организации, выданный сервисом. Во втором — полноценный токен, возвращаемый с сервера «Инфотекс Интернет Траст» посредством передачи пары логин-пароль.

Сервис предоставляет разработчикам краткие сценарии использования основных функций, описание API, а также адрес dev-площадки для тестирования.

Для обмена с API в рамках PHP можно использовать клиентскую библиотеку curl. В «1С-Битрикс» мы использовали встроенный класс httpclient.

Рассмотрим процесс поэтапно.

Регистрация пользователей с портала в сервисе «Инфотекс Интернет Траст»

Первоначально наша задача состояла в регистрации пользователей с портала в сервисе «Инфотекс Интернет Траст».

Регистрация происходит посредством создания заявки на регистрацию путем передачи персональных данных пользователя и открытой части ключа электронной подписи.

Формируем на /api/v2/b2b-requests post-запрос вида:

Где sourceId — уникальный идентификатор нашей организации, выдаваемый «Инфотекс Интернет Траст», а certificateBase64 — открытая часть ключа подписи пользователя в формате Base64.

В requestSourcesIds аналогично передаем наш идентификатор, чтобы зарегистрированный пользователь сразу появился в нашем списке контрагентов на сайте «Инфотекс Интернет Траст».

Остальные поля — это просто соответствующие данные пользователя.

При корректно заполненной информации в ответе в поле ["data"]["orderId"]; получаем id нашей заявки по регистрации.

2. Проверка заявки на регистрацию

Далее мы можем проверить статус нашей заявки на регистрацию через get-запрос вида:

Где orderId — это id нашей заявки, полученной на предыдущем шаге.

После успешной регистрации пользователя можно приступать к работе с документами через второе API.

3. Работа с документами через API: получение токена

Здесь наша задача состоит в получении токена, который потребуется для всех дальнейших операций, передав пару логин-пароль по адресу /api/auth/login/.

Для этого формируем запрос к серверу:

В ответе с сервера в поле token получаем токен. Далее ставим его в заголовок всех наших будущих запросов:

4.Работа с документами через API: отправка документов на подпись

Чтобы отправить документы на подпись, нам необходимо получить уникальный идентификатор пользователя, зарегистрированного нами в «Инфотекс Интернет Траст».

Он входит в список наших контрагентов, поэтому мы можем получить этот идентификатор запросом поиска по контрагентам:

Где $searchStirng — это ИНН нашего пользователя.

Теперь отправляем документы на подпись запросом на /api/workflow.

Документы, как и открытая часть ключа, передаются в формате base64.

Дополнительно нам понадобится параметр contractorRecipients. Параметр представляет собой массив с идентификаторами пользователей, которым отправляются документы.

Используем наш идентификатор, полученный на предыдущем шаге.

В результате получаем id операции в поле id.

По id мы формируем ссылку на сайт вида https://b2b.iitrust.ru/workflow/#ID_Операции#.

По этой ссылке будет происходить подписание документов в сервисе «Инфотекс Интернет Траст».

Основная работа завершена.

5. Работа с документами через API: подпись документов

Теперь мы можем передать эту ссылку стороне, отправляющей документы на подпись (в нашем случае — оператору ).

В интерфейсе «Инфотекс Интернет Траст» по нажатию кнопки «Отправить на подписание» происходит передача документов принимающей стороне (пользователю, которого мы зарегистрировали).

Страница подписания для нее также становится доступна по используемой ранее ссылке https://b2b.iitrust.ru/workflow/#ID_Операции#.

Отслеживать состояние процесса подписания со стороны сайта (подписано, аннулировано, отправлено и др.) мы можем запросом на /api/workflow/.

Где $operationID — это id нашей операции. В поле state вернется ее текущий статус.

На этом техническая часть по настройке подписания документов при помощи ЭЦП завершена.

Наш клиент получил реализованный под ключ проект. Теперь проводить сделки по купле-продаже и аренде участков недр или месторождений стало удобнее и проще.

Если есть вопросы, пишите в комментариях.

Клиент попросил сделать апгрейд сайта, который мы разработали несколько лет назад — профессиональный ресурс для диджеев JesteiPool. Сервис позволяет диджеям скачивать сеты для своей профессиональной деятельности. Сайт был написан на «1С-Битрикс».

Заказчик решился на глобальные изменения:

1. Полностью изменить дизайн.
2. Добавить элементы соцсети — ленту новостей; функцию подписки на обновления различных исполнителей и плейлисты; отображение порядка треков и плейлистов должно автоматически меняться в зависимости от предпочтений, выбранных пользователем.
3. Сделать беспрерывное воспроизведение плейлистов пользователей.

Важное условие — все изменения необходимо было реализовать на «1С-Битрикс». Это связано со следующими факторами:

• На сайте накопилось много контента.
• Заказчик привык к интерфейсу админки «1С-Битрикс».

Однако в процессе изучения требований заказчика стало понятно, что реализовать изменения на сайте, разработанном на «1С-Битрикс», проблематично. Трудности оказались связаны с технологией работы классических монолитных сайтов.

Как работают монолитные сайты

Пользователь при клике по ссылке отправляет через браузер запрос на сервер. На сервере запрос обрабатывается, формируется HTML-страница и возвращается ответом пользователю. После каждого запроса происходит перезагрузка страницы.

Нас данный механизм не устраивал. Было важно, чтобы пользователь при серфинге по сайту мог непрерывно слушать различные треки без перезагрузок страницы.

Поэтому мы поняли, что нам нужно двигаться в сторону SPA (Single Page Application).

SPA – это веб-приложение, которое использует единственный HTML-документ в качестве оболочки для всех веб-страниц. Благодаря этому взаимодействие с пользователем организуется через динамически подгружаемые HTML, CSS, JavaScript, как правило, посредством AJAX.

Для создания такого веб-приложения мы решили бэк оставить на Битриксе, просто создав удобное REST API на его базе, а фронт же писать на React или Vue.

React или Vue

React — библиотека JavaScript. Это профессиональный продукт, который постоянно развивается. Vue — JavaScript-фреймворк с открытым исходным кодом для создания пользовательских интерфейсов, разрабатывался любительским сообществом. Но React популярнее и имеет более интересные перспективы.

Мы решили остановиться на React. Тем более всегда полезно получить опыт, который наверняка пригодится в дальнейшей работе.

Плюсы технологии React

1. Высокая скорость работы высоконагруженных систем. Благодаря технологии Single Page Application вместо перезагрузки всей страницы контент меняется точечно. Сервер возвращает пользователю легкий JSON вместо тяжеловесного HTML. Благодаря этому возможна непрерывная работа плеера.
2. Разделены роли фронтенд- и бэкенд-разработчиков. Клиентские и серверные приложения взаимодействуют посредством технологии Rest API.
3. Модульность React, которая позволяет просто, быстро и дешево обслуживать сайт.
   Но мы выделили один огромный минус сайтов с технологией Single Page Application — они не подходят для SEO-оптимизации. Для пользователя с сервера подгружаются данные в формате JSON, в браузере формируется сама страница, и когда поисковик заходит на такую страницу, он видит не HTML, а Java-скрипт.

Надстройка Next.js над React для SEO

Чтобы решить эту задачу, мы использовали надстройку Next.js над React для SEO. При этом используется серверный рендеринг. Когда пользователь заходит на сайт в первый раз, страница формируется на сервере и возвращается. Но потом страницы формируются в браузере. А так как поисковики получают информацию с сервера, SEO в этом случае отлично работает.

Результат работы

Мы еще работаем над новой версией сервиса, но некоторыми результатами готовы поделиться уже сейчас, в том числе фрагментами кода.

1. Главная страница

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

2. Редактирование своих плейлистов в личном кабинете.

В личном кабинете, помимо подписки на готовые плейлисты, можно создавать и свои собственные. На скриншоте ниже показано, как можно менять порядок отображения плейлистов простым перетаскиванием прямо в браузере.

3. Поп-ап с настройками плеера.

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

Для работы на React необходима более высокая квалификация разработчика. Это не просто верстка, а работа в отдельном приложении. Проект пишет фронтенд-разработчик, а не верстальщик.

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

Кроме того, коммерческие накрутки поставляющих компаний, отсутствие поддержки и обновлений делают стоимость железа, если не катастрофическим, то очень критичным фактором для бизнеса.

Альтернатив не много, либо российские производители, с поставками у которых, говоря мягко, не всё гладко, либо облачные платформы, которые сегодня выглядят самым простым, быстрым и адекватным по стоимости вариантом для размещения цифровой бизнес-инфраструктуры, в частности, 1С.

Мы уже писали о миграции 1C в Яндекс.Облако. Ещё одним из наиболее подходящих вариантов для развертывания 1С мы видим в использовании Cloud.

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

Ресурсы

Cloud обладает хорошо оптимизированными вычислительными ресурсами, что подтверждается популярными в 1С комьюнити тестами Гилёва. В зависимости от конфигурации ландшафта 1С Cloud выдаёт до 40 баллов из 60 возможных.

Так у одного из наших клиентов при развертывании 1С в другом облаке получалось 19 баллов, при использовании Cloud для идентичной инфраструктуры мы получили 39 без какого-либо «тюнинга» с базовыми возможностями сервиса.

Ещё одним преимуществом Cloud является то, что они последний облачный провайдер в России, сохраняющий легальную возможность использования некоторых западных лицензий.

Практические цели и сравнение затрат

Самым критичным при использовании Cloud, равно как и других облачных сервисов для развертывания 1С, является скорость. Так, базовую бизнес-инфраструктуру в подобном облаке можно подготовить за несколько дней. Более сложную за 2-3 недели.

Это не идёт ни в какое сравнение с поставками и инсталляцией серверного оборудования по параллельному импорту, либо от российских вендоров.

Ресурсы в облаке можно менять несколько раз в день.

С физическим оборудованием обратная ситуация — нужно на несколько лет вперед просчитывать необходимость в той или иной вычислительной мощности, заранее представлять себе тот зоопарк устройств и ПО, который понадобится для ЦОДа. Иначе можно «попасть» на апгрейде, и в случае с большими предприятиями — это могут оказаться многомиллионные затраты. Также можно перестраховаться и купить излишне мощные сервера для тривиальных, лёгких задач. Облака исключают такие риски.

Несмотря на то, что работа с облаком не исключает планирование и прогнозирование, ошибки в них не столь критичны и могут легко исправляться. Фактически, можно запланировать ресурсные расходы на год вперёд, но ближе к концу года скорректировать объём закупаемых мощностей, заложить скорректированные параметры на следующий период. И, что главное, быстро, одной заявкой за несколько минут нарастить производительность.

Стоимость облачных решений, например Cloud для развертывания 1С, сопоставима, но, на первый взгляд выше, чем у физического оборудования при равных вычислительных характеристиках. Однако при сопоставлении совокупных затрат в реальных проектах облако получается дешевле.

Затраты на облака используют операционный, а не инвестиционный бюджет, с которым значительно проще работать, кроме того, облачные решения в качестве сервиса предоставляют высокую доступность, т.е. снижают риски отказов.

Для реализации отказоустойчивости и высокой доступности при использовании частного ЦОДа, нужно покупать второй идентичный сервер, чтобы объединить их в кластер. Это удваивает расходы на оборудование.

Облако со старта поставляется провайдером с высокой доступностью и, в случае отказа оборудования провайдера, данные в облаке бесшовно переносятся и остаются доступными. Аналогичная ситуация с резервным копированием.

Компания-пользователь платит за занимаемый объём один раз. В случае с частным сервером необходимо покупать систему хранения данных, что ещё больше увеличивает затраты. Кроме того, на итоговую стоимость владения собственным сервером влияют затраты на электроэнергию, аренду серверной, каналы связи, поддержку со стороны персонала.

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

В Cloud, например, гарантированный 100 мб канал стоит около 1500 рублей, при аренде стойки оплата за каналы связи будет в 10 раз выше, для частного ЦОДа ещё больше.

При бюджетировании затрат на сервер 20% закладывают на поддержку, даже при отсутствии саппорта вендора, в enterprise-решении она остается необходимой. Т.е. речь может идти или о российском сервере или о стороннем саппорте. В любом случае, меньше она стоить не будет.

В облачных сервисах сервис провайдера входит в базовую стоимость. Дополнительная поддержка может тарифицироваться отдельно, но её стоимость будет в любом случае меньше 20%.

Немного об RDS и Postgre или ложка дёгтя

Затраты на администраторов баз данных и в целом на администрирование 1С не отличаются на земле и в облаке. При этом в облаке доступны такие решения как PaaS (DBaS), т.е. возможность развернуть базы данных как сервис. В этом случае развертывание происходит в автоматическом режиме за 10 — 15 минут.

С физическим оборудованием установка и настройка баз занимает несколько часов. В Cloud — этот сервис называется как RDS (Relational Database Service), он поддерживает MySQL, MS SQL и, что главное, PostgreSQL, особенно востребованные сегодня в России по понятным причинам.

Но тут есть проблема, на данный момент 1С не работает в стандартном варианте с т.н. ванильным Postgre. Необходима установка дополнения, которое устраняет этот недостаток. А RDS для PostgreSQL от Cloud к работе 1C на текущий момент не готов. Т.е. при использовании этих баз данных установку в автоматическом режиме провести не выйдет.

В данный момент мы с коллегами работаем над этим вопросом. Как партнеры Cloud, мы заинтересованы в том, чтобы RDS был адаптирован для использования с 1C и PostgreSQL. В частности, занимаемся подготовкой эталонного образа, чтобы его можно было использовать для доработки сервиса.

Сроки развертывания

Нам часто задают вопросы о сроках, но это крайне индивидуально. Тут всё зависит от заказчика, его требований к системе, его виденья, в частности, от глубины технической документации проекта. Мы уже наработали несколько типовых архитектурных решений для предприятий различного масштаба.

Главные критерии — количество пользователей, объемы баз и количество систем, которые планирует установить заказчик, эти данные влияют на архитектуру решения. Она, в свою очередь, определяет времязатраты на развёртывание.

У нас были кейсы, где коллеги хотели перенести только ERP, как наиболее загруженную часть. Были ситуации, когда требовалось развернуть в облаке также продуктивный контур. Как правило, на физическом оборудовании оставляют тестовый контур, чтобы уязвимый старенький корпоративный сервер не работал с критическими данными и функциями. Были компании, которые настаивали на том, чтобы перенести в облако вообще всё.

В сухом остатке

Подводя итог написанного выше, можно говорить, что Cloud, как среда для развертывания продуктов 1С, превосходит физические сервера. Главными достоинствами подобного решения станут:

• меньшая совокупная стоимость владения;
• высокая скорость развертывания;
• оптимизированные вычислительные ресурсы;
• гибкое управление производительностью;
• возможность использования баз данных, как сервис.

Мы старались объективно подойти к вопросу, даже учитывая, что речь в посте идёт о продуктах и услугах наших партнеров, и продемонстрировать максимально ценные для потенциальных пользователей преимущества предложенного подхода. Надеюсь у нас получилось. Мы будем признательны за ваши комментарии и вопросы, т.к. описать всё, что касается этой интеграции в рамках одного поста достаточно тяжело.

Как читать эту статью

Речь пойдет о проектах на Битриксе уровня Enterprise. Некоторые рекомендации будут справедливы и для других PHP-фреймворков и стеков веб-разработки.

Но самое главное: все мы понимаем, что проект в первую очередь нужно реализовать. Уже на этом этапе разработчики продумывают, насколько быстро будет работать система и что ей в этом поможет. Но предусмотреть абсолютно всё невозможно. Эта статья поможет разобраться, как ускорить уже запущенный проект.

Каждый раздел этого текста — это архитектурный блок. Чтобы приложение летало, поработать можно со всеми сразу или с одним из них. Я выделил 5 блоков:

1. Сам Битрикс и всё, что написано на PHP/HTML/CSS/JS поверх.
2. Базы данных: из коробки в Битриксе это MySQL.
3. Кэш.
4. Интеграция с другими системами.
5. Файловая система.

Внутри каждого блока чек-лист с комментариями или просто список советов. Прочитаете — будете лучше понимать своего тимлида. А может, при случае и подскажете ему что-нибудь.

Как ускорить проект на уровне Битрикс и PHP/HTML/CSS/JS

1. PHP

а. Использовать готовые библиотеки

Все библиотеки под решение конкретных задач отлаживаются и версионируются разработчиками не за час и не за неделю. Это большой труд, и все решения прорабатываются годами. У них есть команда поддержки. Поэтому их нужно использовать — это повысит отказоустойчивость проекта.

Для работы с библиотеками и зависимостями используйте composer.

b. Профилировать код в серьезных проектах

Профилировщик собирает данные о том, с какой скоростью и какая функциональность на странице выполняется. Эти данные помогают разработчику и тимлиду на конкретной странице находить узкие места — те, что замедляют общее время загрузки.

c. Пропускать самописный код через статические анализаторы

Какой бы крутой ни была команда разработчиков, ошибки бывают у всех. Анализаторы страхуют всю команду от опечаток или мелких ошибок, которые бы серьезно сказывались на работе всего проекта.

2. HTML/CSS/JS

a. Верстку и фронтовую часть делать на сборщике

Если верстка изначально оптимизирована и сжата, изъяны искать будет проще. Скорее всего, они будут на стороне Backend-разработчиков. Полезная ссылка.

3. Тестирование

a. Не забывать о тестировании

Если проект реально большой, то без тестировщиков никуда. Важно, чтобы они внедряли смоки, регрессы и отлаживали процесс тестирования. Благодаря этому в прод уйдет меньше багов. И значит, у разработчиков будет больше времени, чтобы заниматься ускорением проекта и повышением отказоустойчивости.

4. Bitrix

a. Помнить про ресайз картинок

Представим сайт с инфоблоком «Новости». В одну из них загрузили картинку на 15 Мб. Без ресайза сеть будет подтягивать ее полностью, страница будет грузиться долго. Это скажется на индексации. Конечный пользователь получит очень долгий рендер.

b. Использовать d7 и ORM

Менеджерам сложно это проконтролировать, но знать полезно. Эти две технологии ускоряют проект примерно в 5 раз — моя личная статистика.

c. Переносить как можно больше с инфоблоков на HLB

Переносить на HighLoad-блоки нужно всё, что возможно. Особенно, если вам не нужен какой-то очень удобный контент-менеджмент из админки. А лучше вообще проектировать свои таблицы и решения. Особенно это касается автоматизированных интеграций.

d. Кэшировать одинаковые данные на одном хите

Объясню на примере. Допустим, на страницу выводятся баллы из системы лояльности. Выводятся они как в начале страницы, так и в конце. Чтобы не делать два запроса в процессе загрузки, можно сделать только первый. Дальше баллы нужно закэшировать на уровне PHP, а потом из кэша в оперативной памяти достать и отобразить в нижней части страницы. Так мы урезаем запрос и уменьшаем время рендера страницы.

e. Архивировать устаревшие данные

Если у вас хранятся данные 2015 года, а вы живете в 2022, то возможно, эти данные устарели. Желательно унести их куда-то в другое место и доставать только при необходимости.

f. Учитывать агенты и их ограничение по времени

Агенты — фоновые задачи. У них есть ограничение по времени — 10 минут. Поэтому, если тимлид говорит: «Мы будем вот эту выгрузку выполнять на агенте, которая содержит миллионы строк данных», — это плохая идея. Как сделать, чтобы выгрузка постоянно не падала, расскажу дальше.

Как ускорить на уровне баз данных

1. Разносить базы данных и приложение на разные «машины»

В идеальном мире работа Битрикс и PHP не связана с ресурсами, которые используют базы данных. Так вы распределите нагрузку на эти части системы.

2. Использовать в базах индексы

Индексы — это данные из таблиц, отсортированные по конкретным столбцам, по которым построен индекс. Благодаря им в базе работает бинарный поиск. Проще говоря, поиск идет не по каждой строчке. Вместо этого система делит таблицу на две равные части. Смотрит влево, смотрит вправо. Если влево не найдено — то вправо. Правая часть тоже делится пополам и т. д.

Если данные в таблице обновляются/создаются/удаляются намного чаще, чем выполняется их чтение, то использовать индексы не стоит. Этот вариант подходит в случае, если на сайте есть новости с фильтрацией. Фильтрация с помощью индексов будет работать быстрее.

3. Использовать репликации

Репликация — это механизм создания копий базы данных, которые синхронизируются с оригиналом. Копии бывают двух типов: Master и Slave. Если копия Master, то мы в ней можем и писать, и читать. А если Slave — только читать. Изменения с Master тиражируются на все копии. Реализуется этот механизм на стороне СУБД, ничего программировать не надо.

Полезно применять в случаях, когда у вас на стороне заказчика есть аналитики или системы, которые хотят читать данные в вашей базе. Вы можете сделать отдельную Slave-реплику только для аналитиков. Они будут делать сложные запросы, которые могут уронить всю базу. Но упадет она только для них.

4. Использовать партиции

Партиции помогут, если у вас одна большая таблица на проекте. Партиция — это принцип деления таблицы на основании какого-то фильтра. Например, по дате. Когда таблица очень большая, это поможет разделить нагрузку и повысить отказоустойчивость. Этот механизм тоже реализуется на стороне СУБД.

5. Применять шардирование

В этом случае нужна работа программиста. Шардирование — это вариант распределения нагрузки. Он похож на партиции: тоже деление таблиц по какой-то логике.

Например, можно шардировать фотографии пользователей. Все фотографии нечетных пользователей уходят в одну шарду, четных — в другую.

Как ускорить проект на уровне кэша

Кэш нужен, чтобы снять нагрузку с баз данных. В Битриксе «из коробки» разные типы кэша. Я перечислю плюсы и минусы самых популярных. Но отдельно подчеркну: все эти решения разгружают базу данных. Это их основная функция.

1. Файловый кэш

Плюсы

• Объем не ограничен: если ваш жесткий диск на терабайт, он будет наполняться кэшем, пока вы полностью его не забьете.
• Персистентный: если у вас падает какая-то «машина», закэшированные данные не теряются — как лежали на диске, так и продолжают лежать.

Минусы

• Самый медленный из всех типов.
• Генерирует нагрузку на ту же файловую систему, потому что лежит на жестком диске.

2. Memcached

Плюсы

• Очень быстрый.

Минусы

• Не персистентный: работает в оперативной памяти — если «машина» упала, то кэш потерян.
• Ограничен объемом выделенной под него оперативной памяти.

3. Redis

Плюсы

• Быстрый.
• Может быть персистентным: его можно сконфигурировать как персистеным, так и не персистентным. Но если персистентный, то работает медленнее.

Минусы

• Небольшой объем.

Еще один способ — прогрев кэша

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

Ручной: после сброса кэша запускаете тестировщика, и он меняет города; можно менять только основные, потому что с них будет больше всего потока и нагрузки.

Автоматизированный: это можно повесить на CI/CD и просто написать какие-то функциональные тесты, которые будут после деплоя ходить и медленно переключать города и собирать кэш.

Как ускорить на уровне интеграций с другими системами

В первую очередь я говорю о интеграциях типа «точка — точка»: REST, SOAP. Они работают просто и понятно: одна система отправила запрос, ждет. Вторая система приняла запрос, обработала, отдала ответ. Отправляющая система ждать перестала, обработала ответ, пошла дальше.

Более важная тема — брокеры сообщений и менеджеры очередей. Их мы можем применить вместо REST и SOAP. Примеры брокеров сообщений — Kafka, RabbitMQ. Вот чего они позволяют добиться:

1. Асинхронность

Система отправляет запрос в брокер и дальше занимается своими делами — ответ она заберет в фоновом режиме. Система не забивает память этим запросом: на ее стороне есть обработчик, он же консьюмер, который читает и обрабатывает ответы по одному.

2. Гарантия доставки

В случае с REST, когда ваша система отправляет запрос, а вторая система лежит, пользователь получает 500 ошибку. В случае с брокерами вы всегда дождетесь ответа от другой системы. Кроме тех случаев, когда ваш брокер лежит. Но это критическая проблема — сейчас речь не об этом.

3. Уменьшение нагрузки на отправляющей и на принимающей стороне

Когда у вас «точка — точка», системе тяжелее. Например, 5 млн пользователей одновременно зашли на сайт и вызвали одно и то же интеграционное действие. Ваша система ждет 5 млн ответов. Другая система обрабатывает 5 млн запросов. Брокер же принимает запросы и отдает ответы быстро. Он записывает запрос, отдает в другую систему. Там консьюмер читает и обрабатывает по одному сообщению в фоне. Всё это не занимая ресурсов на 5 млн запросов.

4. Ускорение постоянных и многочисленных однотипных фоновых действий

Если у вас на проекте много логирования, количество посетителей и файлов записей растет, всё это можно перевести на брокер. Система такая: ваш лог сначала пишется в брокер, а дальше в вашей же системе имеется консюмер, который читает из брокера и записывает в хранилище с логами, но не генерирует такого количества нагрузки.

5. Решение продолжительных фоновых задач

Например, если на проекте генерируется больше событий, чем агент успевает обработать за 1 раз, агент падает. В лучшем случае просто не успевает обрабатывать очередь поступающих заявок. С брокерами проще: заявки передаются им, а потом обрабатываются в другом месте без ограничения по времени.

Как ускорить на уровне файловой системы

Файловая система работает как база знаний: в ней есть операции чтения и записи. За этим показателем важно следить и уменьшать его на каждой конкретной «машине». Вот два параметра, на которые стоит обращать внимание:

1. Статика минимизирована и оптимизирована

Статический контент — то, что запрашивается при каждом запросе, если он не был закэширован в браузере. К такому контенту относится CSS, JS, дефолтные картинки типа логотипов компаний. В идеале они должны быть минимизированы, оптимизированы и куда-нибудь убраны — например, в CDN.

2. Динамический контент и медиа в S3-хранилище

S3-хранилище — это облачное хранилище, которое гарантирует, что ваши данные будут отдаваться, храниться, не пропадать и т. д. С помощью него вы разгрузите файловую систему: файлы при рендере страницы в браузере будут подтягиваться из хранилища, а не с вашего сервера.

Эти рекомендации сделают вашу систему более быстрой и отказоустойчивой. Разработчики применяют их в работе — но знать о них полезно всей команде. В следующий раз, когда покажется, что ваш проект на Битриксе работает медленно, спросите у тимлида, все ли способы ускорения он использовал.

Если есть вопросы, задавайте в комментариях. Я по-прежнему на связи!

Юля Килина и Лада Евтюкова, эксперты департамента бизнес-приложений КРОК, смогли решить задачу с помощью инструментов блока бюджетирования «коробочной» версии 1С. И провели по этой теме митап, где рассказали, как быстро формировать нужные документы и эффективно организовать учёт по краткосрочным бизнес-проектам, используя базовые инструменты 1С ERP УХ.

Делимся записью митапа и важной информацией из него: что важно учитывать в работе, как формировать отчёты, как использовать инструменты 1C ERP УХ. А также кратко описываем, как настроили свою систему.

Что учитывать при организации проектного учёта

Бэкграунд компании

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

Кроме того, перед началом работы стоит решить методологические задачи и зафиксировать их в учётной политике. Обычно они касаются:

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

Чем точнее будут описаны методики, тем лучше будет оценка рентабельности и финансовой эффективности проекта.

Отчёты

Кроме стандартных отчётов: по доходам и расходам, по движению денежных встреч, финансовые результаты, управленческий баланс — стоит формировать дополнительные.

Среди них отчёт по маржинальной стоимости в разрезе проектов, отчёт о рентабельности по проектам, распределение денежных средств по проектам, план-факт БДР и план-факт БДДС.

Чтобы сделать дополнительные отчёты, сперва нужно сформировать требования. Они должны исходить от потребителя: собственника, акционера, инвестора, менеджера или исполнителя. Форма и аналитика также могут меняться в зависимости от пользователя.

Формировать отчеты нужно в два этапа.

Сперва задаём структуру строк и колонок, уровни детализации статей доходов и расходов. И определяем состав проекта: что приносит доход, а что требует расходов. Получаем отчётность, удобную для использования, — таблицу данных, опираясь на которую сможем принимать решения по проекту.

Дальше создаём методологию.

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

Итогом всех наших усилий становится распределение всех доходов и расходов и создание дополнительных отчётов.

Как мы управляем скоупом проекта с помощью 1С ERP УХ

1. Определяем функциональные блоки системы: регламентированный учёт, блок закупок, блок продаж, склад, доставка, расчёты с персоналом и так далее.
2. Выделяем характерные для каждого блока бизнес-процессы. Среди них авансовые отчёты, расчёты по заработной плате, заключение договора с поставщиком, приобретение товаров, инвентаризация.
3. В процессе моделирования собираем требования к шагам и ранжируем их по типам: стандартная функциональность, настройка, кастомизация.
4. Далее мы определяем, где нужна кастомизация, объединяем доработки в блоки, оцениваем и переходим к проектированию.
5. Когда система разработана, проводим локальное, функциональное и интеграционное тестирование.
6. Пишем инструкцию для пользователей.

Для всей работы у нас есть инструмент — интегрированный стенд разработки, который помогает снизить нагрузку и отслеживать все процессы. Как он работает:

• Сначала мы в системе прикладных решений регистрируем все бизнес-процессы и функциональные блоки. Далее описываем процесс по шагам, привязываем требования, которые система ранжирует.
• Затем формируется функциональный дизайн расширения, и разработчику поступает документ с прописанными объектами метаданных. Это позволяет ему исключить ошибки. Дальше разработчик делает проект, который мы тестируем, превращаем бизнес-процесс и передаём заказчику.
• Наконец, бизнес-процесс превращается в инструкцию. Мы дополняем её скриншотами — и всё готово.

В 1С все данные о списках баз хранятся в обычных текстовых, читаемых файлах с расширениями .cfg и .v8i, в кодировке utf-8. Как правило, у пользователей на компьютере 1С 8 хранит файлы списков баз в каталогах Профиль всех пользователей: C:\ProgramData\1C\1CEStart\ и Профиль пользователя: С:\Documents and Settings\%username%\Application Data\1C\1CEstart\ (или C:\Users\%username%\AppData\Roaming\1C\1CEStart\).

Содержимое профиля пользователя — два файла: 1CEStart.cfg и ibases.v8i. Содержимое директории профиля всех пользователей — только один 1CEStart.cfg.

При запуске 1С берёт список баз к представлению в файле пользователя, но предварительно читает настройки сначала из профиля всех пользователей C:\ProgramData\1C\1CEStart\1CEStart.cfg, а потом и из профиля пользователя C:\Users\%username%\AppData\Roaming\1C\1CEStart\1CEStart.cfg, и если в них есть ссылки на конфигурационные базы в сети, то добавляет их в этот файл.

Например, нам нужно, чтобы на терминальном сервере Windows Server 2012 R2 Standard обеспечивалась работа около 100 пользователей.

Создаём список баз:

Копируем созданный список баз в общую, доступную для всех пользователей, директорию – тот самый список баз в директории %AppData%\1C\1CEStart с именем ibases.V8I

Третьим шагом будет добавление в файл “C:\ProgramData\1C\1CEStart\1CEStart.cfg” пути к общему списку баз: CommonInfoBases=E:\BaseList\ibases.v8i

Готово. Теперь при входе в систему у пользователя будет одинаковый список баз. Не нужно объяснять пользователю, как добавить базу, уточнять параметры и ставить галочки — всё уже есть.

Если требуется массово изменить имя базы или имя сервера, или другой параметр базы, это делается в одном файле ibases.V8I один раз. В случае, когда принципиально нужно поставить на рабочий стол список баз, это можно сделать следующим образом:

• Открыть командную строку от имени администратора, запустить редактор локальной групповой политики: gpedit.
• В дереве выбрать «Конфигурация пользователя –> Конфигурация Windows –> Административные шаблоны –> Система –> Вход в систему –> Выполнять эти программы при входе в систему».
• Указать команду или путь к bat-файлу:

@echo off

mkdir %UserProfile%\Desktop

copy E:\BaseList\ibases.V8I %UserProfile%\Desktop\ibases.V8I

• И далее обновить политику: gpupdate /force.

Если нужно, чтобы список баз отображался в виде дерева (иерархией), действия следующие:

• Настраиваем список на отображение в виде дерева.
• Копируем файл %UserProfile%\AppData\Roaming\1C\1cv8\1cv8strt.pfl в общую директорию, например, туда же: E:\BaseList\1cv8strt.pfl.
• Открываем командную строку от имени администратора, запускаем редактор локальной групповой политики: gpedit.
• В дереве выбрать «Конфигурация пользователя –> Конфигурация Windows –> Административные шаблоны –> Система –> Вход в систему –> Выполнять эти программы при входе в систему».
• Указать команду или путь к bat-файлу:

@echo off

mkdir %UserProfile%\AppData\Roaming\1C\1cv8

copy E:\BaseList\1cv8strt.pfl %UserProfile%\AppData\Roaming\1C\1cv8\1cv8strt.pfl

Если же требуется лишь заменить строчку с настройкой дерева в указанном файле, то указать путь к bat-файлу:

@echo off

setlocal enabledelayedexpansion

Set infile=%UserProfile%\AppData\Roaming\1C\1cv8\1cv8strt.pfl

Set find={"B",0},"AutoSortIBs",

Set replace={"B",1},"AutoSortIBs",

@echo off

setlocal enabledelayedexpansion

set COUNT=0

for /F "tokens=* delims=," %%n in (!infile!) do (

set LINE=%%n

set TMPR=!LINE:%find%=%replace%!

Echo !TMPR!>>TMP.TXT

)

del %infile%

move TMP.TXT %infile%

Примечание: если сервер находится в домене, то локальная политика не сработает, нужно прописывать доменную политику.

Сегодня в России и странах СНГ почти не существует бизнеса, который бы не использовал хотя бы одной программы 1С. Да, на этом языке вы не напишете 3D-игру класса ААА или новую социальную сеть, но 1С-программистам всего этого и не нужно, потому что их главная цель — помогать предприятиям зарабатывать деньги с помощью автоматизации процессов. А благодаря своему расположению «возле бизнеса» из специалистов по 1С получаются не только прекрасные программисты, но и высококлассные аналитики, и руководители команд разработки.

О том, почему 1С — перспективный язык программирования и отличный выбор для начинающих подробно рассказывает Андрей Овсянкин, системный архитектор «Сберлогистики» и преподаватель курса «1С-программист» в Нетологии.

Кому, а главное зачем нужны 1С-программисты?

Специалисты по 1С нужны всем у кого есть бизнес, то есть буквально всем на рынке. Разработчики графики нужны производителям игр, создатели алгоритмов сжатия видео — стриминговым платформам, низкоуровневые программисты — компаниям, создающим «железо». Но и тем, и другим, и третьим нужны 1С-ники, потому что все это — бизнесы, которым необходимо считать деньги, платить зарплаты, автоматизировать производство и так далее.

Если представить себе бизнес, который продает улучшение качества фотографий онлайн, то сама его платформа, наверняка, будет построена на одном из низкоуровневых языков программирования, но всё, что вокруг: обслуживание клиента, оплата, выставление счета, расчёт и выплата зарплат сотрудникам — могут быть полностью реализованы на базе 1С.

Язык программирования 1С — это так называемый «предметно-ориентированный язык», заточенный под конкретные задачи. С самого начала он был придуман для работы с определённой платформой, а именно «1С: Предприятие». На базе этой платформы создаются решения для автоматизации бизнес-процессов: учёта товаров, расчёта заработной платы, налогов и других операций. И все они пишутся на едином коде, который, за неимением оригинального названия от разработчиков, стали обозначать как «язык программирования 1С».

Сегодня системы вроде «1С: Предприятия» часто называют модным словом low-code, оно обозначает среду программирования с низкой потребностью писать код самостоятельно и в большом количестве. Главная функция таких платформ сводится к тому, чтобы быстро создавать работоспособные приложения для решения бизнес-целей с помощью множества готовых решений и инструментов из «коробки». Ключевое слово здесь — быстро. Чем быстрее бизнес выйдет со своей идеей на рынок, тем лучше. Чем дольше бизнес будет ждать, пока программисты все напишут, тем выше шанс, что его опередят.

Почему 1С — отличный старт для новичков?

Во-первых, у 1С низкий порог вхождения. Он очень простой. Во-вторых, он позволяет быстро получать конечный результат. За счет концепции low-code и огромного количества готовых компонентов даже новичок начинает приносить работодателю выгоду практически сразу после трудоустройства. Джуниор в 1С полезен бизнесу гораздо больше, чем джуниор, скажем, в Java, за которым старшие коллеги первое время вынуждены постоянно присматривать, чтобы не натворил бед.

В экосистеме «1С: Предприятие» есть все для разработки простых алгоритмов: готовые экранные формы, библиотеки данных, стандартные отчеты и понятный язык программирования. Специалисту не нужно писать масштабные модули стандартных операций. Все составные части, которые требуются, уже готовы — остается только собрать механизм.

Специалист по 1С очень быстро окупается и имеет широкое пространство карьерного маневра. Можно писать код, а можно анализировать бизнес и предлагать решения проблем, то есть расти в сторону бизнес-архитектора и бизнес-аналитика. Переключение между этими ипостасями для «1С-ника» происходит гладко, так как он по умолчанию владеет обеими предметными областями.

Еще одна особенность 1С заключается в том, что он поддерживает два языка программирования — английский и русский. И, как правило, если мы говорим о российском рынке, то «1С-ники» пишут именно на русском. Так вот, писать логику на языке, на котором ты думаешь, гораздо удобнее, особенно, если до этого ты не занимался программированием вообще. Потому что то, что думаешь, то и пишешь в код. Именно поэтому «порог вхождения» в программирование легче переступить, начиная с 1С. Тебе не придётся заниматься лишними задачами и корпеть над переводом.

Многие программисты, специализирующиеся на других языках, хихикают и говорят: «Ха, смотрите! Они пишут “если”, а мы пишем “if”». Ну так их иностранные коллеги пишут как раз «если», поскольку именно это слово и думают. А наши вынуждены мучиться с трудностями перевода. Я всегда смеюсь, когда вижу в коде на C# или Java переменные SchetOplachen и Sklad. Бедные авторы, бедные те, кто это сопровождает потом.

Всем нужны «решатели» проблем: задачи 1С-программиста

Главная задача любого программиста (не только «1С-ника») — приносить компании пользу, именно за это специалист получает деньги. Для бизнеса программист — хоть и ценный, но всё же, ненужный посредник между прибыльной идеей и её реализацией. Именно поэтому, бизнесу вообще не важно, на каком языке ты программируешь. А важно другое — как скоро и насколько качественно ты сможешь решить проблему автоматизации того или иного процесса. Вот почему системы low-code так востребованы, они решают проблемы с минимальным участием программистов и меньшими финансовыми и временными затратами.

Работа 1С-программиста построена просто: сначала он анализирует входящие требования клиента и определяет что нужно сделать и какой у задачи смысл. Например, ему нужно настроить для интернет-магазина систему выгрузки данных о том, какие товары остались на сайте и загрузки информации о заказах (цене, количестве, номенклатуре).

Сначала 1С-программист воплощает идею в виде модели данных (решает, какие объекты будут создаваться — заказы, пользователи, товары, счета и тому подобное), а затем пишет алгоритм, как именно эти объекты будут взаимодействовать между собой, создает экранные формы и отчетность под решение конкретной задачи. То есть, один человек решает проблему целиком. Вот и получается, что 1С-ник — это «решатель проблем» и «достигатель бизнес-цели», а не только «программист». И это гораздо ценнее.

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

Только представьте, задача «сделать кнопку “Заказать” недоступной, если не внесена предоплата» у 1С-ника занимает 2 минуты. На другом стеке двум командам разработки: фронтенда и бэкенда нужно будет договориться о том, как две части программы будут взаимодействовать и в каком формате одна команда передаст данные другой. Это занимает примерно неделю обсуждений, разработки и тестирования, и эту неделю бизнес будет ждать своего готового решения.

Какие навыки и знания нужны программисту 1С?

Как и любому другому разработчику, «1С-нику» важно обладать аналитическим складом ума, чтобы понимать, в чём заключается задача, из каких компонентов она состоит и как «шестерёнки» должны закрутиться, чтобы всё заработало. Не менее важны коммуникативные навыки и умение находить общий язык с клиентом. Часто бывает, что заказчик приходит с какой-то идеей, но сам не может чётко выразить, чего хочет на самом деле. Чтобы понять его цели и эффективно сделать свою работу, программисту просто необходимо уметь общаться.

На каком языке ни пиши, всегда приходится упираться в особенности работы «железа» и настройки операционной системы, поэтому потребуются и «общеайтишные» знания: как работают диски, процессор, память или, например, как функционируют базы данных и почему в одном случае они выполняют запрос медленно, а в другом — быстро.

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

Если говорить о «хардовых» навыках, то постепенно программисту придется изучить блоки и компоненты самой 1С, систему зарплатных регистров, периодические расчёты. Не менее важно уметь создавать разные виды справочников и документов, работать с запросами, а также применять языки разметки XML и JSON, сервисы HTTP и SOAP. Опытные 1С-программисты должны понимать не только, как адаптировать и дорабатывать готовые решения, но и как с нуля создавать конфигурации и веб-сервисы под нужды бизнеса, поскольку запросы каждого предприятия уникальны.

Из «непрограммистских» навыков полезными, но не обязательными являются знания учёта и основ бизнеса: как и чем компании вообще живут. Например, в Нетологии студентам преподают ещё и основы бухгалтерского учета.

Будет ли легче учить другие языки программирования со знанием 1С?

Сегодня отраслей и предметных областей, которые так или иначе затрагивает IT — очень много, поэтому знание нескольких языков для программиста это норма. Даже, если ты пишешь на JavaScript, тебе на компьютер ставится Python и C++, потому что node.js их себе требует. Знание нескольких технологий и широкий кругозор сегодня почти обязательны.

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

Если у человека есть желание кодить и осваивать новые языки, то, с одной стороны, после 1С ему будет легче — не придётся заново запоминать, что такое переменная, условие и цикл, потому что это общие концепции, которые есть и в других языках. С другой стороны, будут и сложности: придётся переключаться на кодинг на английском языке, а также привыкать, что под рукой нет решений из «коробки» и все низкоуровневые вещи, вроде миграции полей в базе данных и рисования интерфейса, нужно писать самому.

В целом, будет нетрудно переключиться на Java Script, потому что это стандартная разработка для веба, или освоить Python — язык, который в принципе создавался для того, чтобы быть простым. Поэтому, ответ — да. Если никогда не программировал, то после изучения 1С будет легче изучить что-то ещё.

Где учиться на 1С-программиста?

Знания, достаточные для погружения в профессию, дают очные и интернет-курсы. Многие из них рассчитаны именно на новичков, поскольку опытные специалисты нарабатывают навыки на реальных кейсах.

В Нетологии на первом этапе обучения реализован метод «программирования без кода». Сначала студенты учатся создавать решения нажатием кнопок мыши вообще без кода. И они, даже не написав ни строчки кода, видят результат своей работы — готовое работающее приложение. Можно ввести необходимые данные (клиент, заказ, склад) и посмотреть на результат. Это даёт первичное понимание процесса работы «1С-ника».

После освоения базовых навыков, наступает этап детального изучения самой программы. Здесь студенты не только оттачивают мастерство работы с блоками и компонентами 1С, но, главным образом, учатся понимать, как автоматизировать бизнес-процессы так, чтобы это помогало предприятиям развиваться и приносить прибыль. Если погружение в обучение было последовательным и тщательным, выпускники курсов без труда устраиваются на работу уже в новом качестве — 1С-программистов.

Природа проблемы

Сообщение «Недостаточно памяти» — одна из самых часто встречающихся ошибок при работе с 1С: Предприятие версии 8.3 и выше. Она происходит по самым разным причинам — от обработки системой нескольких массивных файлов и загрузки больших объёмов данных, до обновления ПО и перегрузки ресурсов при формирования сложных отчётов.

Она не так критична при возникновении на клиентском компьютере, а вот если сообщение об ошибке выдает сервер 1С, нужно отнестись к этому максимально внимательно. Это тот самый случай, когда очень важно установить правильный «диагноз» — то есть решения не будет, пока ответственный администратор не распознает источник проблемы, не поймёт её природу.

Проблема может заключаться в несвоевременном завершении процессов, запускаемых различным ПО. Они накапливаются и перегружают доступный объём памяти на сервере. Также может иметь место интенсивная работа различных программ с постоянным резервированием и освобождением ресурсов памяти.

Приведу пример расследования одной подобной ошибки из своей практики.

Инцидент

Поступило обращение со следующей ошибкой:

Смотрим журнал регистрации, там так же выводится ошибка с пояснением о нехватке памяти на сервере:

Настроив технологический журнал (ТЖ) системы 1С с событием EXCP — EXCPCNTX обнаруживаем запись:

Ошибка СУБД out of memory for query result

То есть, обе ошибки сообщают о проблеме объёма памяти, на основании чего нашим главным подозреваемым становится код конфигурации (возможно наличие неоптимальных запросов).

Находим код конфигурации, вызывающий ошибку.

В журнале регистрации указан следующий код:

Открываем конфигуратор и переходим в указанный модуль к указанному номеру строки кода:

Строка, на которой произошла ошибка:

Смотрим тип объекта (константы), к которой идёт обращение:

Итак, в конфигурации есть константа:

Она хранит в базе что-то неструктурированное (двоичные данные), что может занимать значительный объём памяти.

Проверяем, какой объем данных фактически занимает константа. Для этого узнаем имя таблицы хранения в базе PostgreSQL — таблица «_Const10013», индекс «_Const10013_ByKey».

Узнаем размер таблиц «Const10013», «_Const10013_ByKey» на диске:

На диске таблица занимает всего 4688 Кб = 4,6 Мб. Размер является незначительным, значит, причина не в константе.

Обнаруживаем, что кластер 1С является 32-разрядным:

32-разрядный кластер 1С имеет ограничение примерно в 3.8 Гб, при достижении которого происходит падение процесса. В режиме отсутствия нагрузки rphost занял 3,2 Гб, что близко к порогу падения. Подобные инциденты будут происходить в любой момент времени.

Внесены изменения:

• В кластере серверов 1С «Интервал превышения допустимого объёма памяти процессов» = 300. Настройка не избавляет от ошибки, но необходима для снижения частоты возникновения ошибки.
• В планировщике Windows настроен перезапуск службы 1С; такими образом освобождается виртуальное адресное пространство в памяти, создаётся новый рабочий процесс.

Настройка также не гарантирует от ошибки, но снижает вероятность её возникновения.

Для предотвращения повторной ошибки следует:

• Сменить 32-разрядный кластер серверов 1С на 64-разрядный.
• Так как на сервере используется 14 ядер процессора, необходимо осуществить переход на платформенные лицензии 1С КОРП для снятия ограничений по настройкам и обеспечения возможностей для гибкой настройки распределения памяти сервера.

Другие варианты

Зачастую, особенно в ситуации, когда нужно срочно вернуть систему в работоспособное состояние при возникновении подобной ошибки, можно попробовать такие «дедовские» способы, как перезагрузка сервера 1С или перезапуск рабочих процессов 1С, что приведёт к уменьшению объёма используемой памяти.

Источником проблемы также может быть недостаток пространства на жестком диске сервера. Здесь решение будет зависеть от устройство сервера или кластера, но здесь также могут помочь и перезапуск сервера, и наращивание ёмкости диска (или освобождение существующего пространства), а также оптимизация запросов или обновление версии ПО системы.

Распространено мнение, что платформа 1С Предприятие — это в основном про бухгалтерию и зарплату. Что 1С-ники — это такие продвинутые бухгалтеры, которые научились кодить. И в этой статье я хотел бы развеять часть мифов и показать, какое 1С на самом деле может занимать место в IT-ландшафте компании.

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

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

Какие же задачи стоят пред 1С разработчиком для Бухгалтерии?

Кейс 1. Интеграция с сервисом Smartway для автоматической загрузки командировочных документов. Убираем рутину и дублирование ввода данных разными пользователями.

Кейс 2. Бесшовная интеграция с документооборотом. Возможность настроить сквозные бизнес-процессы согласования, подписания, использование ЭЦП, автоматическое прикрепление печатных форм.

Следующий классический случай — 1С Зарплата и управление персоналом

Что же здесь может быть интересного для разработчика 1С, если у него душа не лежит к планам расчётов и разбору ошибок учёта?

Кейс 3. Интеграция с рекрутинговыми сервисами, например Huntflow. Загрузка резюме, работа с подбором персонала, анкетами, кандидатами, вакансиями в тесной связке с 1С.

Кейс 4. Интеграция с СКУД. Активация карточек доступа, контроль учёта рабочего времени, дашборды и аналитика трудовой дисциплины (грубо говоря, как часто сотрудник выходит покурить.

Кейс 5. Интеграция с ActiveDirectory. Создание, блокирование, обновление данных учетных записей. Упрощаем работу системным администраторам и отделу информационной безопасности.

Кейс 6.  Переход на кадровый электронный документооборот. Тут пространство для маневра очень велико — можно интегрироваться со сторонними сервисами (Сбер Корус, СБИС, HRLink) или же использовать свою инфраструктуру на базе сертификатов Microsoft и 1С Документооборота. Помним про бесшовную интеграцию.

Кейс 7. Процессинг, интеграция с банковскими шинами данных, зарплатные проекты и всё с ними связанное.

Кейс 8. Внедрение системы рассылок уведомлений. Уведомления на почту о начале отпуска, работе в выходной, расчётные листки, приемы на работу и увольнения, памятки новым сотрудникам и так далее. Меньше рутины для кадровиков — больше информированности у всех задействованных лиц.

А вот и он — 1С Документооборот! И на его примере у меня есть очень много кейсов интеграции с различными системами

Кейс 9. Интеграция с MS Exchange. Синхронизация мероприятий, создание мероприятий в Outlook прямо из 1С, обновление списков участников, времени и места проведения, и так далее.

Кейс 10. Интеграция с системой обработки заявок OTRS. Создание, отслеживание, обновление заявок непосредственно из 1С, с привязкой к объектам базы данных — документам, проектам, различным справочникам.

Кейс 11. Интеграция с корпоративным порталом. Отображение на портале статуса сотрудника (в отпуске, в командировке, работает дистанционно, отсутствует), отображение дней рождений, и многое другое

Кейс 12. Встраивание веб-клиента в сайт и интеграция с онлайн-чатом/ассистентом.

Кейс 13. Не устали? Да, 1С — это не только бухгалтерия.  Итак, интеграция с MS Project Server. Разработка API для формирования бюджетов, планирования занятости ресурсов на разных проектах, синхронизация сведений в карточке ресурсов с 1С.

Кейс 14. Интеграция с MS Dinamics CRM. Синхронизация финансовых показателей проектов, подходящих под определенные условия. Для синхронизации использовалось консольное приложение от субподрядчика.

Ну и в завершение немного экзотики

Кейс 15. Реализация экспертной медицинской системы по расшифровке результатов анализов. Система в виде веб-кабинета позволяет сотруднику загрузить PDF-файл с анализом, а далее на основе процентных соотношений различных показателей выдаёт рекомендации и интерпретацию этих анализов. Из интересных технологий, которые были задействованы — отображение PDF в 1С в виде html документа с пагинацией, для сравнения исходного файла и распознанных показателей.

Кейс 16. Автоматизация учёта финансовых инструментов. Акции, облигации, сделки РЕПО, котировки, купонный доход, вот это вот всё. Загрузка отчетов брокера в 1С из Excel файлов произвольных форматов, загрузка котировок и данных по финансовым инструментам с биржи ММВБ, формирование аналитики по сделкам.

Теперь об использованных технологиях. Чаще всего на помощь приходят  классические веб-сервисы, http-сервисы, работа с json, xml, xdto. Также часто используются средства работы с табличными документами — как при помощи com-объектов, так и средствами объектов 1С «ТабличныйДокумент».

Не обойтись зачастую и без смежных знаний — навыки веб-разработки вполне можно применять совместно с 1С. Приходится сталкиваться и со скриптами, консольными приложениями, да много с чем. Смежные навыки позволяют решать многие задачи не в лоб средствами 1С, а выбирать наиболее подходящие инструменты.

На закуску

Кейс 17. Использование 1С в качестве бэкэнда для server-side rendering.

Пришла мне в голову идея упростить жизнь себе и коллегам, собрав все данные по использующимся http-сервисам в виде сайта-справки. Сказано — сделано! Вся информация хранится в отдельном расширении. Http-сервис собирает данные из справочника с описанием сервиса, формирует готовый html-документ и возвращает браузеру.

И ещё один вариант использования 1С для бэкэнда. Выше я писал про интеграцию 1С и системы обработки заявок OTRS. У рядовых пользователей, которые эти самые заявки создают, доступа к системе нет, и всё можно отслеживать только в почте по номеру тикета. Чтобы немного упростить навигацию по заявкам, я сделал небольшой веб-сайт, который получает из 1С JSON, в котором содержатся данные о заявках текущего пользователя в OTRS.

Используя доменную авторизацию, можно отфильтровать только заявки, к которым пользователь имеет доступ, и вернуть их в формате JSON. А дальше просто в более-менее красивом виде, используя bootstrap4 и fathgrid, выводим пользователю его заявки с возможностью просмотра деталей.

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

Начнём с того, что rphost представляет собой ключевое звено всей архитектуры 1С, забирая на себя большую аппаратную нагрузку. Процессов rphost может быть много по разным машинам внутри корпоративной системы 1C. При этом rphost.exe часто «съедает память» и перегружает процессор. К примеру, это может выглядеть так:

Дано

• сервер 1С: Wndows Server 2016 Standard, 32 Гб ОЗУ, 12-ядерный процессор 2.7 ГГц;
• платформа 1С — 8.3.15.1565 с настройками по умолчанию;
• 60 баз, лицензия платформы ПРОФ.

Проблема

Процессор загружен постоянно на 85-100% (и каждое ядро, и суммарно). Требуется выявить причину такой загрузки и разгрузить процессор.

Решение

Начинаем с самого простого и очевидного. Откроем диспетчер задач Windows, вкладку Details и отсортируем список процессов по колонке CPU.

Если видим один или несколько процессов rphost.exe в топе – значит, процессор загружен 1С. Если процессор загружен, значит какие-то задачи выполняются. А так как процессор загружен слишком часто, то задачи выполняются либо слишком долго, либо слишком быстро и часто.

Но что именно может суммарно выполняться настолько долго в 1С, что это становится проблемой? Находим топ суммарно длительных серверных вызовов. Для этого нам понадобится выполнить сбор технологического журнала (ТЖ). Это специальный механизм платформы 1С 8.3, который позволяет протоколировать все события, происходящие в системе, в том числе системные ошибки.

Настройка его сбора выглядит так:

Далее необходимо провести парсинг собранного для выявления возможных источников проблемы. В этом поможет следующий скрипт:

С помощью GitBash в директории ТЖ запускаем скрипт. Получаем следующий результат:

В топе оказались регламентные задания. Заходим в базы и проверяем периодичность каждого регламентного задания. Периодичность высокая.

Что поможет справиться с загрузкой процессора?

1. Если в работе системы 1С компании есть период нерабочего времени, переносим время запуска на него.

2. В случае, когда нерабочего времени нет (система всегда работает), уточняем, пользуются ли пользователи полнотекстовым поиском. Если нет — отключаем регламентные задания. Если да — уточняем допустимый предел актуальности данных (например, на вчерашний день, двухчасовая актуальность). И меняем периодичность запуска соответственно.

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

4. Наконец, самый сложный случай, когда полнотекстовый поиск требуется для всех полей, а данные меняются часто. Тогда для решения потребуется либо произвести увеличение количества ядер (и желательно их частоты), либо выполнить перенос сервиса полнотекстового поиска на отдельный сервер.

5. Также иногда проблему загрузки процессора решают довольно банальные шаги: перезагрузка сервера и обновление платформы. Работа с актуальными версиями платформы имеет смысл по многим причинам, одна из которых — постоянный поиск разработчиками путей по снижению системных требований для работы 1С.

Веяния времени

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

Однако сегодня всё меняется: цифровые бизнес-модели масштабируются с ростом объемов операций, меняются модели доступа к ИТ-системам компаний, требования к их производительности и так далее.

Отдельный веб-сервер, на котором публикуется база данных 1С, позволяет избавиться от необходимости установки дополнительных компонентов 1С.

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

Для доступа достаточно иметь веб-браузер, и устройство с доступом к сети интернет.

Служба 1С — отдельно, БД — отдельно: простой принцип, обеспечивающий необходимую производительность.

В Интернете нет недостатка в инструкциях по публикации обоих элементов в единой физической локации – то есть, в рамках старой парадигмы. Это довольно просто: запускаем 1С от имени Администратора, затем в конфигураторе «Администрирование» выбираем «Публикация на веб-сервере». И, собственно, готово.

Но что делать, когда служба 1С и веб-служба должны располагаться на разных серверах?

Организовать веб-сервер для 1С можно с помощью двух решений: Internet Information Server (IIS), который включён в операционную систему Windows, а также с помощью Apache-сервера.

Обе утилиты распространяются бесплатно и предлагают все необходимые функции для настройки удаленных серверов.

Для IIS

Для публикации базы на веб-сервере IIS необходимо сначала установить требуемые компоненты IIS и платформу 1С с компонентой «Модули расширения веб-сервера».

При установке IIS обязательно устанавливаются следующие компоненты.

Общие функции HTTP (Common HTTP Features)

• статическое содержимое (Static Content);

• документ по умолчанию (Default Document);

• обзор каталогов (Directory Browsing);

• ошибки HTTP (HTTP Errors).

Разработка приложений (Application Development)

• ASP;

• ASP.NET. 3.5;

• Расширения ISAPI (ISAPI Extensions);

• Расширяемость .NET 3.5 (.NET Extensibility 3.5);

• Фильтры ISAPI (ISAPI Filters).

Исправление и диагностика (Health and Diagnostics)

• Ведение журнала HTTP (HTTP Logging);

• Монитор запросов (Request Monitor);

• Средства управления (Management Tools);

• Консоль управления IIS (IIS Management Console).

После установки платформы 1С и компонентов IIS пользователю (или группе IIS_USRS), от имени которого запущена служба веб-сервера, необходимо предоставить права на каталог с платформой 1С для возможности запуска компонентов.

Включение компонентов веб-сервера IIS в операционной системе Windows 10 выполняется достаточно просто. Для начала нужно открыть раздел «Программы и компоненты» (Programs and Features) в панели управления (Control panel). Когда откроется окно «Компоненты Windows» (Windows features) в нём необходимо проставить флажки для следующих элементов:

Службы IIS

• Службы интернета;
• Компоненты разработки приложений;

и далее:

• Расширение ISAPI;
• Фильтры ISAPI.

Средства управления веб-сайтом

• Консоль управления IIS.

Затем нажимаем «OK», ждём завершения выполнения операции. После того как включение компонент будет выполнено, можно переходить к публикации информационной базы.

Настройка компонент производятся в диспетчере серверов (Server Manager). Необходимо выбрать «Управление» — «Добавить роли и компоненты» (Manage — Add Roles and Features). В Add Roles and Features нужно два раза нажать «Далее» (Next) пока мастер не переключится на страницу ролей сервера (Server Roles).

Во вкладке роли сервера (Server Roles) установите флажок Web Server IIS. Данная роль зависит от другой ([Tools] IIS Management Console), она устанавливается через «Добавить компоненты» (Add Features) в открывшемся окне.

После чего нажимаем кнопку «Далее» (Next) пока мастер не дойдёт до вкладки «Роль веб-сервера IIS» (Web Server Role IIS).На этой вкладке — «Далее» (Next) и попадете на вкладку «Служба ролей» (Role Services).

Во вкладке нужно найти пункт Application Development и выбрать в нем с помощью флажков пункты ISAPI Extensions и ISAPI Filters. После установки флажков — «Далее» (Next) и «Установить» (Install). На этом установка веб-сервера завершена.

Пример:

"C:\Program Files\1cv8\8.3.16.1224\bin\webinst.exe" -iis -wsdir base1 -dir "C:\inetpub\wwwroot\base1" -connStr "Srvr="Srv1C";Ref="base1"

Для Apache

Если в качестве веб-сервера выбран Apache, нередко много времени приходится тратить на поиск корректной ссылки для скачивания актуального дистрибутива Apache.

Архив с сервером скачивается и разархивируется в любую удобную папку, например, C:\Apache24. В названии папки указан номер версии Apache, например Apache 2.4.

При публикации информационной базы из командной строки стоит обращать на номер версии для того, чтобы выбрать корректную библиотеку веб-компонент, поставляемую с платформой.

После разархивирования в командной строке от имени администратора (меню «Пуск» и ввод cmd) открываем приложение через пункт меню «Запустить от имени Администратора» (Run as Administrator).

В командной строке переходим в директорию распакованного Apache с помощью команды cd

cd C:\Apache24

и директории Apache вводим команду:

httpd.exe -k install

Это установит Apache, которым можно далее управлять в окне служб.

Далее нужно только опубликовать информационную базу и указать файлы сертификата в настройках Apache.

Для публикации базы нужно открыть конфигуратор конкретной базы от имени администратора и перейти в пункт меню «Администрирование». После этого выбрать «Публикация информационной базы». В окне публикации указываются имя публикации и каталог, где будут находиться ее настройки. После этого нажать «Опубликовать» и дождаться окончания операции

Синтаксис:

webinst [-publish] | -delete <веб-сервер> -wsdir <виртуальный каталог>

-dir <физический каталог>

-connstr <строка соединения>

-confpath <путь к файлу httpd.conf>

-descriptor <путь к файлу default.vrd>

[-osauth]

Пример:

"C:\Program Files\1cv8\8.3.16.1063\bin\webinst.exe" -apache24 -wsdir base2 -dir

"C:\Apache24\w\base2" -connStr "Srvr="Srv1C:2541"; Ref="base2";" -confPath

"C:\Apache24\conf\httpd.conf"

Для проверки корректной публикации базы нужно открыть ссылку, которая состоит из двух частей:

• Имени сервера;
• Имя публикации базы, указанное в окне настройки публикации.

По результатам обсуждений собрали основной бриф:

• Разработать систему по регистрации новых абонентов и созданию бизнес-процессов по их подключению с проведением процесса по всем нужным отделам в компании.
• Разработать систему по отключению существующих абонентов и созданию бизнес-процессов по их отключению с проведением процесса по всем нужным отделам в компании.
• Разработать систему оповещения о плановом проведении ремонтных работ на линиях.
• Разработать систему регистрации поступающих заявок от абонентов.
• Автоматизировать систему расчётов для абонентов телекоммуникационных услуг.
• Провести интеграцию с банковским ПО для приёма и обработки платежей от абонентов в системе бухгалтерского учёта.

За основу был взят следующий стек технологий и инструментов:

• Система бухгалтерского учёта на платформе 1С Бухгалтерия, Управляемые формы.
• 1С Битрикс24 – как инструмент для использования механизма бизнес-процессов и уведомлений для абонентов.
• IIS (Internet Information Services), встроенный компонент серверных ОС на платформе Windows Server, – как инструмент для того, чтобы развернуть внешний web-сервис.
• Postman – как инструмент для тестирования запросов.

Приступаем к реализации

Первым делом в системе бухгалтерского учёта создаём новый вид  – учёт коммуникационных услуг. Он содержит в себе необходимое количество документов, справочников, регистров. Совмещаем его с существующей системой через систему расширений конфигурации, чтобы в дальнейшем не сталкиваться с проблемами в обновлениях и соответствовать правилам разработки.

Процесс занял некоторое время. От согласования с отделом бухгалтерии до финальной реализации прошло около двух недель.

Далее переходим к настройке документооборота и CRM-системы на платформе Битрикс24. Тут начинается самое интересное:

• При подключении нового абонента оператор со стороны 1С заполняет заявку на подключение, далее эта заявка попадает по протоколу REST в систему Битрикс24 и инициирует запуск бизнес-процесса, по которому задействуются нужные отделы и сотрудники (определение необходимости закупа оборудования, контроль оплат, распределение по командам монтажных бригад, финальный монтаж и подписание документов о передачи оборудования абоненту). После закрытия заявки абоненту приходит SMS-уведомление об успешном подключении к сервису. Заявка закрывается.
• При поступлении заявки от абонента об отключении от услуги или подключении к другому тарифу оператор вносит эти данные со стороны 1С. Далее заявка попадает в Битрикс24 на контроль в отдел бухгалтерского учёта и при отсутствии задолженности происходит распределение по монтажным бригадам, которая производит демонтаж и подписывает необходимые документы.
• Аналогичным образом настроены механизмы оповещений и обработки входящих заявок от абонентов. Автоматизированный расчёт стоимости происходит на стороне 1С. Если рассказать кратко, то при групповом формировании документов начисления для абонентов из базы 1С данные в Битрикс24 поступают через протокол RESTAPI. Далее  запускается бизнес-процесс системы оповещений через SMS о необходимости внесения оплат с контролем оплаты. В том случае, если от абонента не поступает реакции, разработана система уведомлений и, как крайний шаг, задача на отключение.

Далее переходим к интеграции с банковском ПО. После недолгих переговоров с местным отделением банка, в котором открыт счёт, пришли к соглашению. Банк
добавляет в приложение нашу компанию в список сервисов. При переходе абонент вводит свой ИИН и получает текущую сумму, которую нужно оплатить.

Запускаем web-сервис

На стороне 1С разработали HTTP-сервис, имеющий в себе два основных метода:

PostCustomersInfo – получает методом POST от банка информацию о успешной транзакции и вводе в базу 1С входящего платёжного поручения.

Содержание обработчика GetCustomerInfo в 1С:

Публикация web-сервиса ничем особым не примечательна, да и прошла без особых проблем. Вуаля, сервис работает.

Логика получилась следующая:

1. Абоненту поступило SMS-уведомление о необходимости оплаты.
2. Он переходит в приложение банка, вводит свой ИИН, получает сумму для оплаты, производит оплату.
3. В базу 1С попадет уже полностью заполненное платёжное поручение.

В логику проведения платёжного поручения внесён дополнительный исполняющий код, использующий фишку WebHooks от Битрикс24, позволяющую сместить стадию сделки в статус «Оплачено» и, соответственно, прекратить контроль оплаты по выставленной квитанции.

Когда пошли первые платежи от абонентов, бухгалтер по банковским операциям был очень удивлён тому, что больше не нужно разносить операции вручную. Вроде простой механизм, реализация которого заняла не такое большое время, но функционал оказался крайне полезным.

В итоге у нас есть:

1. Автоматизированная обработка поступающих заявок от абонентов.
2. Автоматизированный расчёт стоимости услуг и контроль оплат по ним.
3. Автоматизированная система приёма и разноски оплат в системе 1С Бухгалтерия.

А как вы автоматизируете процессы?

За годы работы я часто слышал вопросы о выборе технологий для того или иного веб-проекта. Кто-то спрашивает у нас, как у разработчиков, как правильно, а кто-то приходит и просит сделать на какой-то конкретной технологии.

Проблема в том, что большинство выбирают технологии по субъективным причинам и пока я не слышал достойного и внятного рассуждения, которое позволит выбрать технологию объективно, основываясь на фактах, а не желаниях. Даже немногие IT-шники могут правильно выбрать технологию, ведь для этого нужно: понимать специфику проекта, иметь многолетний опыт разработки на нескольких языках, знать, как устроены подобные проекты и т.д.

Но прежде, чем что-то выбирать, давайте посмотрим, какие технологии бывают, чем они отличаются и в каких случаях какую технологию выбрать.

Как чаще всего выбирают технологию сейчас:

1. Она мне нравится
2. Знакомый посоветовал
3. Прочитал в Интернете
4. На этой технологии сделан аналогичный сайт

В чем тут проблема:

1. Нравится. Очень субъективно. А что, если по требованиям она не подходит? Или на ней очень дорогие и редкие специалисты? Или она вообще умирает?

2. Знакомый. Обычно это тот знакомый, который «чуть лучше» разбирается в ИТ, чем тот, кому он советует. И даже если он программист с опытом, он не может знать всех решений на всех популярных языках. Ведь никто не спрашивает, по каким критериям выбирал этот знакомый. Если этот знакомы не CTO Google, я бы так просто не доверял такой рекомендации.

3. Прочитал. Тут уже лучше, можно найти разные сравнения и аргументацию. Но опять же, чтобы разобраться во всех решениях человеку, пусть даже с крепкими знаниями в разработке, нужно время. А без знаний в разработке все прочитанные технические обзоры ничего не стоят.

4. Аналог. Большинство популярных сайтов написаны на тех или иных технологиях потому, что так «исторически сложилось» . Если бы Facebook сейчас выбирал технологию для себя, я сомневаюсь, что он взял бы за основу PHP. А еще может быть, что технология уже устарела, её продавили на основе прошлых 3х пунктов, выбрали какую-то разрекламированную технологию, а не действительно эффективную и т.д. Вы вряд ли можете знать реальные причины выбор технологий в других проектах. Оптимальные технологии используются крайне редко в аналогичных проектах.

Таким образом, ни один из вышеперечисленных методов выбора технологий разработки не отвечает критериям объективности. Поэтому стоит сначала определить эти критерии, а уже потом подбирать по ним техническую платформу. Ниже я попытаюсь выделить действительно важные для проекта критерии, на которым мы и будем основываться.

Важные критерии при выборе технологий:

1. Размер и тип проекта
2. Сложность проекта
3. Скорость разработки
4. Стоимость специалистов
5. Доступность специалистов
6. Доступные инструменты разработки
7. Наличие готовых решений
8. Гибкость решения
9. Наличие широкого сообщества
10. Отказоустойчивость решения
11. Тренд его развития
12. Наличие подробной документации
13. Стоимость поддержки
14. Требования к нагрузкам
15. Требования к безопасности
16. Кроссплатформенность
17. Возможности интеграции с другими решениями

Выбирая технологию по таким критериям мы сможем добиться объективного выбора и тем самым сэкономить себе время и деньги.

Какие бывают проекты

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

Сложность проекта

1. Простые (визитки, лендинги, простые интернет-магазины, простые приложения) — такие решения обычно делаются на тематических коробочных решениях, CMS или шаблонах.
2. Средние (сложные интернет-магазины и маркетплейсы, порталы национального масштаба, разнообразные сервисы, продвинутые приложения) — такие решения обычно делаются на фреимворках.
3. Сложные (огромные порталы, социальные сети, инновационные и нетиповые решения) — ядро таких проектов обычно разрабатываются на чистом (нативном) языке программирования.

По тематике: интернет-магазины, доски объявлений, социальные сети и т.д. Для большинства популярных тематических решений уже давно есть коробочные продукты и, если мы не пытаемся сделать какого-то монстра, то правильнее будет выбрать именно их. Решений очень много, все в одной статье описать невозможно.

Языки программирования

В технологиях я бы выделил 3 уровня абстракции:

1. Чистый язык — это материал, из которого можно сделать все, что угодно. Ограничивают нас только возможности языка. На чистом языке сделаны все крупнейшие сайты мира с посещаемостью в сотни миллионов и миллиарды пользователей, такие как: Instagram, YouTube, Pinterest, Tumblr, Dropbox, Twitter, Facebook, Amazon, Digg, LinkedIn и другие. Более того, крупнейшие проекты в мире даже создают новые технологии для себя, так как уже существующие их не устраивают.
2. Фреимворк — это некая среда разработки для программиста с готовыми правилами и инструментами. Фреимворк с одной стороны помогает и ускоряет разработку, а с другой накладывает определенные ограничения. На фреимворках делаются проекты средней сложности с посещаемостью в миллионы.
3. CMS — это уже готовое решения, конструктор, в котором мы по частям собираем нужный проект. Его скорее не программируют, а настраивают. Ограничений тут огромное количество, выйти за границы коробки сложно и неэффективно. На CMS делаются простые сайты с посещаемостью до миллиона пользователей в месяц.

Чаще всего один уровень абстракции базируется на другом. То есть на чистом языке делают фреимворки, а на фреимворках делают CMS. Для каждого популярного языка есть много разных фреимворков и CMS, но об этом позже.

Сегодня есть огромное количество разных языков программирования, на которых делают сайты. И, более того, на всех популярных языках есть примеры огромных сайтов. Если 10 лет назад, говоря о технологиях больших сайтов, все говорили преимущественно про Java, то сегодня это может быть почти любой язык и утверждать, что сайты делаются на каком-то конкретном языке — стереотип. Это связанно с развитием самих языков, за последнее десятилетие многие сильно продвинулись в развитии и получили широкие возможности. Конечно, каждый язык чем-то отличается и выбирая мы опять же должны руководствоваться объективными критериями с оглядкой на задачи проекта.

На чистом языке, без использования фреимворков и коробочных решений, пишутся огромные проекты с повышенными требованиями по гибкости, нагрузкам и безопасности. Для таких огромных проектов часто бюджет не играет такого значения, как эффективность. Чем больше проект, тем больше будет требований по гибкости и нагрузкам, а значит, проще писать все с нуля, выделяя на это лучших специалистов, чем если брать какие-то готовые решения, которые непонятно кем писались и непонятно какие проблемы в них скрыты. К примеру, когда речь про небольшой проект с посещаемостью в 10 тыс. человек в день, то нам будет дешевле сделать его на CMS, которая будет потреблять в 3 раза больше ресурсов сервера, поставить дополнительный сервер за 50$ / мес. и оно будет работать. Когда же мы говорим про сайт с посещаемостью в 100 млн. пользователей в день, стоимость добавления серверов у нас будет просто космической, поэтому нам проще и дешевле вложить деньги в разработку решения на чистом языке, которое будет оптимальным именно для конкретного проекта.

Чем больше проект, тем больше стек технологий, который в нем используется. В огромных порталах может использоваться сразу несколько языков программирования. Опять же, мы приходим к объективным критериям выбора технологий. Часто один язык может хорошо делать одну задачу, а другой — другую. Такие проекты могут быть на столько огромными, что его части могут работать на разных серверах, с разными доменами (поддоменами) и разными технологиями. Не следует боятся винегрета технологий в большом проекте, хотя и допускать его нужно только когда это действительно необходимо, а также помнить, что далеко не все технологии совместимы. Самый яркий пример использования разных технологий — Google. Он на столько большой, что разные его части написаны на C/C++, Java, Python, JS и других языках. Более того, Google активно создает новые технологии, как, например, популярный нынче AngularJS.

Попробую дать краткую характеристику каждому из популярных языков:

1. PHP — его используют в основном для простых и средних проектов. Очень много коробочных решений. Относительно дешевые программисты. Антитренд последних лет, хотя с выходом последней версии языка под номером 7, он получил действительно мощные возможности.
2. Python — современный язык, разработка на нем быстрая и качественная. Используют его для средних и больших проектов. Программистов найти проблематично и стоят они не дешево.
3. Ruby — современный язык, разработка на нем так же быстрая. Его используют в основном для разработки простых и средних проектов, часто разрабатывают стартапы. Программистов также мало и они дорогие.
4. Java — разработка на нем очень долгая и дорогая. Его используют в основном для больших проектов со специфическими требованиями. Однако является самым популярным языком программирования в рейтинге TIOBE по состоянию на март 2016.
5. C# — аналог Java, также используют для больших проектов, часть в сфере FinTech.
6. JavaScript — очень быстро развивается, тренд последних лет и самый популярный язык программирования в рейтинге Redmonk по состоянию на июнь 2016. Огромное количество наработок и можно писать все, что угодно, даже игры. Его используют для средних и больших проектов, но действительно мощные возможности этот язык получит недавно, потому примеров больших проектов пока мало, специалисты самые дорогие и найти их сложнее всего.

Я описал самые популярные языки, которые сегодня используются под веб. Есть много новых языков, которые очень быстро растут, в частности Scala и некоторые другие. Но пока они довольно молодые и сырые. Я бы не рекомендовал бежать за модой и писать на них, пока они не разовьются во что-то большее.

Примеры больших сайтов:

• PHP: Facebook, Вконтакте, КиноПоиск
• Python: Instagram, Pinterest, Reddit
• Ruby: 500px, Groupon, Airbnb
• Java: Ebay, Amazon, Alibaba
• C#: Guru, Stack Overflow, Bank of America
• JS: LinkedIn, Walmart, PayPal

Эти примеры отлично показывают, что большие сайты могут быть написаны на разных языках, и это нормально. Опять же, приходим к тому, что выбирать технологию нужно под требования, руководствуясь объективными причинами.

Фреймворки и платформы

Это некая среда разработки для программистов, где есть готовая инфраструктура и ряд готовых функций со стандартными решениями типичных задач. Такой себе полуфабрикат, из которого можно сделать конфетку. На каждом языке есть много разных фреймворков. Есть как общие, которые создавались для разработки любых решений, так и специализированных, под узкие задачи. Например, Sylius — специализированный E-commerce фреймворк на основе Symfony. Также есть те, на которых делаются большие и сложные решения, а другие для этого не предназначены. Ниже я опишу популярные фреймворки для каждого из языков, на которых можно писать большие и сложные решения.

На фреймворках разрабатываются довольно большие и сложные сайты с уникальным функционалом. Это значительно быстрее и дешевле, чем на чистом языке, но при этом такое решение позволяет разрабатывать действительно сложные вещи и оптимизировать все это под нагрузки. Кроме того, это почти всегда более безопасно, чем любая коробочная CMS. Если вы хотите узнать об этом больше, посмотрите материал про веб-фреймворки для начинающих.

Популярные фреймворки и платформы:

1. PHP: Symfony, Laravel
2. Python: Django
3. Ruby: Ruby On Rails
4. Java: Spring
5. C#: .NET
6. JS: Node.js, AngularJS

Больше всего фреймворков на PHP и на этом языке есть, из чего выбирать, но действительно функциональных не так много. Меньше на других языках, а на некоторых действительно качественных фреймворков вообще всего один, как у языка Ruby. У Java вообще очень много разных фреймворков для разных целей, и не только для сайтов. Все эти фреймворки ежегодно развиваются, выходят все новые и новые версии, одни фреймворки обгоняют другие. Например, Laravel только в последние несколько лет вышел на первое место по популярности, хотя самые сложные сайты до сих пор делаются на Symfony.

.NET и Node.js — это целые самостоятельные платформы, которые базируются на определенных языках, но имеют очень широкие возможности.

CMS и CMF

Это готовое программное обеспечение, которое нужно только настроить, реже — дописать / переписать какую-то из частей. Таких решений очень много на любом языке, но исторически так сложилось, что в основном все популярные CMS сделаны на PHP. Тут дело в развитие языков, раньше простые сайты, для которых и создавались CMS, писались на PHP. Я еще застал те времена, когда CMS почти не было, были скрипты — отдельные готовые части разных сайтов. Позже эти скрипты собирали в коробочный продукт, который был призван решить потребности 90% простых сайтов. Так и получилось, что основные CMS сделаны на PHP. Сегодня CMS на других языках развиваются слабо, потому, что уже есть сильные конкуренты на PHP, а простому сайту язык не играет большой роли, поэтому все смотрят на возможности этих готовых продуктов.

CMF — если говорить простым языком, это что-то среднее между CMS и фреймворком по возможностям. Обычно CMF используют для самых сложных сайтов из этой категории. Этот подход позволяет избавиться от лишних частей CMS, которые не нужны конкретному проекту.

CMS бывают разные по назначению: общие, для интернет-магазинов, для блогов и т.д. Разные по условиям использования: платные и бесплатные. Для каждой популярной CMS есть куча разных платных и бесплатных модулей, которые легко подключать и использовать.

Маленькие сайты, которые в основном нужны для малого бизнеса, почти всегда используют CMS. Это позволяет очень сильно экономить время на разработку. Кроме того, для настройки таких решений не нужны дорогие программисты, обычно это могут делать новички в программировании, по крайней мере саму настройку, если уже нужно писать код, тут сложнее.

Именно в работе с CMS возникает больше всего непонимание среди конечных заказчиков таких решений. Любая CMS — это тонны готового программного кода, на все случае жизни. В коробочной поставке идут десятки и сотни модулей. Все это очень сильно ограничивает специалистов. Такие решения сильно «тормозят» , они абсолютно не гибкие, их очень легко взломать, особенно бесплатные CMS. Еще часто взламывают CMS через модули сторонних разработчиков, в которых есть критические уязвимости, потому что мы никогда не знаем, какого уровня программист писал тот или иной модуль. То есть любая CMS НЕ рассчитана для большого и сложного сайта. Она не могут выдержать большие нагрузки. Это решение не безопасно, чтобы не говорили разработчики конкретной CMS.

Я видел решения почти на всех популярных CMS, с многими за более, чем 10 лет работы, пришлось поработать лично. Часть из них популярна в рунете, а часть знают в основном на западе. На используемые в них языки CMS разбивать нет смысла, по причинам, описанным выше. Лучше сказать несколько слов про каждую популярную CMS:

1. WordPress — некогда блоговый движок, сейчас на ней делаются почти любые сайты, включая магазины. Одна из самых популярных CMS в мире, есть примеры довольно посещаемых сайтов. На ней часто делают информационные сайты, в том числе разные СМИ. Система бесплатная.
2. Joomla! — CMS общего назначения. Качеством особо не отличается, на ней делают очень маленькие сайты и обычно дешевле всех других вариантов, так как именно с этой CMS начинают учиться многие начинающие программисты. Система бесплатная.
3. Drupal — это уже CMF для общего назначения, с недавнего времени поставляется со встроенных фреймворком Symfony. Довольно мощная, на ней есть известные сайты, например, официальный сайт Белого Дома. Система бесплатная.
4. Magento — самая популярная система управления для интернет-магазинов в мире. Довольно мощная и сложная. В рунете используется редко, в основном на западе.
5. PrestaShop — одна из самых популярных CMS для магазинов в мире. Тоже довольно мощная, используют в основном на западе. Система бесплатная.
6. OpenCart — еще одна популярная система для интернет-магазинов, но её, наоборот, больше используют в рунете, чем на западе. В основном для маленьких и несложных магазинов. Система бесплатная.
7. 1С-Битрикс — очень распиаренная CMS общего назначения, номер 1 в рунете. Возможности очень широкие. На ней часто пытаются делать большие и сложные сайты, а после определенного порога в посещаемости переписывают их на других технологиях. Многие считают, что только эта CMS может интегрироваться с 1С, что не является правдой, поскольку все перечисленные CMS из этого списка могут интегрироваться с 1С, для этого у всех CMS есть специальные модули. Система платная.

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

Шаблоны

В последние 5 лет очень активно развивают шаблонные решения. Это еще на одну ступеньку выше, чем CMS. Если CMS — это конструктор и его нужно настраивать, то шаблоны — это уже готовые решения под типовые случаи. Например, в каждом городе есть свои рестораны, такси, клиники и т.д. Для всех этих типов малого бизнеса нужно примерно одно и тоже. Поэтому, можно просто выбрать готовый тематический шаблон, заменить в нем логотип, цвета и контент. При желании такие шаблоны можно дорабатывать по усмотрению владельца.

Преимущества таких решений в том, что они очень дешевые и их можно запускать моментально. Но при этом, такие решения не учитывают особенностей бизнеса и конверсия будет не очень высокой.

Есть специальные каталоги шаблонов: TemplateMonster, ThemeForest и др. Часто встречаются онлайн-конструкторы, в том числе тематические: Wix, PageCloud и др.

Мобильные приложения

В мобильных приложениях в последнее время используется два подхода: нативная разработка и кроссплатформенные технологии. Нативная ведется на оригинальных языках программирования, в частности Swift (для iOS, ранее был Objective-C) и Java (для Android). Кроссплатформенных технологий сейчас довольно много, они есть на базе разных языков программирования, в частности: Apache Cordova, React Native и др. Некоторые лучше, некоторые хуже. В любом случае, сложные приложения всегда пишутся на нативных технологиях. С кроссплатформой часто возникают проблемы, вплоть до того, что некоторые функции просто нереализуемы на тех или иных кроссплатформенных технологиях, сильно грузится оперативная память устройства, быстро садится батарея и т.д.

В этих двух подходах люди тоже часто путаются, пытаясь использовать кроссплатформенные подходы на все случаи жизни. Оно и понятно, ведь кроссплатформа позволяет писать код один раз, который сразу работает и на iOS и на Android, в то время, как на нативных технологиях это минимум в два раза дороже выходит. Однако мало кто знает про возможные дальнейшие проблемы в разработке. Я бы рекомендовал очень тщательно выбирать технологии и кроссплатформу брать только для простых приложений, иначе придется переписывать. Впрочем, кроссплатформенные технологии постепенно развиваются и становятся все лучше, а приложения написанные на них все сложнее.

Стек технологий в больших проектах

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

Выбор технологий зависит от предлагаемой архитектуры проекта. Именно архитектор продумывает основные блоки будущего сайта. Какой язык ляжет к основу, будет ли он нативный или фреймворк, какую систему кэширования выбрать, какие базы данных, как все это связано и т.д.

Для примера рассмотрим технологии Instagram (данные Insight IT):

• Ubuntu Server 14.04 LTS — основная серверная операционная система
• Python — основной язык программирования серверной части
• Django — фреймворк
• nginx — второй уровень балансировки входящих HTTP-запросов
• gunicorn — WSGI-сервер
• HAProxy — балансировка нагрузки внутри системы
• PostgreSQL — основное хранилище данных
• postgis — поддержка гео-запросов
• pgfouine — отчеты на основе логов
• pgbouncer — создание пула соединений
• Redis — дополнительное хранилище данных
• Memcached — кэширование
• Gearman — очередь задач
• Solr — гео-поиск
• munin, statsd, pingdom — мониторинг
• Fabric — управление кластером
• xfs — файловая система

И это вполне нормальный стек технологий. Сам Instagram не самый большой и сложный сервис в мире.

Стоимость специалистов

Один из важнейших факторов выбора технологии является стоимость и доступность специалистов, потому что именно это самая затратная часть в любом проекте. В рунете есть только одна пузомерка по зарплатам — я отфильтровал по Киеву, уровень Senior, опыт 3-5 лет. Сравним средние значения.

Зарплаты:

1. C# — 3072$
2. Java — 3300$
3. JS — 3500$
4. PHP — 2780$
5. Python — 3000$
6. Ruby — 3000$
7. Scala — 3900$

В США немного другая картина:

Теперь переведем цифры на человеческий язык. Java хоть и не новый язык, но специалисты на ней всегда были одними их самых дорогих. PHP всегда был самым дешевым, да и специалистов на рынке очень много. В сравнение я внес еще и Scala как один из новейших и трендовых языков, по этой причине он дороже всех. Еще дорогой JS, это связанно с его бурным ростом в последние годы и растущей популярностью Node.js, а также AngularJS.

Таким образом, если мы хотим экономить — то лучше смотреть на PHP, специалисты дешевые, а комьюнити большое. А если хотим самое качественное — то смотрим на Scala, который называют будущем веб-разработки, но, правда, на ней найти специалистов почти невозможно и наработок просто нет.

Еще важным параметром будет скорость разработки. Ведь важна не только зарплата программистов, но и скорость разработки. Если не учитывать уже существующие наработки, то одним из самых быстрых в разработке будет Python и Ruby, а самый медленный — Java. Кстати, по этой причине за последние 10 лет почти не вышло новых мегапроектов на Java, зато вышло много проектов на Python, о чем я расскажу ниже.

Тренды

Выбирая технологию, нам нужно смотреть вперед. Особенно, если речь о большом проекте. Все технологии очень быстро развиваются, выходят все новые и новые версии. Языки сильно меняются каждые 5-7 лет, фреймворки — каждые 2-3 года, а CMS — каждые 1-2 года. Важно выбрать не просто хорошую технологию сегодня, а предугадать тренды развития так, чтобы остаться на коне через несколько лет. Иначе, в конечном счете, придется переписывать проект, что всегда очень проблематично.

Есть всевозможные исследования, которые нам могут подсказать некоторые статистические выкладки. Например, исследование TIOBE Index показывает интересную статистику:

По результатам разных исследований можно выделить явных лидеров по росту — это JS (версия ES6 и выше) и мультипарадигмальные языки, в частности Scala. Кстати, именно Scala считается преемником языка Java и во многом на него похож. Также не плохо себя показывает Python.

Антитренды держат ряд старых языков и PHP. Правда, недавно вышла 7я версия PHP, в которой исправлены многие серьезные недостатки. Так что, я думаю, мы скоро увидим новый виток развития PHP. Еще многие большие проекты переписываются с Ruby на другие языки, тоже некий антитренд.

Для иллюстрации посмотрим, каких специалистов не хватает в США:

Именно это можно считать реальной картиной трендов, которые мы видим и у нас.

На чем делались большие проекты за последние 10 лет?

1. Airbnb — Ruby
2. Instagram — Python
3. Pinterest — Python
4. Foursquare — Python
5. Groupon — Ruby → JS
6. Twitter — Ruby → Scala
7. Uber — JS

Это уже не теоретическая статистика, а реальная практика. Python и JS очень хорошо себя показывают.

Стоимость поддержки

Безусловно, важный критерий выбора технологии — это стоимость поддержки, о которой мало кто задумывается в начале разработки. Обычно все мыслят категориями стоимости часа поддержки, что в корне неправильно. Нам важны несколько параметров: стоимость часа, количество часов, официальная поддержка технологии, доступность специалистов, правильный подход к разработке и некоторые другие.

Стоимость часа зависит от зарплаты специалисты, с этим мы уже разобрались. А вот количество часов зависит от самой технологии и качества написания кода. Если решение коробочное, то часов на него может уходить очень много. То есть, с одной стороны, мы можем сэкономить при разработке первой версии проекта, но после погрязнуть в его постоянной доработке. Хорошо, когда решение популярное и есть официальная документация, но часто выбирают малоизвестные коробочные решения без какой-либо документации — в таких решениям стоимость поддержки будет во много раз выше стоимости самой коробки. То же касается некачественной разработки: у нас почему-то полностью отсутствует культура проведения технических аудитов готовых решений или его частей. В среднем за 20-40 часов можно проверить почти любое решение и найти его основные минусы. Чем более качественный код, тем легче, а следовательно и дешевле его поддерживать.

Также следует смотреть на версию языка, фреимворка, CMS. Нужно всегда использовать самую последнюю стабильную версию, чтобы она не устарела до выхода проекта в продакшн. При появлении новой версии, нужно сразу рассматривать возможность перевода проекта на эту версию. Потому что, если пропустить несколько версий, потом будут проблемы сделать резкое обновление.

Так что выбрать?

Подведем итог. Для простых сайтов чаще всего отлично подходят коробочные решения и шаблоны. Сложные сайты делаются только на фреимворках или даже чистых языках программирования. Делать можно на очень разных языках, язык выбирается под проект. Простые мобильные приложения можно делать на кроссплатформенных технологиях, а сложные обычно делаются на родных технологиях. Ну и, выбирая платформу, всегда стоит руководствоваться объективными критериями, которые я описал в статье.