Избыточность против зависимостей: что хуже?

Question

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

Хотя недавно я пытался найти метрический способ взвешивания избыточности в коде и зависимостей в коде. По большей части я пришел к выводу, что сокращение избыточности увеличивает ваши зависимости в вашем коде. Уменьшение зависимостей в вашем коде увеличивает избыточность. Так что это очень сильно противоречит друг другу.

Итак, мой вопрос: Какой хороший показатель вы использовали в прошлом и используете, чтобы взвесить зависимости или избыточность в вашем коде?

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

P.S Исходя из статьи
Статья

Answer 1

Я бы определенно рекомендовал прочитать эссе Джоэлса по этому вопросу:

"В защиту синдрома не изобретенного здесь"

Для зависимости наилучшей метрикой, которую я могу придумать, было бы "остановился бы мир, если бы он исчез". Например, если STL C ++ волшебным образом исчезнет, ​​тонны программ перестанут работать. Если .Net или Java исчезнут, наша экономика, вероятно, обанкротится из-за количества продуктов, которые перестали работать ...

Я бы так подумал. Конечно, многие вещи имеют оттенок серого между «концом света» и «ме», если они исчезли. Чем ближе зависимость к потенциальному концу света, если она исчезнет, ​​тем больше вероятность того, что она будет стабильной, будет иметь активную пользовательскую базу, хорошо знать свои проблемы и т.д. Чем больше пользователей, тем лучше.

Это аналог маленького потребителя некоторого аппаратного компонента. Иногда аппаратные средства устаревают. Зачем? Потому что никто не использует это. Если вы небольшая компания и вам нужен компонент для вашего продукта, вы выберете то, что обычно доступно - то, что «крупные игроки» заказывают в больших количествах, надеясь, что это означает, что (а) компонент не исчезнет (б) проблемы с компонентом хорошо известны, (в) имеется большая, информированная база пользователей и (г) он может стоить дешевле и быть более доступным.

Иногда, тем не менее, вам нужна эта специальная часть конденсатора, и вы рискуете, что компания, продающая ее вам, может не захотеть продолжать выпуск конденсаторов, если вы заказываете только 20 в год, и никого это не волнует :). В этом случае может стоить разработать собственный конденсатор, вместо того чтобы полагаться на ненадежного Doc Brown Inc. Просто не покупайте плутоний у ливийцев.

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

Как измерить это в реальной метрике? Приблизительно посчитайте, сколько людей зависит от чего-либо. Если оно высокое, риск причинения вам вреда гораздо ниже, и вы можете решить, в какой момент риск слишком велик.

Answer 2

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

• Насколько широко распространена библиотека (смогу ли я найти поддержку, если она мне понадобится)
• Какова вероятность того, что мне придется делать неожиданные вещи с этим (собираюсь ли я в конечном итоге приступить к трехнедельной миссии, чтобы добавить необходимую мне функциональность?)
• Сколько из этого мне нужно использовать (я собираюсь провести дни, изучая все входы и выходы только для того, чтобы использовать одну функцию)
• Насколько стабильно это выглядит (больше проблем, чем стоит?)
• Насколько стабилен интерфейс (возможны ли изменения в ближайшие год или два?)
• Насколько интересна проблема (лично мне было бы лучше реализовать ее самостоятельно? Узнаю ли я что-нибудь полезное?)

Answer 3

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

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

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

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

Хорошим примером этого может быть использование сопоставителя объектных отношений (Hibernate \ NHibernate) за набором репозиториев или объектов доступа к данным, или фабрик, реализуемых с помощью структуры внедрения зависимостей.