Лекция
Привет, Вы узнаете о том , что такое sdk, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое sdk, software development kit , настоятельно рекомендую прочитать все из категории Фреймворки. Famworks ( программная платформа).
SDK (от англ. software development kit) — набор средств разработки, позволяющий специалистам по программному обеспечению создавать приложения для определенного пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ.
Программист, как правило, получает SDK непосредственно от разработчика целевой технологии или системы. Часто SDK распространяется через Интернет. Многие SDK распространяются бесплатно, чтобы побудить разработчиков использовать данную технологию или платформу.
Поставщики SDK иногда подменяют слово «software» в словосочетании «software development kit» на более точное слово. Например, Microsoft и Apple предоставляют Driver Development Kit (DDK) для разработки драйверов устройств, PalmSource называет свой инструментарий для разработки PalmOS Development Kit (PDK), а Oracle — Java Development Kit (JDK).
Сегодня индустрия укрепилась во мнении, что SDK — это библиотека, встроенная в приложение, а API — это облачные сервисы, которые работают совместно с SDK или приложением.
Вы создаете что-либо с помощью SDK. Вы используете или потребляете что-либо с помощью API. Вы используете SDK для доступа к функционалу библиотеки, а API для управления им.
Ожидается, что SDK будет предлагать инструменты для программирования в отношении определенного системного ресурса или функции. Фреймворк не обязательно (хотя .NET предлагает целый набор инструментов, таких как компиляторы и т. д., Но они в любом случае обязательны для его работы).
Итак, вы можете разработать Framework, состоящий исключительно из библиотек, но если вы назовете его SDK, вы должны будете предложить что-то для поддержки разработки.
Библиотека:
Библиотека - это набор подпрограмм или классов, используемых для разработки программного обеспечения. Библиотеки содержат код и данные, которые предоставляют услуги независимым программам. Это позволяет разделять и изменять код и данные по модульному принципу.
Framework:
Программная структура в компьютерном программировании - это абстракция, в которой общий код, обеспечивающий общие функциональные возможности, может быть выборочно переопределен или специализирован с помощью пользовательского кода, обеспечивающего определенные функциональные возможности. Фреймворки похожи на программные библиотеки в том, что они представляют собой многократно используемые абстракции кода, заключенные в четко определенный API. Однако, в отличие от библиотек, общий поток управления программой диктуется не вызывающей стороной, а фреймворком. Эта инверсия управления - отличительная черта программных фреймворков.
SDK:
Комплект для разработки программного обеспечения (SDK или «devkit») обычно представляет собой набор инструментов разработки, который позволяет инженеру-программисту создавать приложения для определенного программного пакета, программной платформы, аппаратной платформы, компьютерной системы, игровой консоли, операционной системы и т. Д. Платформа. Это может быть что-то столь же простое, как интерфейс прикладного программирования в форме некоторых файлов для взаимодействия с определенным языком программирования или включать сложное оборудование для связи с определенной встроенной системой. Общие инструменты включают средства отладки и другие утилиты, часто представленные в среде IDE. SDK также часто включают образцы кода и вспомогательные технические примечания или другую вспомогательную документацию, чтобы помочь прояснить моменты из основного справочного материала.
Для этих терминов не может быть канонического определения, поскольку разные люди / компании используют эти термины по-разному, субъективно.
Библиотека . Коллекция классов / модулей / функций, по крайней мере, некоторые из которых являются общедоступными, расширяющими приложение.
Фреймворк. Набор классов / модулей / функций, которые позволяют создавать приложение путем расширения фреймворка. JEE является примером этого: ваш код находится под контролем фреймворка, в отличие от библиотеки.
API Интерфейс прикладного программирования - это библиотека, которая обеспечивает доступ к другому приложению или части оборудования.
SDK Комплект для разработки программного обеспечения - это набор инструментов (например, компиляторы, библиотеки, отладчики, IDE) для помощи в разработке приложений для некоторых API с использованием одного или нескольких языков.
Сказав все это, есть хорошо известные примеры, которые нарушают эти «правила», например, «.NET Framework», который является SDK согласно приведенным выше определениям.
Высокая скорость интеграции нового клиента — вашим клиентам нужно писать меньше кода.
Переиспользование кода — один и тот же код используется сразу в нескольких местах. Можно сказать, что это дублирование предыдущего пункта, но речь идет о том, что логика работы везде одинокава, из чего следует
Предсказуемость поведения — использование одних и тех же библиотек приводит поведение систем к определенному стандарту, что сильно облегчает поиск и устранение ошибок и уязвимостей.
Качество кода — много где любят экономить на тестировании (жалко бюджета, горят сроки и прочие причины). Об этом говорит сайт https://intellect.icu . Понятно, что в реальном мире покрыть тестами все участки проекта это учень трудоемкая задача. Но качественно протестировать все модули SDK, а затем использовать их — это путь повышения процента покрытия тестами, что приведет вас к снижению количества ошибок.
Документация — тот же сценарий, что и с тестами. Покрыть документацией весь проект достаточно проблематично. Переиспользование модулей SDK повышает процент покрытия документацией, что снижает порог вхождения новых сотрудников в проект и вообще помогает по жизни.
Все преимущества, по сути, это следствия самого главного — мы очень качественно пишем код один раз, а затем его переиспользуем.
Высокие требования к качеству кода SDK — следствие главного преимущества. Ошибка в SDK породит ошибки во всех системах, его использующих.
Установка ограничений — SDK — это набор библиотек для реализации стандартных сценариев. Иногда разработчики SDK полагают, что кроме реализации одного из предусмотренных сценариев клиенту ничего не потребуется, что клиенту проще сделать все с нуля самостоятельно, чем строить пьедестал из костылей для SDK.
Dependency hell и обновления — при расширении функционала (например, кастомизации решения под конкретного клиента), вы выпустите новую версию библиотеки. Но существуют зависимости, различные наборы версий библиотек у разных клиентов, и нужно очень тщательно следить за обратной совместимостью или строгим версионированием.
У вас есть несколько стандартных сценариев, которые реализуются заново из раза в раз — собственно, наш случай.
Внутренние разработки — в разных проектах вы используете системы логирования, конфигурирования систем, работу с HttpRequest, БД, файлами? Выработайте внутренний SDK — набор библиотек для внутреннего использования. Вы в любой момент можете расширить функционал SDK, но скорость разработки новых проектов, процент покрытия тестами и документацией вырастет, а порог вхождения новых разработчиков снизится.
Сценарии использования не определены или постоянно меняются — оставьте реализацию кастомных решений клиентам и помогите им. Не надо городить вундервафлю, которая будет только мешать. Очень актуально для молодых компаний и стартапов.
Вы не умеете делать качественно — у меня для вас плохая новость: пора учиться. Но отдавать кривое решение клиенту это очень, очень неправильно. Клиентов надо уважать, в конце концов.
Итак, мы определились, что такое SDK, с его преимуществами и недостатками и когда он нам нужен. Если после этого вы поняли, что SDK действительно нужен — приглашаю вас встать на "путь SDK" и разобраться, а каким он должен быть и как его, черт подери, делать?
Представим все возможные сценарии использования SDK (вы же уже определились, зачем он вам нужен, правда?) и сделаем по библиотеке на сценарий. Чем не выход? Но это плохой подход, и так мы делать не будем. А будем так:
Например, с учетом специфики задачи, нам необходимо, чтобы вся логика задавалась из конфигов. Реализуем модуль работы с конфигами (чтения, записи, обновления, валидации и обработки конфигураций) и будем использовать его во всех остальных модулях.
А для реализации стандартных сценариев мы действительно сделаем модули — этакие "управляющие" модули, каждый из которых реализуют один конкретный сценарий, используя другие модули того же SDK. Таким образом для реализации стандартных сценариев клиент должен лишь подключить управляющий модуль сценария (а он сам подтянет все зависимости), а для реализации нестандартных — используем базовые модули, так же переиспользуя код.
Именно этим обусловлено то, что SDK не должен быть одной библиотекой (хотя очень хочется, понимаю. Ведь когда весь SDK в одной библиотеке, можно забыть о зависимостях и всем, что с ними связано), а быть комплектом библиотек. Дополнительным плюсом данного подхода будет уменьшение "веса" программы клиента — он будет тянуть тяжеловесный SDK, а подтянет только необходимые модули.
Но не стоить плодить модули как попало, ведь чем больше модулей, тем больше головной боли от их зависимостей! Т.е. важно правильно разбить логику на модули, соблюдая баланс между решением "все в одном" и "на каждую функцию свой модуль".
Предоставьте клиенту различные интерфейсы для работы с вашей библиотекой. Приведу пример:
Если предоставить только синхронную версию, то при реализации асинхронного приложения клиент вынужден будет делать асинхронные обертки вашего синхронного метода. Если предоставить только асинхронную версию — ситуация похожа. Дайте клиенту и то и другое и он скажет вам спасибо.
Приятным плюсом будут дженерики. Например, у нас есть класс для работы с конфигурациями, реализующий методы упаковки конфига в строку, загрузки конфига из файла и т.д. Конфигурация конкретного модуля будет наследоваться от нашего базового класса, но для работы с новым классом нам необходимо также предоставить методы распаковки.
Таким образом мы предоставили клиенту аж три реализации, которые он может использовать. Дженерики очень удобны, но при работе с динамическими типами их можно вызывать только через рефлексию, что накладно. Общий принцип универсальности, надеюсь, понятен.
Что самое трудное в работе программиста? Выдумывать имена для переменных.
И тем не менее… Правильное именование модулей, классов, свойств и методов сильно помогут тем, кто будут с вашим SDK работать. Пример, не требующих комментариев:
Kinect 2.0 SDK example
var skeletons = new Skeleton[0];
using (var skeletonFrame = e.OpenSkeletonFrame())
{
if (skeletonFrame != null)
{
skeletons = new Skeleton[skeletonFrame.SkeletonArrayLength];
skeletonFrame.CopySkeletonDataTo(skeletons);
}
}
if (skeletons.Length == 0) { return; }
var skel = skeletons.FirstOrDefault(x => x.TrackingState == SkeletonTrackingState.Tracked);
if (skel == null) { return; }
var rightHand = skel.Joints[JointType.WristRight];
XValueRight.Text = rightHand.Position.X.ToString(CultureInfo.InvariantCulture);
YValueRight.Text = rightHand.Position.Y.ToString(CultureInfo.InvariantCulture);
ZValueRight.Text = rightHand.Position.Z.ToString(CultureInfo.InvariantCulture);
Все ясно из названий классов и методов. А если есть автодополнение кода в вашей IDE, то зачастую можно и в документацию не заглядывать, если и так все понятно.
Но даже если у вас очень красиво и актуально названы все модули, классы, методы и свойства, документацию все равно необходимо написать. Во-первых, это очень сильно сбережет вам нервы (количество вопросов клиентов уменьшается на порядок. Все есть в документации), а во-вторых, всегда понятно, почему вы сделали так, а не иначе.
Документация, в SDK, как правило, проста и лаконична. Она обычно делится на две части: Tutorial — пошаговый курс в стиле “Построим город за 10 минут” и раздел Reference — справочник по всему, что можно сделать с помощью данного SDK.
Мы выбрали самый простой путь — summary + articles. Мы добавляем Xml атрибуты для методов и классов, которые светятся в intellisense как подсказки. Используя Docfx мы строим документацию по этим атрибутам и получаем подробную и удобную документацию, которую дополняет статьями, описывающими сценарии использования и примеры.
Что можно сказать про тестирование в рамках обсуждения SDK… Must have! Лучшим решением будет TDD (несмотря на то, что я негативно отношусь к данному подходу, в данном случае я решил использовать именно его). Да, долго. Да, нудно. Но зато в будущем вы не повеситесь от постоянных падений SDK на стороне и следствий этого падения.
Основной сок ситуации заключается в том, что отдавая SDK клиенту вы теряете контроль: вы не можете быстро пофиксить ошибку, сложно эту самую ошибку найти, да и выглядеть в такой ситуации вы будете достаточно глупо. Поэтому — тестируйте. Тестируйте лучше. И еще раз. И, на всякий случай, протестируйте ваши тесты. И тесты тестов. Так, что-то я увлекся, но важность тестирования SDK, надеюсь, понятна.
Поскольку вы отдаете SDK сторонней компании, в следствие чего теряете контроль над ситуацией, в случае ошибки (на этапе тестирования вы все-так решили "и так сойдет", да?) вас ждет достаточно долгий и болезненный процесс поиск этой самой ошибки. Именно тут вам на помощь придут логи.
Логируйте все, абсолютно все, а в случае возникновения ошибки запросите у вашего клиента логи. Таким образом вы сэкономите много времени и сможете не потярять лицо перед клиентом.
Долго размышляя на тему ошибок я пришел к интересному выводу — ни один метод в вашем SDK не должен отдавать ошибку, не описанную в документации. Согласитесь, очень неприятно, когда вы подключаете стороннюю библиотеку для работы с HttpRequest, а она вываливает на вас какой-нибудь NullPointerException и StackTrace, который уводит в недра библиотеки. И вам приходиться погружаться в эти самые "недра", пытаясь понять, насколько глубока кроличья нора, и в чем, собственно, проблема.
Поэтому я предлагаю следующее решение — декларируйте закрытый список возможных исключений и документируйте их. Но, т.к. нельзя быть увереннным, что вы предусмотрели все, оберните метод в try-catch, а пойманную ошибку — в задекларируему. Например, ConfigurationException, который будет содержать InnerException — пойманную ошибку. Это позволит стороннему разработчику поймать все возможные ошибки, но в случае чего быстро разобраться в чем дело.
Во избежание проблем в будущем крайне рекомендую использовать строгое версионирование. Выберете подходящую вам систему построения версий и используйте ее. Но если новая версия библиотеки не имеет обратной совместимости — это необходимо указать. Как это разруливать — думать вам. Но подумать об этом точно стоит.
Необходимость актуальности документации и версий порождают требование к корректности деплоя. В своем решении мы используем следующее решение (костыли, но работают).
Когда надо выпустить нвый релиз, разработчик дергает bat'ник с указанием номера релиза, а затем батник:
На выходе получаем обновленную версию сайта с документацией, откуда можно скачать архив с последней версией SDK.
В планах на будущее — упаковка всего в Nuget пакеты и публикация в локальный Nuget репозиторий.
Рекоммендую обратить внимание на этот пункт, ведь вы можете существенно снизить количество головной боли, вызванной отсутствием актуальной информации о новой версии библиотеки.
Важным пунктом документации являются примеры использования. Но помимо этого, зачастую требуется предоставить не библиотеку, а приложение, которое реализует самые стандартные сценарии. Рекомендую делать эти приложения с открытым и хорошо прокомментированным исходным кодом, что позволит убить двух зайцев разом — предоставить работающее приложение и предоставить пример использования SDK.
Данная статья про sdk подтверждают значимость применения современных методик для изучения данных проблем. Надеюсь, что теперь ты понял что такое sdk, software development kit и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Фреймворки. Famworks ( программная платформа)
Комментарии
Оставить комментарий
Фреймворки. Famworks ( программная платформа)
Термины: Фреймворки. Famworks ( программная платформа)