Создание микросервисов

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

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

Но есть и еще одна модель, которая может неплохо работать в наших интересах.

Семейственный открытый код

А что, если мы приложили максимум усилий, но так и не смогли найти способа, исключающего применение нескольких общих сервисов? В таком случае вполне определенный смысл может иметь правильное внедрение модели семейственного открытого кода.

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

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

Роль кураторов

Нам хочется, чтобы наши сервисы были практичными. Хочется, чтобы код был высокого качества и сам сервис проявлял некую последовательность при сборе всего в общее целое. Мы также хотим убедиться в том, что изменения, вносимые сейчас, не затруднят внесение намечаемых на будущее изменений сверх допустимого. Это означает, что внутри нашей организации необходимо применять те же схемы, которые используются в обычном открытом коде, то есть выделить группу надежных исполнителей (основную команду) и ненадежных исполнителей (людей, не входящих в команду предлагающих изменения).

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

Хорошие контролеры проделывают в связи с этим большой объем работы, общаясь непосредственно с теми, кто вносит предложения, и поощряя их хорошие поступки. Плохие контролеры могут воспользоваться своим положением для демонстрации власти над другими или ведения мировоззренческих сражений вокруг произвольных технических решений. Будучи свидетелем обеих форм поведения, хочу сказать только одно: в любом случае на это тратится определенное время. Когда кураторы позволяют ненадежным исполнителям отправлять свои изменения в ваш исходный код, вам нужно решить, стоит ли беспокоиться об издержках на использование контролера — о том, может ли основная команда заняться чем-нибудь более полезным, чем проверка исправлений или изменений.

Зрелость

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

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

Инструментарий