Здравствуйте, IQuerist, Вы писали:
IQ>У меня был знакомый, тестировщик от рождения, в его руках софт просто горел аццким пламенем "общение" с ним, когда он просто рвал, уже многократно оттестированный UI на части, вызывало бессильную ярость и преклонение перед гениальностью одновременно. Этот
Здравствуйте, ilvi, Вы писали:
C>>Я внутри Amazon'а работаю в облачных вычислениях. I>Полтора-два года назад как раз читал про плеер амазонвский под андроид, были огромные ветки на форумах с разгневаными пользователями и оценка в плеймаркете соответсвенная. Потом довелось подержать в руках один из киндлов, с цветным экраном, на котором этот плеер можно было помучать. Через пять минут я его "сломал" — перестал отображать постеры к описаниям фильмов и еще что-то отвалилось. Потом спросил у дядечки, который руководил одним из проектов по разработке этого плеера, как они тестируют — ответ был, что только юнит тесты и никаких ручных тестов. На тот момент всей этой информации хватило, чтобы сформировать мнение, почему у амазона конкретно этот плеер такой глючный.
А если по сути...
Во-первых, фраза "только юнит тесты и никаких ручных тестов" показывает как минимум непонимание терминологии, а чаще — непонимание темы вообще. Хинт: бывают не ручные UI-тесты, а бывают ручные юнит-тесты.
Во-вторых, ты правда считаешь, что из этой информации правда достаточно для именно такого мнения? Ведь существует столько причин ведущих к плохому качеству продукта, но ты сразу делаешь однозначный далеко идущий вывод. Откуда такое предубеждение к тестам?
В-третьих, а это точно именно амазоновский продукт был? Купили очередной стартап, и слепили что получилось из того что досталось побыстрому. Что не удивительно для очередного плеера, с облачными вычислениями мало что общего.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[15]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, ·, Вы писали:
·>А если по сути... ·>Во-первых, фраза "только юнит тесты и никаких ручных тестов" показывает как минимум непонимание терминологии, а чаще — непонимание темы вообще. Хинт: бывают не ручные UI-тесты, а бывают ручные юнит-тесты. ·>Во-вторых, ты правда считаешь, что из этой информации правда достаточно для именно такого мнения? Ведь существует столько причин ведущих к плохому качеству продукта, но ты сразу делаешь однозначный далеко идущий вывод. Откуда такое предубеждение к тестам? ·>В-третьих, а это точно именно амазоновский продукт был? Купили очередной стартап, и слепили что получилось из того что досталось побыстрому. Что не удивительно для очередного плеера, с облачными вычислениями мало что общего.
3) Именно амазоновский, общался непосредственно с командой его разрабатывающей. Для самого показа видео они использовали сильверлайт, все остальное амозоновская инфраструктура по предоставлению самого видео.
2) У меня нету предубеждения перед тестами, у меня есть предубеждение перед людьми, которые считают, что юнит тесты могут заменить хорошую команду QA. Дополнить могут, но вот заменить — мое мнение нет.
1) Я знаю про автоматизированые тесты, но давать их писать разработчику, это тоже самое что давать тестировать разработчику. Он будет тестировать то что он написал, а это может быть немного не то что требовалось.
Мое мнение, что все типы автоматизорованых тестов это очень хорошо, но не надо при этом сводить команду QA до нуля.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[16]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, IQuerist, Вы писали:
IQ>>У меня был знакомый, тестировщик от рождения, в его руках софт просто горел аццким пламенем "общение" с ним, когда он просто рвал, уже многократно оттестированный UI на части, вызывало бессильную ярость и преклонение перед гениальностью одновременно. S>Этот
Ну все же не на столько брутальный ))) впрочем... один раз он вскрывал алюминевый бочонок пива топором проигнорировав штатный кран, признаться тогда я не придал этому значения.
Re[15]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, ·, Вы писали:
·>Во-вторых, ты правда считаешь, что из этой информации правда достаточно для именно такого мнения? Ведь существует столько причин ведущих к плохому качеству продукта, но ты сразу делаешь однозначный далеко идущий вывод. Откуда такое предубеждение к тестам?
Предубеждение классическое все разработчики страдают "кретинизмом тестирования" и очень часто пропускают кейсы чуть менее очевидные чем выбивалка для ковров ))) Я сам так делаю и у других наблюдаю повсеместно
Re[16]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, ilvi, Вы писали:
I>2) У меня нету предубеждения перед тестами, у меня есть предубеждение перед людьми, которые считают, что юнит тесты могут заменить хорошую команду QA. Дополнить могут, но вот заменить — мое мнение нет.
Юнит-тесты вообще-то не QA, а инструмент разработки.
I>1) Я знаю про автоматизированые тесты, но давать их писать разработчику, это тоже самое что давать тестировать разработчику. Он будет тестировать то что он написал, а это может быть немного не то что требовалось. I>Мое мнение, что все типы автоматизорованых тестов это очень хорошо, но не надо при этом сводить команду QA до нуля.
Так согласен, "отсутствие QA" может быть причиной плохого качества. А "только юнит тесты и никаких ручных тестов" — лажа. На моей прошлой работе команда QA писала тесты, ручного тестирования практически не было.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Понимаю сейчас что польются литры говна на меня от тех кто не осилил и не понял смысла DI но попробую ответить.
Лично для себя сделал простой вывод, DI НЕ требуется только для объектов в которых нет логики, т.е. POCO.
Всё остальное — DI. Причин тут несколько и все они достаточно очевидны и разжёваны не мной а в тьме видео описывающих какие именно проблемы решает DI но я ещё раз ох опишу.
1. Когда говорят про использование DI то в 99% случаев DI используют вместе с контейнером. А смысл контейнера не только в предоставлении зависимостей а в управлении временем жизни объекта. Делегирование управления жизни обьекта контейнеру — одна из самых принципиальных вещей.
2. Использование DI позволяет тебе чётко определять все зависимости объекта, зависимости становятся явными и получает их обьект обычно в конструкторе. Иными словами мне НЕ нужно лазить по коду объекта что бы понять а от чего ещё он зависит. Достаточно глянуть в конструктор и всё становится понятным.
3. При тотальном использовании DI во всём проекте во всём проекте используется один и тот же стандартных подход. Такой код читать просто и понятно. А вот обратный случай когда вот тут вот мы сделаем new, а вот там вот вызовем статический метод а вот это вот мы заинжектим потому что оно — это сервис (а что такое сервис никто не знает). Это точно бред.
В целом у автора пока просто мало опыта использование DI и DI для него новая концепция при переходе к которой абсолютно естественно возникает куча вопросов и нормальное отторжение. Так у всех, это нормально.
IQ>Имхо главного не написано — маниакальная страсть к IOC навязываемая ранним внедрением DI провоцирует нарушение всех принципов SOLID.
Вы бы с SOLID разобрались и не писали чушь. Расскажите мне как DI у нас портит S или I я уже не говорю про D
Здравствуйте, Tom, Вы писали:
Tom>Понимаю сейчас что польются литры говна на меня от тех кто не осилил и не понял смысла DI но попробую ответить.
Литров не обещаю, но возразить могу: контейнер не нужен. Накой мне жуткий монстр тащить, не надо ему ничего делегировать. Я что не в состоянии сам new вызвать в нужный момент? Просто пишется отдельный инфрасткуртурный код, который будет делать весь этот ваш wiring. А эти контейнеры не только с собой тащат всякий хлам с поддержкой всякой чёрной магии (противоречит твоему пункту 3), но ещё и в особо запущенных случаях — жуткие XML-конфиги.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Tom, Вы писали:
Tom>>Понимаю сейчас что польются литры говна на меня от тех кто не осилил и не понял смысла DI но попробую ответить. ·>Литров не обещаю, но возразить могу: контейнер не нужен. Накой мне жуткий монстр тащить, не надо ему ничего делегировать. Я что не в состоянии сам new вызвать в нужный момент? Просто пишется отдельный инфрасткуртурный код, который будет делать весь этот ваш wiring. А эти контейнеры не только с собой тащат всякий хлам с поддержкой всякой чёрной магии (противоречит твоему пункту 3), но ещё и в особо запущенных случаях — жуткие XML-конфиги.
Конфигов 0, не дай бог никакого XML. Магии 0. Монструозности 0. С производительность всё прелесно. Пользовать DI без контейнера конечно можно но жутко неудобно. Вы отстали от жизни.
Здравствуйте, Tom, Вы писали:
Tom>>>Понимаю сейчас что польются литры говна на меня от тех кто не осилил и не понял смысла DI но попробую ответить. Tom>·>Литров не обещаю, но возразить могу: контейнер не нужен. Накой мне жуткий монстр тащить, не надо ему ничего делегировать. Я что не в состоянии сам new вызвать в нужный момент? Просто пишется отдельный инфрасткуртурный код, который будет делать весь этот ваш wiring. А эти контейнеры не только с собой тащат всякий хлам с поддержкой всякой чёрной магии (противоречит твоему пункту 3), но ещё и в особо запущенных случаях — жуткие XML-конфиги. Tom>Конфигов 0, не дай бог никакого XML. Магии 0. Монструозности 0. С производительность всё прелесно. Пользовать DI без контейнера конечно можно но жутко неудобно. Вы отстали от жизни.
Это ты о чём? О каком-то конкретном контейнере?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
·>Это ты о чём? О каком-то конкретном контейнере?
О большинстве современных. Lightinject, DryIoc, Unity, StructureMap итп
Больше скажу, с вовременных зачастую конфигурация только через код.
Здравствуйте, Tom, Вы писали:
Tom>·>Это ты о чём? О каком-то конкретном контейнере? Tom>О большинстве современных. Lightinject, DryIoc, Unity, StructureMap итп Tom>Больше скажу, с вовременных зачастую конфигурация только через код.
Я все не смотрел, посмотрел только первый. А что именно там хорошего, современного?
container.Register<IFoo, Foo>();//я очень надеюсь, что интерфейс IFoo необязателен и регистрировать можно просто Foo.
container.Register<IFoo, AnotherFoo>("AnotherFoo"); // В самом деле? магические строки?!var instance = container.GetInstance<Bar>();// Service Locator?!! фтопку.
container.RegisterInstance<string>("SomeValue");
var value = container.GetInstance<string>();// в контекст суём тип string?!!
Куча вредных антипаттернов, которые легко размазать по всему проекту, а обычно достаточно одного единственного constructor injection. И вычищать потом это — замучаешься.
И собственно тупой код типа:
var someValue = "SomeValue";
var anotherFoo = new AnotherFoo();
var instance = new Bar(anotherFoo, someValue);
выглядит ничуть не хуже.
Единственное для чего эти контейнеры могут быть хороши это всякое Assembly Scanning, но реально проектов, где это необходимо — очень мало.
Tom>Пользовать DI без контейнера конечно можно но жутко неудобно.
Зато полная поддержка компилятора и IDE. А неудобно только с непривычки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
·>Куча вредных антипаттернов, которые легко размазать по всему проекту, а обычно достаточно одного единственного constructor injection. И вычищать потом это — замучаешься.
Давай по конкретнее. Хоть один анти паттерн покажи мне и опиши в чём состоит проблема.
·>И собственно тупой код типа: ·>
·>var someValue = "SomeValue";
·>var anotherFoo = new AnotherFoo();
·>var instance = new Bar(anotherFoo, someValue);
·>
·>выглядит ничуть не хуже.
Выглядит хуже. И создаёт конкретные проблемы в вполне конкретных случаях. Я больше скажу, с управлением временем жизни обьектов руками есть большие проблемы даже на теоретическом уровне. Вот тебе прмиер. Есть обьект IFoo. Ну или IPlugin для наглядности. Есть пара его реализаций, одна из них использует unmanaget ресурсы и требует реализации IDisposable а другая нет. Кроме как калечного решения в виде наследованияч IPlugin от IDisposable для ручного управления зависимостями я не вижу.
·>Единственное для чего эти контейнеры могут быть хороши это всякое Assembly Scanning, но реально проектов, где это необходимо — очень мало.
Контейнеры много чего могут но это бесполезно обьяснять человеку у которого в голове установка что они зло.
Tom>>Пользовать DI без контейнера конечно можно но жутко неудобно. ·>Зато полная поддержка компилятора и IDE. А неудобно только с непривычки.
new это огромные трудности при написании тестов. Я про Integration тесты.
Руками собирать всё дерево зависимостей? Вопрос нахера, если я 2-мя движениями мышки могу в тесте подменить любую зависимость.
Здравствуйте, Tom, Вы писали:
IQ>>Имхо главного не написано — маниакальная страсть к IOC навязываемая ранним внедрением DI провоцирует нарушение всех принципов SOLID. Tom>Вы бы с SOLID разобрались и не писали чушь. Расскажите мне как DI у нас портит S или I я уже не говорю про D
Здравствуйте, Tom, Вы писали:
Tom>Понимаю сейчас что польются литры говна на меня от тех кто не осилил и не понял смысла DI но попробую ответить. Tom>Лично для себя сделал простой вывод, DI НЕ требуется только для объектов в которых нет логики, т.е. POCO.
Звучит эпически, а как быть со stateless объектами в которых одна логика и нет состояния? Для чего им DI, если потенциальное время их жизни — от старта системы до самого ее финиша?
Tom>Всё остальное — DI. Причин тут несколько и все они достаточно очевидны и разжёваны не мной а в тьме видео описывающих какие именно проблемы решает DI но я ещё раз ох опишу.
Tom>1. Когда говорят про использование DI то в 99% случаев DI используют вместе с контейнером. А смысл контейнера не только в предоставлении зависимостей а в управлении временем жизни объекта. Делегирование управления жизни обьекта контейнеру — одна из самых принципиальных вещей.
Забавно ))) вот например есть ворох статических хелперных методов не имеющих состояния. Вот например есть целые сервисы, зависимость от которых и жизни которых определяется контекстом бизнес операции т.к. сильно зависит от бизнес логики...
Мне кажется или ваша позиция больше связана с вопросами веры, чем с вопросами разработки ПО?
Tom>2. Использование DI позволяет тебе чётко определять все зависимости объекта, зависимости становятся явными и получает их обьект обычно в конструкторе. Иными словами мне НЕ нужно лазить по коду объекта что бы понять а от чего ещё он зависит. Достаточно глянуть в конструктор и всё становится понятным.
Э... четко определить зависимости исключительно в рамках конкретной реализации DI которые качественно более примитивные, чем могут быть рамки бизнес операции. Собственно, когда DI перестает использоваться новичками исключительно для хелперных методов, проблемы с ним связанные и начинают всплывать.
Tom>3. При тотальном использовании DI во всём проекте во всём проекте используется один и тот же стандартных подход. Такой код читать просто и понятно. А вот обратный случай когда вот тут вот мы сделаем new, а вот там вот вызовем статический метод а вот это вот мы заинжектим потому что оно — это сервис (а что такое сервис никто не знает). Это точно бред.
А вы не задумывались откуда может взяться понимание, что есть сервис, а что нет на старте проекта? А ведь DI религиозные фанатики начинают использовать в самом начале. Ах да... Tom — "Всё остальное — DI." Т.е. вообще все прямо с самого старта и есть цель для DI... Colonoscopy Injection детектед В общем мой пост как раз про это.
Tom>В целом у автора пока просто мало опыта использование DI и DI для него новая концепция при переходе к которой абсолютно естественно возникает куча вопросов и нормальное отторжение. Так у всех, это нормально.
У меня полно опыта в области DI. Я отхреначивал DI нафиг уже в трех проектах потому как с ним архитектура типа big ball of mud становиться абсолютно неподдерживаемой.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Tom, Вы писали:
Tom>>Понимаю сейчас что польются литры говна на меня от тех кто не осилил и не понял смысла DI но попробую ответить. ·>Литров не обещаю, но возразить могу: контейнер не нужен. Накой мне жуткий монстр тащить, не надо ему ничего делегировать. Я что не в состоянии сам new вызвать в нужный момент? Просто пишется отдельный инфрасткуртурный код, который будет делать весь этот ваш wiring. А эти контейнеры не только с собой тащат всякий хлам с поддержкой всякой чёрной магии (противоречит твоему пункту 3), но ещё и в особо запущенных случаях — жуткие XML-конфиги.
Здравствуйте, Tom, Вы писали:
Tom>·>Единственное для чего эти контейнеры могут быть хороши это всякое Assembly Scanning, но реально проектов, где это необходимо — очень мало. Tom>Контейнеры много чего могут но это бесполезно обьяснять человеку у которого в голове установка что они зло.
И зачем вы тогда комменты писали? поставили бы минус и вся не долга. У нас не было согласия с ., но у него хотя бы есть позиция. А в ваших каментах пока не видно ничего кроме слепой веры и предрассудков.
Здравствуйте, IQuerist, Вы писали:
IQ>Здравствуйте, Tom, Вы писали:
IQ>>>Имхо главного не написано — маниакальная страсть к IOC навязываемая ранним внедрением DI провоцирует нарушение всех принципов SOLID. Tom>>Вы бы с SOLID разобрались и не писали чушь. Расскажите мне как DI у нас портит S или I я уже не говорю про D
IQ>Вы бы сам пост, таки почитали...
Я сам пост читал, в отличии от вас. Вам зажали конкретный вопрос, что именно и как именно из SOLID нарушает DI. Вы слились...
IQ>Звучит эпически, а как быть со stateless объектами в которых одна логика и нет состояния? Для чего им DI, если потенциальное время их жизни — от старта системы до самого ее финиша?
Звучит не эпически а логично. Statefull или Stateless абсолютно никак не влияет на то надо ли обьект инжектить. Единственное на что это влияет — на время жизни обьекта. Если он Stateless — его смело можно делать singleton-ом. Что касается Statefull то надо разбираться что за стейт и кому он принадлежит. А у вас в голове каша, вы смешали разные понятия — State-а, и DI. На вопрос для чего — уже обьяснял, для того что бы иметь возможность подменять в тестах, для того что бы сделать зависимость явной.
Tom>>Всё остальное — DI. Причин тут несколько и все они достаточно очевидны и разжёваны не мной а в тьме видео описывающих какие именно проблемы решает DI но я ещё раз ох опишу.
Tom>>1. Когда говорят про использование DI то в 99% случаев DI используют вместе с контейнером. А смысл контейнера не только в предоставлении зависимостей а в управлении временем жизни объекта. Делегирование управления жизни обьекта контейнеру — одна из самых принципиальных вещей.
IQ>Забавно ))) вот например время жизни db entity определяется оно как правило контекстом внутри одного метода от загрузки из БД до сохранения в БД. Вот например есть ворох статических хелперных методов не имеющих состояния. Вот например есть целые сервисы, зависимость от которых и жизни которых определяется контекстом бизнес операции т.к. сильно зависит от бизнес логики...
Спросить то чего хотел. И ещё раз уточню, забавно выглядит тут ваша позиция неофита. Могу спорить вы возрастной программист лет после 40-ка которые просто не смог в DI. И уже никогда не сможет.
IQ>Мне кажется или ваша позиция больше связана с вопросами веры, чем с вопросами разработки ПО?
Вам кажется. Моя позиция связана с принципами и опытом разработки mission critical систем работающих 24/7 и распространяющихся по схеме PaaS. Качество для нас критически важно. Покрытие тестами для нас критически важно.
Tom>>2. Использование DI позволяет тебе чётко определять все зависимости объекта, зависимости становятся явными и получает их обьект обычно в конструкторе. Иными словами мне НЕ нужно лазить по коду объекта что бы понять а от чего ещё он зависит. Достаточно глянуть в конструктор и всё становится понятным.
IQ> Э... четко определить зависимости исключительно в рамках конкретной реализации DI которые качественно более примитивные, чем могут быть рамки бизнес операции. Собственно, когда DI перестает использоваться новичками исключительно для хелперных методов, проблемы с ним связанные и начинают всплывать.
Мда. Вы научитесь писать стройно и понятно. А то у вас каша не только в голове а и в сообщениях. И когда пишете чётко определяйтесь что именно хотите сказать.
Tom>>3. При тотальном использовании DI во всём проекте во всём проекте используется один и тот же стандартных подход. Такой код читать просто и понятно. А вот обратный случай когда вот тут вот мы сделаем new, а вот там вот вызовем статический метод а вот это вот мы заинжектим потому что оно — это сервис (а что такое сервис никто не знает). Это точно бред.
IQ>А вы не задумывались откуда может взяться понимание, что есть сервис, а что нет на старте проекта? А ведь DI религиозные фанатики начинают использовать в самом начале. Ах да... Tom — "Всё остальное — DI." Т.е. вообще все прямо с самого старта и есть цель для DI... Colonoscopy Injection детектед В общем мой пост как раз про это.
Tom>>В целом у автора пока просто мало опыта использование DI и DI для него новая концепция при переходе к которой абсолютно естественно возникает куча вопросов и нормальное отторжение. Так у всех, это нормально.
IQ> У меня полно опыта в области DI. Я отхреначивал DI нафиг уже в трех проектах потому как с ним архитектура типа big ball of mud становиться абсолютно неподдерживаемой.
С чем вас и поздравляю. Отхреначивайте дальше. И к архитектуре DI не имеет никакого отношения. DI это маленькая частная практика наряду с кучей других практик которые необходимы для того что бы писать качественный код. А то что вы делает называется "макароны"
"общение" с ним, когда он просто рвал, уже многократно оттестированный UI на части, вызывало бессильную ярость и преклонение перед гениальностью одновременно. 
все разработчики страдают "кретинизмом тестирования" и очень часто пропускают кейсы чуть менее очевидные чем выбивалка для ковров ))) Я сам так делаю и у других наблюдаю повсеместно 
