Re[9]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 14.10.13 03:01
Оценка:
Здравствуйте, Doc, Вы писали:

Doc>В том, что зависимость не ушла. Её переложили с одного класса на другой. А, как говориться, от перемены мест слагаемых сумма не изменяется.


Ещё как изменится. Эта аналогия в данном случае не работает и поэтому не уместна.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: своё vs. сторонее
От: Doc Россия http://andrey.moveax.ru
Дата: 14.10.13 07:22
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ещё как изменится. Эта аналогия в данном случае не работает и поэтому не уместна.


И как изменится? Что вижу я тут http://www.rsdn.ru/forum/design/5329186.1:
Автор: IT
Дата: 13.10.13


Первый код: есть класс А, зависящий от _service, и (должен быть) класс B, вызывающий его метод MyVeryPrimitiveMethod.

После переделки: есть класс А, и класс B, вызывающий его метод MyVeryPrimitiveMethod и зависящий от _service.

Как видим, зависимость никуда не делась, ибо value1 и value2 откуда-то должны браться.
Re[2]: своё vs. сторонее
От: Sni4ok  
Дата: 14.10.13 07:25
Оценка:
Здравствуйте, scale_tone, Вы писали:

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


ну вот реально нету быстрого свободного логера например, с оверхедом с учётом формотирования не более 1мкс например, и хоть убей- нужно писать самому.
Re[3]: своё vs. сторонее
От: Sinix  
Дата: 14.10.13 07:47
Оценка:
Здравствуйте, Sni4ok, Вы писали:

S>ну вот реально нету быстрого свободного логера например, с оверхедом с учётом формотирования не более 1мкс например, и хоть убей- нужно писать самому.

Если только под win — можно использовать ETW. Вот тут обещают 600k/sec для простого примера на шарпе. Если код нативнцый — подозреваю, будет быстрее.
Re[4]: своё vs. сторонее
От: Sni4ok  
Дата: 14.10.13 08:23
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Вот тут[/url] обещают 600k/sec для простого примера на шарпе. Если код нативнцый — подозреваю, будет быстрее.


1.5мкс в среднем на запись? да это тормозный платформозависимый бред, логер тут я вам привёл лишь в пример, я не против сторонних библиотек- и стараюсь использовать вначале именно их(конечно если это часть буста :D), просто они часто медленные и с кучей реалтаймового оверхеда.
Re[3]: своё vs. сторонее
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 14.10.13 08:28
Оценка:
Здравствуйте, Doc, Вы писали:

Doc>Для каких-то глобальных вещей — да. Но вы забываете что еще есть всякая мелочь типа jQuery библиотек для UI и прочее. Протестить все за разумное время не реально. И вот тут иногда проще написать велосипед (свой и подконтрольный), чем выбирать 1 из 1000 на первый взгляд близнецов и возиться потом с чужим кодом.


С подачи топикстартера, речь идет о тысячах человекочасов. Метод, впрочем, работает и на меньших масштабах — до десятков.
Протестить все действительно нереально. Но у либы из интернета в этом плане тоже есть преимущество: ее кто-то другой уже успел поюзать. И соответственно, есть шанс, что часть багов в ней уже нашли. Баги же в собственной поделке всегда приходится искать самостоятельно.

Еще раз подчеркиваю: мы говорим о промышленной разработке коммерческого ПО. Про ситуацию "сам себе девелопер, тестер, бизнес-оунер и юзер" мы не говорим.
Re[4]: своё vs. сторонее
От: Doc Россия http://andrey.moveax.ru
Дата: 14.10.13 08:37
Оценка:
Здравствуйте, scale_tone, Вы писали:

_>С подачи топикстартера, речь идет о тысячах человекочасов.


В точности наоборот (из первого поста)

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


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


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

_>Еще раз подчеркиваю: мы говорим о промышленной разработке коммерческого ПО.


Я о том же. Про большие либы с большими затратами в человеко-часах полностью согласен (более 1-2 дня работы). Я лишь уточняю, что речь идет больше как раз о мелких либах (особенно если она используется из проекта в проект).
Re[3]: своё vs. сторонее
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 14.10.13 08:43
Оценка:
Здравствуйте, Sni4ok, Вы писали:

