Есть ли доказательства того, что использование внедрения зависимостей улучшает результаты в разработке программного обеспечения?

18

Несмотря на его популярность, есть ли эмпирические данные, которые показывают, что Dependency Injection (и / или использование DI-контейнера) помогает, скажем, уменьшать количество ошибок, улучшать удобство обслуживания или увеличивать скорость разработки в реальных программных проектах?

NMrt
источник
3
Возможный дубликат инъекции зависимости: как ее продать И прежде чем заглянуть только в заголовок и подумать «эй, это не буквально дурак» - прочитайте этот другой вопрос и ответы, я думаю, что они очень хорошо подходят к этому вопросу здесь.
Док Браун
5
Примите тот факт, что многие практики профессиональной разработки программного обеспечения не имеют «научных доказательств», они основаны на практическом опыте. Таким образом, даже если вы сейчас усугубили свой вопрос только из-за того, что пытались сделать его искусственно «менее дублирующим», чем тот, на который я ссылался, реальный вопрос, который вы должны были задать, чтобы получить ответы, которые вы действительно хотите знать, - это другой вопрос, с которым я связан , И, между прочим, теперь кажется, что вы запрашиваете сторонние ресурсы, что не по теме на этом сайте.
Док Браун
6
Очень немногие методы разработки программного обеспечения сопровождаются научными доказательствами, в которых вы можете указать на исследовательскую работу и окончательно заявить, что метод является ценным. Следовательно, большинство из нас полагаются на опыт и анализ затрат / выгод для обоснования наших решений. Вы выбираете методику, такую ​​как внедрение зависимости, потому что вам нужны преимущества, которые она дает, и потому что эти выгоды перевешивают затраты. Следует признать, что это исчисление всегда несколько субъективно.
Роберт Харви
1
@DocBrown Честно говоря, я сам не вижу в этом ни дубликата, ни постороннего. Обоснование и эффективность практики разработки представляется очень важной для SE.SE. И я собираюсь дать ответ. ОП, вероятно, не понравится мой ответ ... но, я думаю, стоит иметь объективный ответ (почти ответ) на то, могут ли TPO и PM ожидать, что производительность их команд волшебным образом вырастет (или их уровень ошибок снизится) как как только кто-то кричит «инъекция зависимости».
svidgen
3
@gnat, вероятно, стоит начать отдельный мета-вопрос для «доказательных» вопросов, которые были добавлены в объем этого мета-ответа «вне сайта» задолго до того, как я проголосовал за него. Конечно, просить нас найти статистику, вероятно, бесполезно. Но суть вопроса вполне разумна. И для меня это звучит как лень так быстро отозвать это из темы. Комментарии здесь, в частности, создают впечатление, что мы группа догматиков, которые просто не могут защитить нашу практику. Ну, мы можем. И мы должны.
svidgen

Ответы:

14

TLDR

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


А теперь, с гораздо большим многословием ...

Есть ли эмпирические доказательства?

Конечно, наверное. Или, по крайней мере, может быть. Но кого это волнует? Это не актуально.

Статистический анализ затрат и выгод DI может быть интересен академически, но он не обязательно предсказывает индивидуальный успех. Совокупные результаты скрывают индивидуальные успехи и неудачи. И я могу утверждать, что данные о «евангельских» практиках особенно ядовиты. Эти дисциплины, как правило, привлекают как фанатиков, так и дураков, которые затеняют чистое влияние «чистой» реализации, и любой из которых вы можете быть!

Итак, как мы узнаем, что инъекция зависимостей вообще полезна ?

Хороший вопрос! БОЛЬШОЙ вопрос, на самом деле. И я с тобой - я ненавижу тратить время и умственные усилия на догматические "лучшие практики", которые никто не может оправдать. Итак, я рад, что вы спросили.

Гм. Но вот смущающая проблема ... В общем , вы не знаете. И, что еще более неловко, ваш код может на самом деле не стать лучше, введя DI.


GASP!

    ⊙▃⊙     . . .      (╯°□°)╯︵ ┻━┻

...


Итак, может быть, теперь вам интересно ...

