Как Junior-разработчики делают мой проект правильнее

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

В закладки

Почему не нанять сразу крутых разработчиков:

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

Junior-разработчик - минусы:

  • Нет фундамента и знаний правильной разработки.
  • Не проверяет за собой, спешат быстрее сказать “Я сделал”.
  • Не знают маломальских регламентов.
  • Тесты - знают что полезно, но никогда их не писали.
  • Метрики - что черт возьми это такое.
  • Легко хантятся на сторону.

Junior-разработчики - плюсы:

  • Стоят копейки, легче найти
  • Можно состряпать человека под команду.

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

  • Микросервисная среда, причем микросервисы должны быть максимально стандартизированы. О микросервисной архитектуры можно тут - https://www.atlassian.com/ru/continuous-delivery/microservices/building-microservices и https://habr.com/ru/company/flant/blog/347518/ на русском. Микросрвис должен быть понятен даже маме разработчика, которая работает в библиотеке.
  • Документирование всей системы (нет-нет это не та глупая бездумная документация которую никто не читает) это понятная схема причем если она будут интерактивной еще лучше. Если разработчик за 1 день не разобрался с вашим микросервисом, то у вас проблемы с документацией.
  • Тесты-тесты-тесты. По моему мнению самый эффективный результат дают функциональные приемочные автотесты, а также тесты real-time по боевому окружению. Тесты должны писать совсем не разработчики софта - разработчики пишут тесты получаются де...мо.
  • РЕГЛАМЕНТЫ - вот над чет стоит действительно поработать и следить за этим. Я считаю это наиболее весомым делом. Старт разработки, описание стандарта кодирования, описание для тестирования, тесты, сдача метрик и алертов, культура деплоймента, да даже регламент на попить чаю - все это должно занимать около 50% всего времени.
  • Разработка с Junior-разработчиком строится исключительно по принципу - сдал тесты, метрики, алерты, документацию = сдал задачу.

Что в итоге это дает:

  • В первую очередь ты всегда контролируешь процесс и никогда не отдаешь работу в которой плохо понимаешь.
  • Если что-то сломалось ты всегда знаешь что, где и как это починить.
  • У тебя в 2 раза больше людей (твоя гарантия MVP команды) за меньшие деньги.
  • Бонусом ты получаешь самое ценное в разработки - актуальные метрики, алерты и тесты - ради этого все делалось.

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

{ "author_name": "Ринат Програмский", "author_type": "self", "tags": [], "comments": 0, "likes": 5, "favorites": 14, "is_advertisement": false, "subsite_label": "dev", "id": 76257, "is_wide": true, "is_ugc": true, "date": "Mon, 22 Jul 2019 12:27:01 +0300", "is_special": false }
0
Комментариев нет
Популярные
По порядку

Комментарии

null