Как начинающему разработчику Directum RX быстрее освоиться в системе и влиться в процесс или сделать для разработчика переход с Directum 5 на Directum RX менее болезненным? В статье приведены общие рекомендации по взаимодействию внутри команды разработки и развитию софт-скиллов новых участников.
Чтобы команда разработки эффективно развивалась, тимлид и руководитель проекта должны уделять внимание адаптации новых участников. Одновременно важно и знакомить с внутренними процессами компании, и улучшать софт-скиллы разработчика. Не только обучаемый сотрудник нуждается в распределении своих ресурсов, чтобы поэтапно изучать материал, но и наставнику не помешают выработанные практики по обучению новых членов команды.
На своих первых проектах каждый разработчик перенимает опыт у старших коллег. Какие-то вопросы имеют краткий письменный ответ, но чаще объяснения требуют личного контакта или хотя бы обсуждения голосом.
Если курировать одновременно несколько новых участников команды, то более опытный разработчик рискует погрязнуть в бесконечных созвонах. Плюс, чтобы успеть выполнить свои основные обязанности, появляются переработки, а после них – привет, выгорание!
Чтобы вписать трудозатраты на консультации разработчиков в свой график, такие работы в первую очередь нужно систематизировать. Все стихийные созвоны переводить в регулярные встречи, а небольшие вопросы копить и обсуждать сразу несколько, не отвлекаясь на каждый по отдельности.
Привить новичку-разработчику самостоятельность и научить добывать информацию получится быстрее и комфортнее, если заложить для этого некоторую основу:
Если в компании с аналитиками взаимодействует не только тимплид или руководитель команды, но и сам разработчик, то ему нужно:
Не лишним будет вести внутри компании базу знаний с расположением полезных ресурсов:
Своевременное создание "каркаса" решения (модули, типы сущностей и события без реализации) в дальнейшем значительно уменьшит количество конфликтов при слиянии веток и сэкономит время на сборку пакета разработки. Если в команде еще и приняты договоренности о наименовании новых элементов в решении или их созданием занимается выделенный сотрудник, то приятным бонусом станет повышение читаемости исходного кода.
Помимо обязательного Code Review хорошей практикой будет участие неопытного разработчика в перекрестном рецензировании. Изучая код коллег, можно почерпнуть для себя интересные варианты реализации и привыкнуть к стилю оформления кода. Кроме того, участники команды будут лучше ориентироваться в решении проекта и иметь общее представление, какой модуль за что отвечает.
Часто на проектах роль системного инженера выполняет разработчик. Помимо навыков установки и обновления Directum RX, умение анализировать работоспособность и производительность системы положительно скажется на квалификации сотрудника.
Мероприятия, которые помогут развиваться в администрировании:
Теория тяжело воспринимается без практики. Проследив весь путь от написания неоптимальной разработки, публикации на стенд (локальный, потому что на другие стенды стараемся пресечь ее во время review) и анализа ошибки в логах, разработчик наглядно воспринимает причины и последствия. Методом проб и ошибок накапливается опыт. Среди задач наставника – показывать пример и знакомить с лучшими практиками.
А существуют ли какие рекомендации, как оптимально организовать тот же Git при коллективной разработке? Ведь в RX помимо кода и конфигурационные файлы есть, разные и много...
Владислав, уточните, о каких конфигурационных файлах идет речь, в которых разработчики могут пересекаться?
Алексей, в частности настройки интеграций: https://club.directum.ru/webhelp/directumrx/web/index.html?inst_config_integrationservice.htm
Не сомневаюсь что в реальном проекте их приходится мутузить не раз, пока всё заработает.
> Ведь в RX помимо кода и конфигурационные файлы есть, разные и много...
Разве много? вроде файл всегда один.
> Не сомневаюсь что в реальном проекте их приходится мутузить не раз, пока всё заработает.
Нужны примеры. Вот сколько работаю, никогда не нужно было конфиг файлы "мутузить", что бы локальная система разработчика заработала. БОлее, того, в 80% случаев настройки по умолчанию достаточно.
Андрей, config.yml, _ConfigSettings.xml. 100-80=20, и то эти 80 это оценочное суждение, может быть там и 40, но да ладно. 20% это 1/5 часть когда не хватало. А почему? И сколько в этих "20%" случаев когда например в инструкции не то написано?
Владислав, gitflow можно погуглить
Дмитрий, config.yml - да, _ConfigSettings.xml - это те, которые автогенерируемые? их то зачем менять, они после up команды перетрутся ведь. А на линуксе до него еще умудрится добраться нужно.
> И сколько в этих "20%" случаев когда например в инструкции не то написано?
Должно быть 0. Если не 0 - оформлять баги на справку/документацию. Ее вроде как очень оперативно правят.
Я еще могу понять хранение эталонных шаблонов конфигов для продуктивного/тестового стенда, когда это не один сервер и нужен контроль изменений.
Но в целом, гит почти все стерпит, от пары сотен доп файлов точно не пострадает.
Авторизуйтесь, чтобы написать комментарий