Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Что значит правильнее — стабильнее, отказоустойчивее, более легко понятнее — быстрый вход, быстровостанавливаемый в случае ошибки или краха, с правильными метриками и алертами на все.
Почему не нанять сразу крутых разработчиков:
Junior-разработчик — минусы:
Junior-разработчики — плюсы:
Из сего видно что минусов у них гораздо больше чем плюсов, так как же минусы превращаются в плюсы? Для начала предстоит немного попотеть самому и создать фундамент для этого:
Что в итоге это дает:
Главная идея данного поста, что при таком подходе ты вынужден строить фундамент для качественной работы сервисов.
Почему не нанять сразу крутых разработчиков:
- Дорого, сложно найти.
- Держать компетенцию желательно распределенно.
- Не всегда уживаются вместе в силу конкуренции, бывает.
- Завышенные требования
Junior-разработчик — минусы:
- Нет фундамента и знаний правильной разработки.
- Не проверяет за собой, спешат быстрее сказать “Я сделал”.
- Не знают маломальских регламентов.
- Тесты — знают что полезно, но никогда их не писали.
- Метрики — что черт возьми это такое.
- Легко хантятся на сторону.
Junior-разработчики — плюсы:
- Стоят копейки, легче найти
- Можно состряпать человека под команду.
Из сего видно что минусов у них гораздо больше чем плюсов, так как же минусы превращаются в плюсы? Для начала предстоит немного попотеть самому и создать фундамент для этого:
- Микросервисная среда, причем микросервисы должны быть максимально стандартизированы. О микросервисной архитектуры можно тут — и на русском. Микросрвис должен быть понятен даже маме разработчика, которая работает в библиотеке.
- Документирование всей системы (нет-нет это не та глупая бездумная документация которую никто не читает) это понятная схема причем если она будут интерактивной еще лучше. Если разработчик за 1 день не разобрался с вашим микросервисом, то у вас проблемы с документацией.
- Тесты-тесты-тесты. По моему мнению самый эффективный результат дают функциональные приемочные автотесты, а также тесты real-time по боевому окружению. Тесты должны писать совсем не разработчики софта — разработчики пишут тесты получаются де… мо.
- РЕГЛАМЕНТЫ — вот над чет стоит действительно поработать и следить за этим. Я считаю это наиболее весомым делом. Старт разработки, описание стандарта кодирования, описание для тестирования, тесты, сдача метрик и алертов, культура деплоймента, да даже регламент на попить чаю — все это должно занимать около 50% всего времени.
- Разработка с Junior-разработчиком строится исключительно по принципу — разработал, сдал тесты, метрики, алерты, документацию = сдал задачу.
Что в итоге это дает:
- В первую очередь ты всегда контролируешь процесс и никогда не отдаешь работу в которой плохо понимаешь.
- Если что-то сломалось ты всегда знаешь что, где и как это починить.
- У тебя в 2 раза больше людей (твоя гарантия MVP команды) за меньшие деньги.
- Бонусом ты получаешь самое ценное в разработки — актуальные метрики, алерты и тесты — ради этого все делалось.
Главная идея данного поста, что при таком подходе ты вынужден строить фундамент для качественной работы сервисов.