Почему я должен беспокоиться о вещах, которые не были доказаны?

Прежде всего, давайте все просто - на каждой стороне дебатов - просто успокоиться. Я могу заверить вас, что между догматизмом и скептицизмом лежит прекрасный рай разума и рассудительности. (И иногда эксцентричный пост SE.SE.) И, POAP может привести вас туда.

... Под чем я подразумеваю принцип применения принципов :

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

Вы должны понимать, почему вы делаете то, что делаете!

(POAP не освобождается от POAP.)

(Я бы сказал, «выделение мое», но в любом случае это из моего собственного «блога». Итак, это все мое!)

Позвольте мне повторить главное: вам нужно понять, почему вы делаете то, что делаете.

И, возможно, чтобы уточнить, как правило, не имеет смысла брать какое-то данное «что-то» (например, инъекцию зависимости) и использовать его, не понимая, какую проблему оно решает - специально для вас. Если вы понимаете свои проблемы и то, как работает «что-то» (например, DI), будет несколько «очевидно», насколько полезно «что-то», в значительной степени независимо от того, что предлагают обобщенные, агрегированные, эмпирические данные.

Если полезность DI или ООН -helpfulness вам не очевидно , - или , по крайней мере , за пределами ваших рассуждений полномочий - вы либо не понимаете , DI, или вы не понимаете , ваши собственные проблем.


Давайте рассмотрим реальную притчу.

Нам нужно построить коробку. У нас есть дерево. У нас есть гвозди. И у нас есть два инструмента: стандартный молоток с раздвоенным хвостом и отвертка .

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

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

Телекинез!

Эээ ... хм ...


Да-а, какую проблему решает Dependency Injection?

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

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

Мы начали евангелизировать базовую передачу параметров, назвав ее «Внедрение зависимостей», когда накопили и унаследовали достаточно кода, чтобы увидеть наши дисбалансы. Горы кода, над которыми мы сидели, не могли быть легко изменены, протестированы или даже использованы повторно просто потому, что зависимости были скрыты.

Следовательно, ревностный крестовый поход для инъекции зависимости ...

К. Но я могу передать аргументы в порядке. Почему рамки ?

Насколько я понимаю, структуры DI в первую очередь решают проблему накопления шаблонов (из-за чрезмерно усердного DI, IMO) - особенно, когда существуют стандартные зависимости «по умолчанию» для всех модулей, которые в них нуждаются. DI-фреймворки совершают магические (потенциально даже порочные) вещи, чтобы вытащить эти зависимости по умолчанию, когда они явно не передаются в момент вызова. (Имейте в виду тот же эффект, что и при использовании локатора услуг при использовании таким образом!)

Инъекция зависимости, как «дисциплина», на самом деле очень трудно понять правильно. Это не вопрос использования DI или нет; это вопрос зная , какая зависимость, вероятно, изменения или необходимости насмешек и инъекционных тех . И затем, вопрос о том, подходит ли DI лучше, чем какая-либо альтернатива, например, Service Location ...

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

svidgen
источник
4
Вы нюхали немного клея @ CandiedOrange? +1 за принцип прикладных целей.
Роберт Харви
1
@RobertHarvey Хотелось бы сказать, что я новичок, о клее, о котором мы говорили! У меня была давняя вендетта против основанной на вере инженерии ... Разве вы не имеете в виду повествование - возможно, даже сумасшедший - характер поста?
svidgen
2
Кстати, ничто не наполняет меня уверенностью в моем решении ответить на вопрос больше, чем хорошо сбалансированные голоса вверх и вниз! ... Хотелось бы увидеть вашу критику в комментариях ...
svidgen
3
@RobertHarvey не уверен, на какой из моих многочисленных клеев вы ссылаетесь, но я согласен с каждым словом этого. Легко думать, что молоток сосет, когда вы используете его на винтах.
candied_orange
Началось редактирование, чтобы включить больше подробностей о DI, а также всплыть над TLDR. А потом дети начали суетиться, поэтому я нажал «Сохранить». ... Если я случайно потерял суть того, что вы проголосовали (для тех из вас, кто это сделал), пожалуйста, дайте мне знать!
svidgen
12