S>ну вот реально нету быстрого свободного логера например, с оверхедом с учётом формотирования не более 1мкс например, и хоть убей- нужно писать самому.


Этот кейс вполне вписывается в схему. Если его реально нету.
Re[5]: своё vs. сторонее
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 14.10.13 09:40
Оценка:
Здравствуйте, Doc, Вы писали:

Doc>В точности наоборот (из первого поста)

Doc>

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


Это да, это я ошибся.

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


ОК, сойдемся на диапазоне o-o > X > (1-2 дня).
Re: своё vs. сторонее
От: smallpoxlet Ниоткуда  
Дата: 14.10.13 09:50
Оценка: 43 (5)
Здравствуйте, CEMb, Вы писали:

CEM>по мотивам этого поста
Автор: Vzhyk
Дата: 09.10.13
отдельно

CEM>захотелось обсудить как раз идею использования сторонних библиотек и написания
CEM>на их основе своего кода.

CEM>Вот интересно, кто как и на основе чего в своей работе руководствуется при таком выборе?


У нас в компании принята политика выбора библиотек.
1. Обязательно open source под либеральной лицензией (GPL идет лесом сразу, проприетарщина допустима только при наличии саппорт контракта не менее чем на срок жизни проекта с прибитым гвоздями SLA или при наличии исходников)
2. Библиотека в обязательном порядке проходит acceptance review при котором проверяется качество кода, вменяемость разработчика, политику патчей, активность комьюнити, покрытие тестами, систему сборки и т.п. По результатам AR может быть три вердикта: "в топку", "берем" и "берем под свою ответственность". Последнее означает что мы посылаем разработчика в пень и форкаем проект в свою инфрастркутуру, налаживаем систему сборки, тестирование и т.п. В некоторых проектах наши люди становятся основными контрибуторами и эти проекты фактически переходят под наш контроль.
3. Если библиотека признана годной, то она проходит compatibility review на котором проверяется насколько архитектура библиотеки совместима с нашими проектами. Часто при этом пишутся тесты на типичные сценарии из наших проектов. Обычно этим занимаются интерны/джуниоры под наблюдением старших. Если уж они способны справится с библиотекой, то и нормальные разработчики смогут.
4. Если оба ревью пройдены библиотека считается разрешенной к использованию. Библиотеке назначается внутренний мейнтейнер который собирает ее в пакет, следит за обновлениями, отправляет патчи, общается в списках рассылки, рекомендует или наоборот запрещает переход на новые версии. Как правило этим занимается тот же человек что проводил AR, но иногда на эту роль мы берем на контракт разработчика библиотеки.

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

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

Для статистики: протокол прошли >100 библиотек из них разрешены к использованию 32 из них активно используются 12. Включены в инфраструктуру компании и опубликованы — 5.
Дислексия — чума XXI века
Re[8]: своё vs. сторонее
От: Mr.Delphist  
Дата: 14.10.13 10:05
Оценка: +1 -1
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Dziman, Вы писали:


IT>>> Я предложил орлам рассказать мне как прикрутить DI с пользой к одному моему проекту. Они поизучали код, придрались к неотносящимся к делу мелочам, но признали, что DI там ничем не поможет, потому что такой дизайн. Вот это видимо и есть альтернатива.


D>>А конкретней? Ну т.е. DI не панацея как и любое общее решение, но ты-то как бы обобщаешь, что DI всегда ерунда.


IT>DI всегда привносит дополнительную сложность в проект, впрочем как и любой другой инструмент. Но компенсировать эту сложность удаётся далеко не всегда и не всем. В этом смысле да, я обобщаю. И главным в том топике, да и в этом тоже, для меня была попытка понять как можно компенсировать ту сложность, которую даёт DI. Ответа я не услышал. Зато много раз услышал "ты не понимаешь"


Если DI даёт сложность — то да, это неправильный DI. Или неподходящая архитектура (да, все мы грешили в своё время MyClass.getInstance()-рукоблудием)

