Как бороться со страхом перед зависимостями

Команда, в которой я работаю, создает компоненты, которые могут использоваться партнерами компании для интеграции с нашей платформой.

Таким образом, я согласен, что мы должны проявлять крайнюю осторожность при введении (сторонних) зависимостей. В настоящее время у нас нет сторонних зависимостей, и мы должны оставаться на самом низком уровне API платформы.

Некоторые примеры:

• Мы вынуждены оставаться на самом низком уровне API фреймворка (.NET Standard). Причиной этого является то, что однажды может появиться новая платформа, которая поддерживает только этот очень низкий уровень API.
• Мы внедрили наши собственные компоненты для (де) сериализации JSON и делаем то же самое для JWT. Это доступно на более высоком уровне фреймворка API.
• Мы реализовали оболочку вокруг структуры HTTP стандартной библиотеки, потому что мы не хотим зависеть от реализации HTTP стандартной библиотеки.
• Весь код для отображения в / из XML написан «вручную», опять же по той же причине.

Я чувствую, что мы зашли слишком далеко. Мне интересно, как с этим бороться, так как это, я думаю, сильно влияет на нашу скорость.

... Мы вынуждены оставаться на самом низком уровне API фреймворка (.NET Standard) ...

Для меня это подчеркивает тот факт, что вы не только слишком ограничиваете себя, но и приближаетесь к неприятному падению.

.NET Standard не является и никогда не будет « самым низким уровнем API фреймворка ». Самый ограниченный набор API для .NET достигается путем создания переносимой библиотеки классов, предназначенной для Windows Phone и Silverlight.

В зависимости от того, на какую версию .NET Standard вы ориентируетесь, вы можете получить очень богатый набор API, совместимых с .NET Framework, .NET Core , Mono и Xamarin . И есть много сторонних библиотек, совместимых со стандартом .NET, которые будут работать на всех этих платформах.

Затем есть .NET Standard 2.1, который может быть выпущен осенью 2019 года. Он будет поддерживаться .NET Core, Mono и Xamarin. Он не будет поддерживаться ни одной версией .NET Framework , по крайней мере, в обозримом будущем и, скорее всего, всегда. Таким образом, в ближайшем будущем, далеко не являющийся « самым низким уровнем API платформы », .NET Standard заменит среду и будет иметь API, которые не поддерживаются последними.

Поэтому будьте очень осторожны с « Причиной этого является то, что однажды может появиться новая платформа, которая поддерживает только этот очень низкий уровень API », так как вполне вероятно, что новые платформы на самом деле будут поддерживать API более высокого уровня, чем старая платформа.

Тогда есть проблема сторонних библиотек. Например, JSON.NET совместим со стандартом .NET. Любая библиотека, совместимая с .NET Standard, гарантированно - с точки зрения API - работает со всеми реализациями .NET, совместимыми с этой версией .NET Standard. Таким образом, вы не достигаете никакой дополнительной совместимости, не используя ее и создавая свою библиотеку JSON. Вы просто создаете больше работы для себя и несете ненужные расходы для вашей компании.

Так что да, вы определенно слишком далеко зашли, на мой взгляд.

Мы вынуждены оставаться на самом низком уровне API фреймворка (стандарт .net). Причиной этого является то, что однажды может появиться новая платформа, которая поддерживает только этот очень низкий уровень API.

Рассуждения здесь скорее задом наперед. Старые, более низкие уровни API с большей вероятностью устаревают и не поддерживаются, чем более новые. Хотя я согласен с тем, что разумно оставаться в стороне от «передового края», чтобы обеспечить разумный уровень совместимости в сценарии, о котором вы упомянули, никогда не выходить за пределы предела.

Мы внедрили наши собственные компоненты для (де) сериализации JSON и делаем то же самое для JWT. Это доступно на более высоком уровне фреймворка API. Мы реализовали оболочку вокруг структуры HTTP стандартной библиотеки, потому что мы не хотим зависеть от имплементации HTTP стандартной библиотеки. Весь код для отображения в / из XML написан «вручную», опять же по той же причине.

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

Если случится худшее, и этот проект исчезнет или перестанет обслуживаться, тогда у вас есть код для сборки библиотеки, и вы назначаете кого-то для его обслуживания. И вы, вероятно, все еще находитесь в гораздо лучшем положении, чем если бы вы катались самостоятельно, поскольку в действительности у вас будет больше проверенного, более чистого и более удобного в обслуживании кода.

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

В целом, это хорошо для ваших клиентов. Даже популярная библиотека с открытым исходным кодом может быть по какой-то причине невозможна для них.

Например, они могли подписать контракт со своими клиентами, обещая не использовать продукты с открытым исходным кодом.

Однако, как вы указываете, эти функции не без затрат.

• Пора торговать
• Размер упаковки
• Представление

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

Если все клиенты уже используют Json.NET, например, то использование его в вашем продукте, а не в вашем собственном коде десериализации, уменьшает его размер и улучшает его.

Если вы представите вторую версию своего продукта, в которой используются сторонние библиотеки, а также совместимую, вы можете судить об использовании обеих. Будут ли клиенты использовать третьи стороны для получения новейших функций чуть раньше или будут использовать «совместимую» версию?

Короткий ответ: вы должны начать вводить сторонние зависимости. Во время вашей следующей встречи на рабочем месте скажите всем, что следующая рабочая неделя будет самой веселой за последние годы: они заменит компоненты JSON и XML на решения с открытыми исходными кодами, стандартные библиотеки. Скажите всем, что у них есть три дня для замены компонента JSON. Празднуйте после того, как это сделано. Устроить вечеринку. Это стоит праздновать.

В основном все сводится к усилию против риска.

Добавляя дополнительную зависимость, обновляя свою среду или используя API более высокого уровня, вы снижаете свои усилия, но принимаете на себя риск. Поэтому я бы предложил провести SWOT-анализ .

• Сильные стороны: Меньше усилий, потому что вам не нужно кодировать это самостоятельно.
• Слабые стороны: Это не так специально для ваших особых нужд, как решение ручной работы.
• Возможности: Время выхода на рынок меньше. Вы можете извлечь выгоду из внешних событий.
• Угрозы: вы можете расстроить клиентов дополнительными зависимостями.

Как вы видите, дополнительные усилия по разработке решения ручной работы - это инвестиции в снижение ваших угроз. Теперь вы можете принять стратегическое решение.

Разделите ваши библиотеки компонентов на набор «Core», который не имеет зависимостей (по сути, то, что вы делаете сейчас) и «Common» набор, который имеет зависимости от ваших «Core» и сторонних библиотек.

Таким образом, если кто-то хочет только функциональность «Core», он может иметь ее.

Если кому-то нужна «общая» функциональность, он может ее иметь.

И вы можете управлять тем, что является «ядром» против «общего». Вы можете быстрее добавить функциональность в «Common» и переместить ее в свою собственную «базовую» реализацию, если / когда имеет смысл предоставить собственную реализацию.