Я искал Google, Google Scholar, ACM и IEEE. Вот документы, которые мне удалось найти:

  • Основы внедрения зависимостей: улучшение тестируемости? , Он утверждает, что «тестируемость» может быть определена как «низкая сплоченность». В нем говорится, что DI приводит к снижению когезии, более низкая когезия коррелирует с более высоким охватом испытаний, и что более высокий охват тестированием коррелирует с большим количеством обнаруженных неисправностей. Это говорит о том, что, основываясь на этом, DI улучшает тестируемость.

    Мне это не нравится по нескольким причинам. Прежде всего, он говорит: «А соотносится с В, В соотносится с С, поэтому А вызывает С», что является парой шагов в логике, которую я не вижу в статье. Во-вторых, он признает, что он измеряет только «части тестируемости», и что «тестируемость» в целом не так легко определить. Наконец, их мера тестируемости определяется количеством введенных зависимостей!

  • Влияние внедрения зависимости на ремонтопригодность . Они сравнивают проекты, использующие DI, с проектами, не использующими DI, которые они нашли в SourceForge, и выясняют, есть ли различия в показателях сплоченности. Чтобы уменьшить предвзятость, они объединили проекты, чтобы они были максимально похожими. В конечном счете, они увидели сигналы о том, что проекты с большим количеством DI были несколько менее связаны, чем проекты с небольшим количеством DI. Однако, похоже, что между проектами DI и их парой не-DI не было существенной разницы в сплоченности, поэтому это может быть следствием конкретных областей. Они перечисляют «отсутствие корреляции» в качестве основного результата и «возможно, это немного помогает?» как тема для дальнейшего изучения.

  • Эмпирически оценивая влияние внедрения зависимости на разработку приложений веб-сервисов . Аннотация не совсем объясняет, что они ищут. Я выкопал и прочитал препринт, и насколько я могу судить, он на самом деле о том, насколько хорошо автоматизированный инструментарий может обнаруживать сервисы. Сервисы, написанные в стиле DI, легче обнаружить. Кроме того, он ссылается на предыдущее исследование, которое я перечислил как обеспечивающее эмпирическое доказательство того, что DI уменьшает сцепление, что противоположно тому, что утверждал этот документ.

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

Hovercouch
источник
2
Это отвечает на вопрос напрямую. +1
Мэтью Джеймс Бриггс
3
@MatthewJamesBriggs Я не даунвотер, но имеет ли значение непосредственный ответ на вопрос, является ли ответ вводящим в заблуждение или неполным ???
svidgen
@svidgen Я не вижу, как ответ неполон. Вопрос был "есть ли у нас эмпирические доказательства того, что ДИ работает?" И ответ нет." Это ничего не говорит о том, работает ли оно или нет, просто нет исследований.
Hovercouch
1
Неполный и вводящий в заблуждение ответ на ваш вопрос ограничивает область «доказательств» «бумагами, которые вы (sic) были в состоянии найти», и скрывает «эффективность» без учета реальных целей DI и наличия у вас поэтому пришел к выводу, что ответ «нет» без оговорок ... Я бы сказал, что, если вы собираетесь «прямо» ответить на вопрос, как предлагает @MatthewJamesBriggs, на вас лежит большая ответственность за то, чтобы копать глубоко и смог с высокой степенью уверенности продемонстрировать, что вы исследовали все пути ...
svidgen
1
И я думаю, когда объединить , что с поспешной оценкой одного ресурса вы же процитировать, я мог бы даже назвать этот ответ очень вводит в заблуждение. Потому что, помимо всех потенциальных доказательств, которые вы игнорируете, вы берете документированные доказательства и сразу же обесцениваете их по причинам, не полностью объясненным. ... Если бы я, например, утверждал, что "нет никаких доказательств того, что мы приземлились на Луну", потому что "единственная" статья, которую я когда-либо читал по этому вопросу, была из "устаревшей" редакции учебника, которую я не делаю доверяю, я надеюсь, что вы скептически относитесь к моим методам ...
svidgen