IT>>> Doc>Для избавления от жестких зависимостей и в случаях когда конкретные реализации не известны на момент написания кода как ответы не подходят?


D>>Очень никакой пример: тут можно сделать что и так и этак 'правильно'


IT>Этот пример показывает способ избавления от жестких зависимостей. DI такое и не снилось в самых радужных снах.


Похоже, действительно "Вы не понимаете"
Что такое сервисы 1 и 2? откуда они и кто их создаёт?
Кто вбрасывает первое и второе значения в MyVeryPrimitiveMethod()? возможны ли иные кроме перемножения варианты вычислений?

Ответы на эти вопросы и определяют, надо ли "депенденсиинжектировать" данный кусок кода. Если же DI применено по уму, то
1) упрощается тестирование, т.к. легко можно собрать каждый компонент системы с разными моками вместо прочих компонентов и прогнать хоть интеграционные, хоть нагрузочные, хоть ещё какие тесты
2) упрощается конфигурирование, т.к. можно менять поведение системы "на лету" без перекомпиляции (и редеплоя, что очень важно для всяких энтерпрайзов)
Re[10]: своё vs. сторонее
От: Dziman США http://github.com/Dziman
Дата: 14.10.13 10:06
Оценка:
Здравствуйте, IT, Вы писали:

IT> D>Мне кажется вы рассматриваете не ту проблему: DI — это построение графа объектов, а в приведенном примере проблема не в том как построен граф, а как взаимодействуют объекты графа.


IT> DI &mdash; это 25-ти доллоровый термин для 5-ти центовой концепции. Я вообще не понимаю чего с ним так все носятся. Складывается такое впечатление, что DI — это некий верхний предел познания для большинства. Тот кто познал DI прётся от этого необычайно. Хотя даже концепцией это назвать можно с натяжкой. Так себе, не самый лучший паттерн, от которого проблемы возникают сразу и по всему коду,

Можно пример проблемы именно из-за DI?
IT> а что он даёт ценного внятно не может объяснить ни один из его апологетов.
Decoupling
avalon 1.0rc3 build 430, zlib 1.2.5
Re[10]: своё vs. сторонее
От: Doc Россия http://andrey.moveax.ru
Дата: 14.10.13 10:28
Оценка:
Здравствуйте, IT, Вы писали:

IT>DI &mdash; это 25-ти доллоровый термин для 5-ти центовой концепции.


Кстати, забавная статья, про то, как человек открыл для себя тот факт, что DI это передача экземпляра заданного класса внутрь его класса. Он так скоро откроет, что там еще и интерфейсы можно использовать.
Re[11]: своё vs. сторонее
От: Noen  
Дата: 14.10.13 11:02
Оценка:
Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, IT, Вы писали:


IT>>DI &mdash; это 25-ти доллоровый термин для 5-ти центовой концепции.


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



You can have the dependency be an interface and then polymorphically pass in some polyjuice.

Re[9]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 14.10.13 13:44
Оценка: :)
Здравствуйте, Mr.Delphist, Вы писали:

MD>Если DI даёт сложность — то да, это неправильный DI.


DI даёт сложность всегда и без всяких если.

MD>Похоже, действительно "Вы не понимаете"


Ага. Началось.

MD>1) упрощается тестирование, т.к. легко можно собрать каждый компонент системы с разными моками вместо прочих компонентов и прогнать хоть интеграционные, хоть нагрузочные, хоть ещё какие тесты


Предыдущим товарищам было предложено упростить тестирование в конкретном проекте с помощью DI. Не смогли

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


В случае отсутствия DI отсутствует и всякое конфигурирование. Как можно упростить то, чего нет?
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 14.10.13 14:40
Оценка: +1
Здравствуйте, Dziman, Вы писали:

D>Можно пример проблемы именно из-за DI?


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

IT>> а что он даёт ценного внятно не может объяснить ни один из его апологетов.

D>Decoupling

А всегда ли это нужно?
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 14.10.13 14:51
Оценка: :)
Здравствуйте, Doc, Вы писали:

