оверхед - слово конечно старшное, но в ентерпрайзе не сильно существенное. А вот что может быть существенно, так это легкость тестирования.
имхо есть 2 путя тут: 1. когда в типе акцент идет на сами хранящиеся в нем данные, тогда расширяющая его (тип) функциональность в интерфейсе не нуждается, т.к. эта функциональность скорее всего будет очень сильно переплетена с самими данными.
2. использование интерфейсов в сервисных (стейтлесс) типах (что в целом является большинством кода который мы пишем), где по возможности имхо лучше использовать интерфейсы по максимуму: а. интерфейсы на стороне клиента что бы ограничить набор нужного для работы апи и упростить тестирование СЕБЕ. б. интерфейсы на стороне реализации, что бы по возможности под них сразу положить рядом моки и упростить тестирование КОМУ-ТО.
Можно пойти прото-путем: grpc-gateway. Да grpc. Но, по факту можно просто не запускать сам grpc сервер, а запускать gateway. Тут вам и адекватная кодогенерация, и генерация опенапи спеки.
Вляпался давече в стартап, ныне присмерти коий. Собрал муж отряд бравых разработчиков, закаленных легаси, да облаченных в шрамы энтерпрайза. Правозгласил сий муж себя СТО. Поклонились и согласились тогда все. Принялся тогда муж сий шкуру нереализованного стартапа делить: как водится в сказаниях — бравым молодцам отдал он по 3%, а себе взял гораздо больше. И тут смолчали все. Шло время. Гитхаб рос, да вместе с ним и вопросы у бравых разработчиков к мужу, СТО именуемому. Ибо лик его и присутствие его ощущалось не дальше чем на 10 минут в день, на вече (дейликом именуемым). И спросили бравые разработчики у березы, не соромно ли СТО такую долю иметь, за столь «непосильную» ношу, что он на себя взвалил. И были посланы с напутствием. И послан сам был муж. И шкура поделена не была.
В случае продуктовой компании мотивируют опционами. На аутсорсе попу рвут только джуны и сектанты. Если производительность всегда была неуд, то тут вряд ли что-то поможет. Разве что выделять мит раз за спринт и при всей команде обсуждать велосити каждого. Если за 2-3 спринта ничего не меняется — предупреждение, если после предупреждения то ж самое — досвидули. Если велосити было норм но упало, возможно стоит сменить команду/проект, или отправить в отпуск
оверхед - слово конечно старшное, но в ентерпрайзе не сильно существенное. А вот что может быть существенно, так это легкость тестирования.
имхо есть 2 путя тут:
1. когда в типе акцент идет на сами хранящиеся в нем данные, тогда расширяющая его (тип) функциональность в интерфейсе не нуждается, т.к. эта функциональность скорее всего будет очень сильно переплетена с самими данными.
2. использование интерфейсов в сервисных (стейтлесс) типах (что в целом является большинством кода который мы пишем), где по возможности имхо лучше использовать интерфейсы по максимуму:
а. интерфейсы на стороне клиента что бы ограничить набор нужного для работы апи и упростить тестирование СЕБЕ.
б. интерфейсы на стороне реализации, что бы по возможности под них сразу положить рядом моки и упростить тестирование КОМУ-ТО.