Контекст
Системные API разрабатываются, в том числе и так, чтобы попытаться решить несовместимые задачи. Например, следующие задачи – предоставить возможность детального управления ресурсом системы, и в то же время, упростить работу с ресурсом для разработчика. Такие задачи/цели порождают, например, следующее системное противоречия – API должно быть минимальным для того, чтобы можно было им легко/безопасно/с минимальным количеством ошибок использоваться, и в то же время, API должно быть детальным для того, чтобы можно было использовать максимум возможностей для управления системными ресурсами.
Последнее противоречие в системном API может:
не разрешаться вообще (это происходит, например, если цель разработки в минимизации затрат ресурсов системы во время выполнения кода);
разрешаться частично (с помощью, например, несколько уровней API или предоставлением нескольких/ряда системных API адаптированных под свои подзадачи);
разрешаться с помощью развития API дополнительными адаптирующими библиотеками (например, адаптирующие под возможности более мощных языков).
С другой стороны при разработке ad hoc для конкретного(ых) проекта(ов) можно получить бонусы разработки с помощью адаптации системного(ых) API под нужны данного проекта и данной команды разработчиков.
Например, можно получить следующие преимущества:
выделение наиболее важной для данного проекта части API;
выделение нескольких уровней API (выделение нескольких уровней детализации API) с точки зрения данного проекта (разработчик в большинстве случаев может использовать простейший уровень API и только в отдельных случаях использовать более сложные и более детальные глубокие уровни API);
интеграция системного API с существующей инфраструктурой проекта;
сокрытие части действий с системным API от разработчиков данного проекта, за счёт того, что мы знаем для данного проекта корректное поведение по умолчанию с системным API;
за счёт реализации по умолчанию некоторых стандартных операций, которые единообразны для данного проекта;
использование преимуществ инфраструктуры (языков, других библиотек, средств интеграции и так далее) данного проекта для развития системного API с целью улучшения качества использования API разработчиками проекта;
и так далее.
Прием
Так как одной из наиболее важных целей адаптации системного API и создания внутреннего API для конкретного проекта является повышение качества/повышение скорости/оптимизации уровня вхождения разработки, то предлагается следующее.
На этапе проектирования API создавать код и примеры использования будущего API и начинать с проектирования использования будущего внутреннего API.
Это означает, пробовать писать работающий код заглушек API, который можно скомпилировать и выполнить для разработки интерфейса использования API. Пробовать разные варианты того, как можно использовать системный API в рамках вашей адаптации для вашего проекта для ваших разработчиков. Пробовать проводить code review примеров использования будущего внутреннего API. Пробовать выяснять возможные точки развития вашего внутреннего API, осознавать то, как воспринимается внутреннее API вашими разработчиками, оценивать удобство использования внутреннего API для ваших разработчиков.
Важно, чтобы это был хоть и код заглушек, но вполне компилируемый и вполне выполняемый код. Код, который можно рассматривать на code review. Чтобы можно было просить разработчиков попробовать использовать ваше внутреннее API, ещё на стадиях проектирования API.
lair
Ммм, а если в этот код вставлять проверки на то, что API ведет себя как ожидается — то это ж сразу тесты получатся! Какая прекрасная новая идея!
klizardin Автор
Да, TDD изобретено. Только тестируем юзабилити API на разработчиках
klizardin Автор
(Если без иронии и серьезно.) Да, идея совершенно не новая. Да, близка по духу TDD. Но акцент в приёме на раннем тестирование нового API будущими пользователями API (разработчиками). Проведение тестов использования API, проведение code review попыток использовать макета API разработчиками.
Есть ирония… или какие возникают вопросы?
lair
Да какие тут вопросы, вы описываете обычный цикл разработки ПО, где пользователями выступают разработчики.
klizardin Автор
Да, пользователи API — это разработчики.
klizardin Автор
Да, описываю отношение к разработке внутренних API
klizardin Автор
В процессе данного предлагаемого тестирования макета API, как понимаете, определяется степень легкости использования API данными разработчиками данной команды, а не корректность реализации и корректность функционирование API (чтобы делал TDD). Определается какие места/возможности API вызывают трудности у разработчика. Где разработчик (конкретной команды, конкретного уровня) допускает ошибки, допускает больше всего ошибок.
Это тестирование дизайна API, а не реализации API.
Хотя да. Можно оформлять тестовые куски использования макета API в автоматизированные тесты и проверять насколько точно разработчик решил задачу по использованию макета API. Косвенно опередлять то, насколько разработчик понимает предлагаемое API.
Вы правы можно использовать автоматизированные тесты.
Правда, есть и такой инструмент, как интервью разработчика. В некоторых случаях интервью будет более дешевой альтернативой получения адекватной обратной связи по дизайну API, нежели автоматизированные тесты для которых первоначально нужно определить метрики.
lair
Я боюсь, у вас достаточно узкое понимание TDD. Одна из его задач как раз в том, чтобы помочь разработчику выработать удобный API через использование этого самого API.
klizardin Автор
Спасибо, поищу инфу по такому использованию TDD. Если можете подсказать ссылки, то буду рад. Так же это может помочь другим читателям. Спасибо
lair
"When we write a test, we imagine the perfect interface for our operation. We are telling ourselves a story about how the operation will look from the outside. Our story won't always come true, but it's better to start from the best-possible application program interface (API) and work backward than to make things complicated, ugly, and “realistic” from the get-go."
Kent Beck, "Test Driven Development: By Example" (Addison-Wesley Professional, 2002), Chapter 1.
klizardin Автор
И ещё пояснение.
В приёме важен акцент на следующем процессе.
Разработчик API (используя TDD или иные методы) делает предположение об юзабилити внутренего API. Выдвигает гипотезу (разрабатывает макет API). А далее тестирует эту гипотезу. Используя макет API, просит реализовать разработчиков код, который использует гипотезу API. Далее разработчик API оценивает свою гипотезу. Вносит доработки в гипотезу и тестирует вновь.
Альтернативно, группа разработчиков могла бы формулировать свои собственные гипотезы по необходимому им API.
Вопрос в управлением разработки API. И ведение гипотез к формированию конечного внутреннего API.
lair
Это, повторюсь, типовой процесс разработки программного продукта, где продуктом выступает внутреннее API, а его аудиторией — разработчики, которые будут пользоваться этим API.
klizardin Автор
Отличный пример утверждения Шрёдингера. Который раскрывается вопросом: типовой процесс разработки внутренних библиотек для внутренних разработчиков каких фирм/компаний? (Этот вопрос является мотивацией написания поста.)
lair
Не для "каких фирм/компаний", а для индустрии. В индустрии есть такой процесс.
klizardin Автор
Летают на самолетах, а не на авиаиндустрии.
Вы правомерно, указываете, что данные процессы существуют в индустрии, вы правомерно указываете, что данные процессы вытекают «из математических аксиом». Но смещаете фокус с выделенного в статье предложения для конкретной команды поити по пути фокусирования на потребностях конкретной команды.
lair
Я? Вы точно меня ни с кем не путаете?
Я смещаю фокус с предложения "давайте использовать для АПИ вот такой подход" на предложение "давайте трактовать АПИ как продукт, и использовать для него тот же подход, что для продукта".
klizardin Автор
Для кого лучший? Предложение/приём служит для того, чтобы работать с уточнением ответа на этот вопрос.
lair
Для пользователей API.
klizardin Автор
Да, создатель API создает API для пользователей API. Но в цитате это не прописано прямым текстом. Создатель API может полагать, что его видение API и есть лучшее видение API. Я обратил ваше внимание на то, что в цитате не определены заинтерсованные лица. И не определено разрешение конфликта «лучшее API». Возможно, вы к радости читателей сможете привес ти цитату, где опеределены криетрии «лучшего API».
В данном случае подразумевается, что внутренее API созадет не команда разработчиков, которое использует это API. В частности, из-за, например, недостаточной квалификации, а выделенная команда.
Поэтому в данном случае возникает конфликт интересов того, что понимать под понятием «лучшая реализация API».
Возможно, я давно не перечитавал классиков TDD и не могу сам найти цитату по разрешению именно данного конфликта — взгляд команды разработки внутреннего API на юзабилити API и взгляд команды разработчиков, которые используют внутреннее API.
lair
Этому вопросу посвящена другая литература — в частности, та, в которой обсуждается управление требованиями для ПО.
В общем случае, чаще всего ПО создают не те люди, которые его используют. Разрешению этого конфликта посвящено множество литературы.
BugM
Не дай бог так жить.
Разные команды с разной зоной ответсвенности это нормально. А вот эти лучше поэтому они делают это, а вы второго сорта поэтому делаете вот то нельзя.
В обоих командах и создающих АПИ и использующих его должны быть свои сеньеры. Которые знают, умеют и могут. Они договорятся между собой как лучше. И это на самом деле будет лучше.
klizardin Автор
Вы предлагаете, что имеют право голоса только тимлиды/синьеры?
В предложение/приёме не оговорён круг лиц, которые исследуют юзабилити API. Возможно, это часть разработчиков из команды, которая будет использовать разрабатываемое API. По крайней мере, исследование не может учитывать разработчиков, которые придут на проект после внедрения разработанного API.
Поясню, когда возможен данный случай:
Допустим, команда, которая будет использовать API не является высоко-компетентной в разработке низкоуровневой работы с устройствами. В то же время, команда, разрабатывающая API и выделяется, так как обладает компетенциями по работе с некоторым набором низкоуровневых API.
Команда разработки API предоставляет высокоуровневый механизм работы с обощенными устройствами.
Или же выделенная команда разрабатывает используя другие языки программирования.
Для меньшей стигматизации можно переписать:
В частности, из-за, например, различий в специализации в разработке выделенной команды и основной команды.
Какие у вас возникают вопросы?
BugM
В такой формулировке никаких. Проблема только в начальной формулировке.