«Continuous API Management», Mehdi Medjaoui и др.

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

Примером ответа на этот вопрос может служить Amazon, который постулирует: «делать все API так, будто они публичные». Проблема в том, что это очень дорого. И я решил разобраться в вопросе более детально.

⭐️ О чём книга

Книга посвящена управлению (руководству) разработкой API. Под API авторы подразумевают не интерфейс взаимодействия, а сервисы, выполняющие полезные для клиентов функции. Основу книги составляют пять элементов управления: продуктовая перспектива, правильные команды, руководство, зрелость продукта и проектирование ландшафта.

В книге раскрываются следующие темы:
➡️В чём заключается управление разработкой API и его сложности?
➡️Как применять продуктовый подход в разработке API?
➡️Какие есть типы команд, участвующих в разработке API?
➡️Управление циклом разработки API
➡️Проектирование API-ландшафта в компании

⭐️ 3 идеи из книги

🟡Управлять нужно не только созданием самих API, но и методологиями их разработки, руководствами, практиками, подходами и каскадированием этого всего на организацию. Также необходимо управлять экосистемой API.

🟡Управление API в первую очередь должно быть направлено на улучшение качества решений и их имплементации. Это не про «заставить всех делать как надо», а про «научить людей принимать более качественные решения».

🟡Управление API – это постоянный процесс. Если делать его выборочно или время от времени, то оно, скорее, будет наносить вред. Принципы разработки API должны проникать в культуру, иначе получится «кто в лес, кто по дрова».

⭐️ Мои впечатления

Книга оказалась довольно интересной. Авторы топят за продуктовый подход в создании сервисов, что является здравой идеей – я видел слишком много «сервисов ради сервисов».

Авторы делают большой упор на принятие решений: разбирают централизованную и децентрализованную схемы, их преимущества и недостатки, а также рассматривают смешанный вариант в контексте управления API. Фактически, это самая важная часть книги, потому что она заставляет задуматься о том, кто и какую ответственность на себя должен брать.

Ещё мне зашёл фокус на удобстве API. Этим разработчики заморачиваются довольно редко, а зря. Авторы утверждают, что удобные API гораздо чаще становятся популярными. Тезис спорный – вряд ли кто-то будет пользоваться удобными и хорошо описанными, но бесполезными API. Но посыл про хороший DX я считаю очень важным, потому что средняя документация вызывает у меня страдания.

Из минусов – книга дико водянистая и изобилует самоповторами. Примерно половину текста можно убрать, не потеряв смысла.

Рекомендую к прочтению, особенно если у вас в управлении находится много микросервисов – лучше поймёте, как управлять их созданием и развитием.

Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.

А для тех, кто хочет читать с большей пользой, у меня есть статья с описанием моего процесса чтения и упражнениями.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog