[API] Приём для разработчиков API
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Контекст Системные 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.
===========
Источник:
habr.com
===========
Похожие новости:
- [Python, API] LongPoll в vk_api
- [Монетизация IT-систем, Agile, Развитие стартапа, Бизнес-модели, Будущее здесь] Нужна ли новая методология разработки?
- [Мессенджеры, Facebook API, Разработка под AR и VR, AR и VR] Facebook Messenger портировали на Oculus Quest
- [Open source, GTK+, C, Разработка под Linux] Выявляем опечатки в проекте GTK 4 с помощью PVS-Studio
- [Open source, Совершенный код, C, Разработка под Linux] Finding Typos in the GTK 4 Project by PVS-Studio
- [Open source, GTK+, C, Разработка под Linux] Finding Typos in the GTK 4 Project by PVS-Studio
- [Информационная безопасность, Google Chrome, API, Расширения для браузеров, Браузеры] В бета-версию Chrome 89 добавили функции доступа к аппаратному обеспечению. Их критикуют Apple и Mozilla
- [Программирование, Проектирование и рефакторинг, API, Google API] Проектирование API: почему для представления отношений в API лучше использовать ссылки, а не ключи (перевод)
- [Разработка веб-сайтов, PHP, Проектирование и рефакторинг, API] Хьюстон, у нас проблема с интерпретацией ошибок
- [.NET, Разработка игр, C#] Бэк-офис для игр или «результат борьбы с пенсионной скукой»
Теги для поиска: #_api, #_development, #_api, #_api
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:41
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Контекст Системные 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. =========== Источник: habr.com =========== Похожие новости:
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:41
Часовой пояс: UTC + 5