Как делать микросервисы единообразными, когда их много, а разрабы все разные? #
Проблема, с которой столкнулся наш отдел, заключалась в следующем. У нас было несколько десятков микросервисов, и их число продолжало расти. При этом, как это часто бывает, в Go разработку люди пришли из других языков и принесли с собой различные практики. Всё бы ничего, но когда один сервис написан так, как привыкли писать на PHP, другой вдохновлен Ruby, а третий и вовсе отдаёт плюсами, то становится жутко. С таким зоопарком подходов переключаться от сервиса к сервису очень сложно и трудозатратно, а главное, чревато большим количеством ошибок в разработке. Тут тебе и стабильность продукта страдать может и тайм ту маркет расти. Решением сперва стал шаблонный сервис, на который стали ориентироваться при создании новых сервисов и рефакторинге старых, а потом и cli-утилита, которая занималась кодогенерацией скелета проекта и основных его компонентов. Также общие элементы, как, например, клиент к бд или grpc dialer, были вынесены в отдельный репозиторий с целью переиспользования во всех сервисах. Польза такого подхода дала о себе знать. Создание новых сервисов и поддержка старых ускорились, а влияние человеческого фактора в рутинных операциях снизилось. Да и разрабы стали счастливее, потому что уже не нужно было писать однообразный код, а он сам генерился.
