Возвращаемся к техническим книгам. Мне как руководителю всегда было интересно: как управлять разработкой продуктов в больших организациях? Как избежать дублирования и делать действительно качественные сервисы?
Примером ответа на этот вопрос может служить Amazon, который постулирует: «делать все API так, будто они публичные». Проблема в том, что это очень дорого. И я решил разобраться в вопросе более детально.
О чём книга
Книга посвящена управлению (руководству) разработкой API. Под API авторы подразумевают не интерфейс взаимодействия, а сервисы, выполняющие полезные для клиентов функции. Основу книги составляют пять элементов управления: продуктовая перспектива, правильные команды, руководство, зрелость продукта и проектирование ландшафта.
В книге раскрываются следующие темы:
- в чём заключается управление разработкой API и его сложности;
- как применять продуктовый подход в разработке API;
- какие есть типы команд, участвующих в разработке API;
- управление циклом разработки API;
- проектирование API-ландшафта в компании.
Три идеи из книги
-
Управлять нужно не только созданием самих API, но и методологиями их разработки, руководствами, практиками, подходами и каскадированием этого всего на организацию. Также необходимо управлять экосистемой API.
-
Управление API в первую очередь должно быть направлено на улучшение качества решений и их имплементации. Это не про «заставить всех делать как надо», а про «научить людей принимать более качественные решения».
-
Управление API – это постоянный процесс. Если делать его выборочно или время от времени, то оно, скорее, будет наносить вред. Принципы разработки API должны проникать в культуру, иначе получится «кто в лес, кто по дрова».
Мои впечатления
Книга оказалась довольно интересной. Авторы топят за продуктовый подход в создании сервисов, что является здравой идеей – я видел слишком много «сервисов ради сервисов».
Авторы делают большой упор на принятие решений: разбирают централизованную и децентрализованную схемы, их преимущества и недостатки, а также рассматривают смешанный вариант в контексте управления API. Фактически, это самая важная часть книги, потому что она заставляет задуматься о том, кто и какую ответственность на себя должен брать.
Ещё мне зашёл фокус на удобстве API. Этим разработчики заморачиваются довольно редко, а зря. Авторы утверждают, что удобные API гораздо чаще становятся популярными. Тезис спорный – вряд ли кто-то будет пользоваться удобными и хорошо описанными, но бесполезными API. Но посыл про хороший DX я считаю очень важным, потому что средняя документация вызывает у меня страдания.
Из минусов – книга дико водянистая и изобилует самоповторами. Примерно половину текста можно убрать, не потеряв смысла.
Рекомендую к прочтению, особенно если у вас в управлении находится много микросервисов – лучше поймёте, как управлять их созданием и развитием.