А сколько у вас в компании во внутренних системах используется наименований одного и того же поля в API? А сколько способов назвать поле, которое перечисляет список id?

Я часто сталкиваюсь с тем, что при проектировании и разработке HTTP REST API команды (чаще неосознанно) собирают целый семантический и лексический зоопарк наименований. Потом бывает сложно разобраться, что нужно записать в определенное поле, или какое название поля выбрать для перечисления списка ID из уже существующих.

Поэтому я однажды собрала для себя и коллег гайд–чек-лист под названием “Приглаживаем названия в API” и теперь публикую его для широкой аудитории. Уверена, что он кому-то да пригодится.

Я думаю, что вы не раз уже гуглили, заглядывали в статьи, манифесты IT-гигантов о лучших практиках проектирования API. Я тоже.

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

Я работаю тимлидом направления системного анализа в X5Tech и за все время развития карьеры сталкивалась с большим количеством кейсов проектирования Web систем. IT продукты в большинстве очень динамичны: постоянно изменяются требования, появляются новые, итеративно улучшается пользовательский опыт (по принципу 20% усилий на 80% результата, а остальное доделаем потом).

Часто при проектировании мне помогала следующая идея: было бы здорово проектировать контракт так, чтобы при малейшем изменении/добавлении бизнес-правил его не приходилось сильно трансформировать, так как API является стыковочным звеном между разными слоями приложения. По ходу повествования я приведу пару примеров, чтобы проиллюстрировать такие изменения.

В этой статье предлагаю спроектировать контракт по шагам, и на каждом из них я расскажу про общие рекомендации из копилочки “Полезное”, а также про личные правила и практики, полученные долгим опытом работы над постоянно меняющимися ИТ-продуктами, которые помогут для “дальновидного” проектирования GET REST API.

Всем привет! Меня зовут Анна Мозер, я работаю тимлидом системных аналитиков в X5 Tech. Мне удалось поработать и в корпорации, и в стартапе, и в качестве фриланс Delivery Manager на этапе запуска стартап команды. 

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

Периодически мои друзья, знакомые, коллеги в кулуарах делятся тем, что процессы в их командах напоминают хаос. Они говорят: "Мы только и занимаемся тем, что тушим пожары" или "Я не знаю, чем буду заниматься на следующей неделе". И моё самое любимое: "Мы начали делать задачу, а на полпути потребности поменялись, и теперь нужно совсем другое. Но это же Agile…".

Хотя многие менеджеры объясняют это стремлением к гибкости и следованием Agile-философии, чаще всего такие признаки указывают на неправильное понимание и применение гибких методологий. Цель моей статьи – подсветить типичные ошибки менеджмента команды и рассказать об индикаторах того самого "недопонятого" Agile (я насчитала таких 10 штук).