Интересный проект
В 2012 году появился интересный проект. Предстояло научиться java, сформировать команду, организовать конвейер по разработке корпоративной информационной системы. Разработку начал подрядчик, предстояло эту функцию забрать на себя.
Нырнул в эту задачу и выяснил много любопытного.
Это другое
Если кратко, то это другое. Разработка на java сильно отличается от разработки на 1С. Голову надо серьёзно перестроить. Там другие подходы, паттерны автоматизации. После нескольких лет работы в 1С привыкаешь задачи решать по определённому алгоритму. Да, для каждой предметной области своя логика, но база одна. Тут же куча разных инструментов, куча подходов, куча вариантов реализации.
Первый месяц ушёл на чтение умных книжек, изучение синтаксиса и на попытку после внесённых изменений собрать приложение.
Вот некоторые отличия:
1. Забота об инфраструктуре. Как обычно решается задача по реализации хранения и манипуляции с нормативно-справочной информацией? Создаёшь справочник, добавляешь реквизиты, табличные части, права, размещаешь в подсистеме. Ну, собственно и всё. За интерфейс формы списка и элемента можешь не переживать – они сформируются автоматически. Работы на 10 минут. А вот в java ты должен сначала на уровне базы данных создать таблицы. Причём для табличной части создать свою таблицу, потом описать модель данных на бэке. После потрудиться над тем, как это всё приедет на фронт. На фронте сверстать страницу, разобраться, какими компонентами всё это отобразить, разобраться, например, как же тут сделать подписки на события. Фреймворк, на котором велась разработка, конечно, спасал. Отличие от 1С в том, что 1С заточен на бизнес специфику. Фреймворки на java решают задачи намного более широкие и как следствие не имеют такой удобной заточки под бизнес приложения.
2. Специализация в разработке. Ввиду такой вариативности уже тогда было деление на бэк, фронт, архитекторов, дизайнеров, бизнес аналитиков и тестировщиков. Каждый хорошо разбирался в своей части и немного знал про соседа. В 1С на тот момент один человек – это человек-оркестр. Ввиду того, что фреймворк 1С забирал на себя большое количество задач, разработчик был освобождён от определённых технических решений, работал с абстракциями на уровне конфигуратора, не задумывался, как это реализовано внутри.
3. Разработчик оторван от предметной области. Разработчик в 1С изначально рассуждает бизнес категориями типа «справочник», «документ» и может общаться с представителем заказчика на его языке, в его терминах. На тот момент разработчик java решал настолько разные задачи, что у него не было заточки, практики в конкретной предметной области. Поэтому между таким программистом и представителем бизнеса всегда должен был быть «интерфейс» в виде бизнес аналитика. Иначе просто не взлетит, круглое в квадратное не влезет.
Первое знакомство с Git
Увидев Git, сразу не смог понять, что это вообще такое. Какие такие ветки? Какое слияние, это вообще, что? Документация была на английском, на русском она была скудновата. Постоянно приходилось работать с переводчиком. Когда появлялся конфликт слияния, образовывалась катастрофа. Как это всё исправить? Только в примерах, на практике, несколько раз сломав приложение, начал понимать логику. В 1С ты работаешь с конфликтами, как правило, только при обновлении типового релиза. В обычной работе вопросы отсутствия конфликтов слияния решаются за счёт монопольной блокировки объекта. То есть, конфликтов нет. Цена за это: другой разработчик ждёт, пока ты отпустишь объект.
Значительно позже, когда появилась EDT и я начал обучать этому инструменту программистов 1С, увидел у них такие же квадратные глаза. Но было понятно, что на практике понимание у них появится. Для упрощения создаётся документация по работе с типовыми ошибками, например, как работать с конфликтами слияния и как их можно избежать. Эти ошибки создаются специально, и на берегу в процессе обучения обкатывается их решение.
Набор команды
Подучив немного java, вышел на рынок в поиске программистов. Агрегаторы, типа hh.ru, результатов не дали. Странно, конечно. Начал искать другие варианты. Потратил примерно месяц. В итоге сработал следующий вариант. Приезжал в ВУЗ, общался с зав. кафедрами, после вывешивалось объявление о работе на доске, рядом с расписанием студентов. Конечно, на это соглашались не все, но нашлись те, кто согласился.
Оказалось, что уже со 2-го курса большинство студентов технических ВУЗов так или иначе уже трудятся. А после окончания ВУЗа это уже готовый специалист, и на рынке труда он нарасхват.
В основном с таких объявлений я и набрал сотрудников.
Первый опыт взаимодействия с удаленным разработчиком
Мне периодически везёт с сотрудниками. Это был как раз такой случай. В команду попал сильный разработчик, можно сказать, матёрый. У него было несколько отличительных особенностей. Во-первых, он писал в четыре раза быстрее, чем другие. Разница просто колоссальная. Сначала поверить не мог, как так. Он показал на практике, при мне, как это делает. Рассказал, как думает, показал, как рассуждает. Красавчик. Во-вторых, он критически подходил к постановке задачи, мог предложить свое решение и обосновать его, а иногда и сам мог сформулировать техническое задачи. И в-третьих, с самого начала он попросил полностью удаленный формат работы. У меня такого опыта вообще не было. Договорились, что начнёт он в офисе, а после, если всё срастётся, перейдёт на удаленный формат. В итоге в офис он приезжал в лучшем случае раз в месяц, когда мы собирались с нашей группой разработки в соседнем кафе попить чай-кофе, съесть что-нибудь сладкое, обсудить все накопившиеся вопросы в спокойной, неформальной обстановке.
Позже, ещё до пандемии, у меня будет несколько полностью удалённых групп разработки. Практика покажет, что это живой стандарт, он работает. И соглашался я на такой формат без опаски, потому что опыт в проекте по разработке корпоративной информационной системы на java был успешным.
1С + java
Был небольшой промежуток времени, когда под моим управлением было две команды разработки. На 1С и на java. Команды были небольшими, и в каждой я выступал в роли лида. Накопив опыт в обоих стеках, мне было достаточно просто общаться с разработчиками. Пригодилась практика, приобретенная ранее. Важно отметить, что подходы всё же разные у этих стеков. Под общую гребенку всех не причесать. Нужно учитывать специфику не только технической части, но и понимать, что java разработчики рассуждают по-другому, оперируют другими понятиями. Вот когда разработчик поднимается с мидла до сеньора, накапливает опыт, вот тогда эти различия несколько нивелируются, сглаживаются.
Заключение
Мой вывод такой. Если есть возможность и желание прикоснуться к соседнему стеку разработки, то это нужно сделать. Опыт обогатится новыми знаниями, новыми подходами. Вы увидите, что можно делать по-другому. И сможете это применить на практике.
Успехов! ;)
