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


54

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

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

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

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

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


20
Есть ли для этого оправдание (например, внешнее требование) или это делается по незнанию?
Blrfl

6
Проведите эксперимент с небольшой частью кода, создайте слой изоляции, который не пытается быть универсальной библиотекой, но определяет абстрактный интерфейс, который моделирует ваши потребности; затем поместите в него как собственную реализацию, так и стороннюю зависимость, и сравните, как работают / работают две версии. Взвесьте все за и против, оцените, насколько легко (или сложно) было бы поменять местами реализации, а затем принять решение. Короче говоря, тестируйте вещи относительно рискованным способом, посмотрите, что произойдет, а затем решите.
Филипп Милованович

73
«В настоящее время у нас нет сторонних зависимостей». Это всегда заставляет меня смеяться, когда люди заявляют об этом. Конечно, вы делаете. Вы не написали свой собственный компилятор, IDE, реализацию каких-либо стандартных библиотек. Вы не написали ни одной из библиотек объектов-осколков, которые вы используете косвенно (или напрямую). Когда вы поймете, сколько стороннего программного обеспечения и библиотек зависит от вас, вы можете отказаться от идеи «зависимости плохие» и просто не изобретать велосипед. Я бы просто пометил зависимости, которые у вас есть, и затем спросил, почему они приемлемы, но разбор json - нет.
UKMonkey

8
Тем не менее, есть альтернативные недостатки, как никогда не завершать проекты. Но это продвигать работу программного обеспечения и занятость :)
маршал корабль

5
Вы правы в том, что вы тратите впустую усилия, заново изобретая обычное программное обеспечение. Вы ошибаетесь в том, что это никоим образом не близко к «избеганию всех зависимостей». Команда Excel в Microsoft однажды написала свой собственный компилятор C, чтобы избежать зависимости от команды C в Microsoft . Вы берете огромные зависимости от операционных систем, высокоуровневых фреймворков и так далее.
Эрик Липперт

Ответы:


94

... Мы вынуждены оставаться на самом низком уровне 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. Вы просто создаете больше работы для себя и несете ненужные расходы для вашей компании.

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


16
«Вы просто создаете больше работы для себя и несете ненужные расходы для вашей компании». - и обязательства по безопасности. Ваш кодер JSON аварийно завершает работу с переполнением стека, если вы передаете ему рекурсивный объект? Ваш парсер правильно обрабатывает экранированные символы? Отбрасывает ли он неэкранированные символы? Как насчет непарных суррогатных персонажей? Это переполняется, когда JSON кодирует число больше 2 ^ 64? Или это просто крошечная evalобертка с некоторыми проверками работоспособности, которые легко обойти?
Джон Дворак

4
«Самый ограниченный набор API для .NET достигается путем создания переносимой библиотеки классов, предназначенной для Windows Phone и Silverlight». Я выйду на передний план и утверждаю, что в этом подмножестве есть по крайней мере несколько API, которые не поддерживаются всеми возможными реализациями, которые когда-либо существовали (и никому больше не нужны WinPhone или Silvernight, даже Microsoft). Использование .NetStandard 2.0 в качестве цели для современного фреймворка кажется очень разумным и не особенно ограничивающим. Обновление до 2.1 - это отдельная история, но нет никаких признаков того, что они это сделают.
Во

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

51

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

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

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

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

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

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


3
И даже если вы не можете переключиться на другую библиотеку, все же проще и лучше, чем переходить на другую.
Легкость гонки с Моникой

5
Отличное замечание, что вещи более низкого уровня умирают быстрее. В этом весь смысл создания абстракций.
Легкость гонки с Моникой

«Старые, более низкие уровни API с большей вероятностью устаревают и не поддерживаются, чем более новые». А? Насколько я знаю, NetSTandards строятся друг на друге (то есть 2.0 означает 1.3 + X). Также Стандарты - это просто ... стандарты, а не реализации. Нет смысла говорить о том, что стандарт станет неподдерживаемым, в большинстве конкретных реализаций этого стандарта это может произойти в будущем (но посмотрите на более раннюю точку, почему это также не является проблемой). Если вашей библиотеке ничего не нужно, кроме NetStandard 1.3, абсолютно нет причин менять ее на 2.0
Voo

11

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

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

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

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

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

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

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


11
Да, я, очевидно, согласен, и я бы добавил «безопасность» в ваш список. Существует вероятность того, что вы могли бы внедрить уязвимость в свой код, особенно с такими вещами, как JSON / JWT, по сравнению с хорошо протестированными средами и, безусловно, стандартной библиотекой.
Бертус

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

12
«Возможно, они подписали контракт со своими клиентами, обещая не использовать продукты с открытым исходным кодом», - они используют .NET Standard, который является открытым исходным кодом. Это плохая идея, чтобы подписать этот контракт, когда вы основываете весь свой продукт на среде с открытым исходным кодом.
Стивен

И все же люди делают это
Ewan

7

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


2
Это может быть язык в щеке, но это не нереально. Я присоединился к компании, где «старший» разработчик (старший по образованию) поручил младшему разработчику написать библиотеку конечных автоматов. В нем было пять месяцев разработки, и он все еще глючил, поэтому я разорвал его и за пару дней заменил его на готовое решение.
Нет U

0

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

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

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

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


-2

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.