Привет, мир! Софья, 5 лет в ERP на Turbo Script, старший разработчик Консист Бизнес Групп. За это время я не раз убеждалась: обучение стажёров — это искусство баланса между академическими знаниями и реальными задачами, где каждая строчка кода может стать либо фундаментом архитектуры, либо техническим долгом.

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

Если Вы джун, который только входит в мир продуктовой разработки, или наставник, ищущий подход к обучению, добро пожаловать под кат!

Введение: 5 основных задач стажировки

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

Задача 1: Оценка базового технического уровня: владение языком, понимание основ ООП и принципов SOLID, а также понимание специфики корпоративных информационных систем (КИС/ERP) и их отличий от обычных приложений. На этой основе определить область дальнейшей работы. 

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

Задача 3: Научить стажёра применять инженерные практики (Git, Agile, работу с СУБД, т.п.) и эффективно работать в команде — интегрировать свое решение в существующую кодовую базу, планировать задачи, документировать результаты, фикс��ровать изменения.

Задача 4: Научить стажёра выполнять тесты для собственного кода и проверять интеграцию своего решения в общий функционал. 

Задача 5: Демонстрация своего решения куратору. Научить стажера отвечать на вопросы и конструктивно воспринимать обратную связь. Этот этап рекомендательный, но полезный для развития soft-skills.

С чего начинается обучение: оценка базы и контекста

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

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

Почему склад? Он осязаемо представим, близок к реальному бизнесу и сразу дает базовые сущности: 

  • Товар, то что хранится

  • Коробка, то что инкапсулирует товар

  • Полка, место хранения коробок

  • Склад, система, объединяющая все вместе.

Уже на этом уровне можно определить ключевые идеи: 

  • Инкапсуляция — товар «спрятан» внутри коробки, и к нему есть контролируемый доступ;

  • Наследование — коробка для игрушек, может быть специализацией общей коробки;

  • Полиморфизм — разные товары можно класть на одну и ту же полку, если у них соответствующий интерфейс — «хранить на складе».

Можно ли объяснить на примере склада и коробок принципы SOLID? Так, если коробка отвечает за хранение, а полка — за размещение — мы можем сформулировать принцип единства ответственности. В случае же операций «положить» и «взять», которые четко определяются для каждого уровня, — мы говорим о принципах разделения интерфейсов. 

И здесь мы плавно подходим к главному вопросу: а как управлять всем этим в масштабе предприятия? Здесь уже естественно возникает потребность в системе, которая будет не просто хранить наши товары на полках, но и обеспечивать контроль и согласованность хранения. А отсюда уже следует не «зачем мне архитектура», а «как спроектировать так, чтобы завтра не пришлось переписывать все с нуля». 

В итоге структура первой встречи с юным «падаваном» выстраивается как 1-2 часовая беседа по следующему алгоритму:

  1. Задать следующий ряд вопросов: Что такое ООП? Что такое SOLID? Какие паттерны проектирования известны? Что такое ERP? Какой язык программирования уже известен?

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

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

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

Первая встреча со стажером — это не собеседование и не экзамен, а диагностическая сессия, рассчитанная на 1–2 часа. Ее цель — понять, на каком уровне находится человек, и выстроить индивидуальную траекторию обучения. При желании список вопросов можно расширить — например, оценить soft skills, опыт работы в команде, знакомство с Git или Agile. Но в рамках нашей стажировки основной фокус — перенос теоретических знаний в практическое проектирование. И этого минимума уже достаточно, чтобы понять, с чего начать.

Внутри проекта: MVC-подобная структура как основа порядка

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

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

В TURBO Script в процессе разработке для поддерж��ния подобного подхода существуют устоявшаяся структура, которая напрямую отражает принципы, обсуждаемые на этапе моделирования.

  • mtl-модель — это описание структуры данных. Именно здесь, мы фиксируем: что такое «товар», какие у него атрибуты. Платформа по описанным моделям создает в СУБД таблицы БД для хранения описанной структуры.  Зачастую это не одна таблица в СУБД, а много разных связанных между собой таблиц.

  • rec — отвечает за реализацию бизнес-логики. Здесь необходимо располагать правила: можно ли положить товар на полку, нужно ли проверять остатки, как обновлять историю перемещений. Это поведение сущностей, то есть «что делает коробка», а не просто «что в ней лежит». По сути этот класс является аналогом Controller в классическом MVC. 

  • frm — интерфейс взаимодействия пользователя с системой. То есть, то как оператор видит полку, выбирает коробку и перемещает товар. Здесь только представление, без логики.

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

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

Поэтому на практике мы даём чёткий алгоритм:

  • Создать наследника от базового системного класса (Com или Bas) — например, BaseDoc — и прописать в нём заглушки под будущие методы.

  • В последующих итерациях — создавать расширения этого класса, реализуя конкретную логику.

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

  • шапки (номер, наименование, итоги),

  • табличной части (для ввода данных по учёту).

И это дисциплинирует: сначала структура, потом детали.

Работа в команде как база хорошего продукта

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

Опыт показывает, что для того, чтобы не нарушать естественное погружение в продукт, но вместе с тем, контролировать сроки выполнения — на предварительное MVP достаточно 2-3 дней: на руках будет базовая структура проекта с файлами mtl, rec, frm и понимание того, как это связано с изначальной схемой. И тут возникает естественный вопрос: «Как отправить это на проверку?»

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

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

Зачем? Чтобы код можно было легко переиспользовать и интегрировать в другие проекты. Собственная разработка оформляется как отдельный репозиторий (Custom), а подключается в основной через .gitmodules. Структура проекта при этом выглядит так:

Projects/
── Vendor/         — файлы от вендора (не изменяются)
── Custom/		   — файлы разработки (изменяются)
   ── Addons/      — интегрируемые компоненты (субмодули)
   ── Склад/       — наш учебный проект

