Как помочь освоиться разработчику Directum RX

22 7

Как начинающему разработчику Directum RX быстрее освоиться в системе и влиться в процесс или сделать для разработчика переход с Directum 5 на Directum RX менее болезненным? В статье приведены общие рекомендации по взаимодействию внутри команды разработки и развитию софт-скиллов новых участников.

 

Адаптация в команде

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

 

Как не стать оператором кол-центра

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

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

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

 

Учить учиться

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

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

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

  • обсуждать вопросы и уточнения по ТЗ напрямую с аналитиком, учиться находить общий язык.
  • не изобретать велосипед, ориентироваться на реализацию в коробке. Привыкать задавать аналитику вопрос «было ли что-то похожее в коробке?», «покажите пример в проводнике».

 

Знакомство с ресурсами вендора

Не лишним будет вести внутри компании базу знаний с расположением полезных ресурсов:

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

 

Повышение качества разработки

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

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

 

Администрирование Directum RX

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

Мероприятия, которые помогут развиваться в администрировании:

  • работать с СУБД: изучать структуру хранения данных, писать SQL-запросы, анализировать статистику запросов;
  • использовать решение "Мониторинг системы Directum RX": комплексно наблюдать за системой, выявлять неоптимальную разработку и настраивать оповещения по выбранным параметрам;
  • анализировать лог-файлы на сервере: важно научиться определять, какой сервис отвечает за процесс в системе, где искать его логи, и как выделить самое важное из набора сообщений в файле;
  • конфигурировать настройки на сервере, например, настройка почты или внешней аутентификации.

 

P.S.

Теория тяжело воспринимается без практики. Проследив весь путь от написания неоптимальной разработки, публикации на стенд (локальный, потому что на другие стенды стараемся пресечь ее во время 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 - оформлять баги на справку/документацию. Ее вроде как очень оперативно правят.

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

Но в целом, гит почти все стерпит, от пары сотен доп файлов точно не пострадает.

Авторизуйтесь, чтобы написать комментарий