Doc>Как видим, зависимость никуда не делась, ибо value1 и value2 откуда-то должны браться.


Это уже проблема вызывающего класса. У обсуждаемого класса зависимостей нет вообще.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: своё vs. сторонее
От: artelk  
Дата: 14.10.13 17:03
Оценка:
Здравствуйте, IT, Вы писали:

IT>Я предложил орлам рассказать мне как прикрутить DI с пользой к одному моему проекту. Они поизучали код, придрались к неотносящимся к делу мелочам, но признали, что DI там ничем не поможет, потому что такой дизайн. Вот это видимо и есть альтернатива.


Этот проект, все же, несколько отличается от того, с чем приходится сталкиваться в энтерпрайзе. Хотя бы тем, что он, чуть менее чем полностью, представляет из себя один большой преобразователь из linq выражения в sql запрос. Но я таки нашел в нем некий упрощенный контейнер:

public partial class DataConnection : ICloneable
{
    static readonly ConcurrentDictionary<string,IDataProvider> _dataProviders = new ConcurrentDictionary<string,IDataProvider>();

    //оффтоп: а почему _dataProviders потокобезопасен, а _providerDetectors нет?
    readonly static List<Func<ConnectionStringSettings,IDataProvider>> _providerDetectors = new List<Func<ConnectionStringSettings,IDataProvider>>();

    public static void AddDataProvider(string providerName, IDataProvider dataProvider)
    {
         //...
        _dataProviders[providerName] = dataProvider;
    }

    public static void AddDataProvider(IDataProvider dataProvider)
    {
         //...
        AddDataProvider(dataProvider.Name, dataProvider);
    }

    public static void AddProviderDetector(Func<ConnectionStringSettings,IDataProvider> providerDetector)
    {
        _providerDetectors.Add(providerDetector);
    }

    static DataConnection()
    {
        LinqToDB.DataProvider.SqlServer. SqlServerTools. GetDataProvider();
        LinqToDB.DataProvider.Access.    AccessTools.    GetDataProvider();
            //...
    }
}


Обращение к методам GetDataProvider имеет побочный эффект в виде вызова статических конструкторов классов. Например, смотрим SqlServerTools:

    static SqlServerTools()
    {
        AutoDetectProvider = true;

        DataConnection.AddDataProvider(ProviderName.SqlServer, _sqlServerDataProvider2008);
        DataConnection.AddDataProvider(_sqlServerDataProvider2012);
        DataConnection.AddDataProvider(_sqlServerDataProvider2008);
        DataConnection.AddDataProvider(_sqlServerDataProvider2005);
        DataConnection.AddDataProvider(_sqlServerDataProvider2000);

        DataConnection.AddProviderDetector(ProviderDetector);
    }


Т.е. так осуществляется регистрация в контейнере различных дата-провайдеров и их детектеров.
Re[7]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 14.10.13 17:15
Оценка:
Здравствуйте, artelk, Вы писали:

A>Обращение к методам GetDataProvider имеет побочный эффект в виде вызова статических конструкторов классов. Например, смотрим SqlServerTools:


И в чём проблема?
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: своё vs. сторонее
От: IT Россия linq2db.com
Дата: 14.10.13 17:20
Оценка:
Здравствуйте, artelk, Вы писали:

A>Этот проект, все же, несколько отличается от того, с чем приходится сталкиваться в энтерпрайзе.


По поводу энтерпрайза. Как раз если и использовать DI для тестирования, то в таких проектах как linq1db. В энтерпрайзах 90% логики — это работа с базами данных. А в самых запущенных случаях вся логика вообще находится в сохранённых процедурах, т.е. в самой базе данных. И если у кого-нибудь хватит мозгов использовать DI, чтобы мокать такую логику, то что, скажите вы собираетесь тестировать, умение C# генерировать вызовы методов? Так это уже давно было сделано в MS.

А те оставшиеся 10% нетривиальной логики, которую действительно нужно гонять на самых разных данных и желательно без БД, совершенно спокойно можно задизайнить таким образом, что всё, что ей нужно будет передаваться по необходимости. И всё. DI не нужен.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.