Также с самого начала вводим ветвление: даже в учебном репозитории должно быть как минимум две ветки — develop для активной разработки и main для релизов. Это формирует привычку, критически важную на реальных проектах.

Что касается Agile, то, учитывая фиксированную длительность стажировки (от 2 недель до месяца), мы утверждаем четкий план:

  • 3 дня — изучение языка и архитектуры TURBO

  • 7 дней — разработка MVP

  • 2 дня — написание и проверка тестов

  • 1 день — правки по фидбэку

  • 1 день — финальная демонстрация

Если стажировка длиннее — пропорционально увеличиваем этапы. Каждый из них завершается мини-стендапом (30–40 минут) по формату «вопрос–ответ», где стажёр показывает результат, объясняет решения и получает обратную связь. 

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

Самопроверка и документирование: учим писать код не «в стол»

На первый взгляд, всё очевидно: перед отправкой в удалённый репозиторий нужно убедиться, что решение работает. И всё же многие стажёры (да и не только они) пропускают этот шаг — особенно когда сроки поджимают. Чтобы сформировать устойчивую привычку, мы вводим чёткий чек-лист самопроверки.

  1. Возвращаемся к первоначальной схеме, составленной на этапе проектирования: реализована ли запланированная функциональность?

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

  3. Взаимная проверка (peer-review). Стажёры обмениваются проектами и тестируют друг друга по двум сценариям:

    1) Структурированное тестирование: по заранее известной функциональности проверяется, что:

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

    2) Исследовательское тестирование: без пояснений и плана — просто «разберись сам». Цель — оценить, насколько интерфейс понятен незнакомому пользователю.

    — Подписаны ли кнопки и закладки?
    — Есть ли подсказки при наведении?
    — Можно ли интуитивно понять, что делает каждая функция?

  4. Рефакторинг и код-ревью. Здесь в работу включается наставник: проверяется соблюдение стиля (отступы, именование, структура), оценивается рациональность алгоритмов, напоминаем о принятых соглашениях.

  5. Документирование. Одна из самых устойчивых привычек — не документировать код — присуща не только новичкам, но и опытным разработчикам. А ведь отсутствие пояснений превращает даже простую функцию в «чёрный ящик»: можно ли что-то менять? Что сломается? Зачем это вообще здесь? В TURBO Script мы решаем способами описанными ниже.

    1) К каждой процедуре и функции обязательно добавляется директива //help, где кратко описывается ее назначение. Этого обычно достаточно — язык поддерживает такую аннотацию, и она отображается в IDE. Комментарии внутри тела алгоритма допускаются, но только там, где логика нетривиальна — например, в сложных циклах или при обработке исключений.

    2) Особое внимание уделяем именованию — оно должно быть самодокументирующим: для локальных переменных используем шаблон: vVariableName, а для параметров функций — aVariableName; базовые сущности — Entity, а конкретные типы: NaturalEntity (физическое лицо), ContraParties (контрагенты).

    3) Цифры в именах запрещены — даже если они сгенерированы автоматически (например, при дублировании). Такие имена сразу требуют переименования.

    4) Для поддержания читаемости вводим две ключевые практики:

    — Длинные имена классов выносятся в отдельный класс Def;
    — Общие функции и утилиты размещаются в библиотечном классе Lib, чтобы избежать дублирования и упростить поддержку;
    — Неизменяемые значения, например цвет какой-нибудь кнопки или код справочника, выносим в класс —  Consts.

Такой подход учит стажёров понимать, что их код будут читать, использовать и ��азвивать другие. А в ERP-системе, где всё взаимосвязано, это не вежливость, а необходимость.

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

Финальный показ

Демонстрация проекта — необязательный, но крайне ценный этап. Обычно к ней привлекаем не только куратора, но и коллег из команды. Цель вовсе не в том, чтобы увидеть «крутой функционал» (у стажёров часто нет доступа к полной системе, и решение может выглядеть скромно), а в том, чтобы человек смог объяснить, что он сделал — и почему именно так. 

Формально вся стажировка и есть подготовка к демо. Но за день до выступления обычно даем такие рекомендации по презентации:

  • 5–7 минут на рассказ;

  • обязательно: схема проекта и краткий тезис — «в чём суть?»;

  • типовые сценарии использования — как этим будет пользоваться оператор;

  • архитектурные пояснения: например, почему расчёт остатков реализован в Rec, а некоторые обновления — во Frm (и когда это допустимо).

Также просим ответить на три ключевых вопроса:

  • Какие сложности возникли и как вы их преодолели?

  • Как выполнялось сохранение данных в БД и проверяли ли работу через веб-интерфейс?

  • Как ваш модуль может быть интегрирован в существующую систему?

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

Итоговую оценку команда даёт по трём критериям:

  • Интегрируемость — можно ли встроить модуль в существующую архитектуру без переделки;

  • Читаемость — насколько понятны код, структура и документация (//help, именование, стиль);

  • Осознанность — понимает ли стажёр, почему TURBO устроен так, а не иначе.

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

Заключение

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

Рекомендую начинать с простого — со склада, коробки и товара — но уже через две недели дать стажеру работать не с «кодом», а с системой: строить проект по правилам (mtl/rec/frm), оформлять его как субмодуль, документировать каждую функцию, выполнить тестирование  с учетом граничных случаев, и, наконец, объяснить свое решение коллегам — не как случайный набор форм, а как осознанный вклад в общую архитектуру.

Всё это возможно потому, что TURBO, несмотря на монолитную природу, допускает и поощряет модульный подход — если знать, как им пользоваться. А наша задача как наставников, помочь увидеть структуру за кодом, пользователя за интерфейсом и систему за отдельным модулем.

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