отдельно
захотелось обсудить как раз идею использования сторонних библиотек и написания
на их основе своего кода.
Точнее, как принимать решение об использовании сторонних библиотек vs. написания своего кода.
Не рассматриваем случай, когда область неизвестна и слабо изучена, либо требуются тысячи человекочасов.
Там, где я работаю, стараются брать сторонние библиотеки, потому что:
плюсы:
0. выше уровень разработки.
1. платформа обкатана, есть документация, форумы, поддержка
2. опыт в разработке на этой платформе
минусы своего кода:
0. долго
1. требуется отладка написанного
Сам я обычно стараюсь ничего стороннего не брать, потому что:
минусы:
0. чужие баги, тормоза, ограниченность функционала. и всё в самый неподходящий момент. Медленная тех.поддержка.
1. надо изучать возможности библиотеки. Как правило, несколько библиотек, чтобы выбрать.
2. надо изучать много чужого кода, примеров, чтобы понять, подходит это или нет. Писать тесты.
3. инсталляторы, тяжёлые библиотеки, из которых используется меньше половины, несовместимость, неактуальность и так далее
4. лицензии. Если это платное, то можно в любой момент ждать что-нибудь новенькое от авторов (2 раза было на моей памяти)
плюсы своего кода:
0. свой код быстро модифицируется под новые нужды
1. опыт написания своих компонентов
2. опыт разработки архитектуры всяких мини-платформ
ну и вообще, со временем появляется навык быстрого определения объёма работы в обоих случаях, что в разы облегчает жизнь
Вот интересно, кто как и на основе чего в своей работе руководствуется при таком выборе?
Здравствуйте, CEMb, Вы писали:
CEM>Точнее, как принимать решение об использовании сторонних библиотек vs. написания своего кода.
Всегда использую сторонние, если это возможно и только если не подходят делаю свой велосипед.
Чтобы определить, что подходят делаю набор тестов, что мне нужны и удовлетворяю их с помощью сторонней библиотеки. Если библиотека не удовлетворяет меня по ~40% тестов, ищу другую, иначе пишу сам.
Если библиотека навязывает свою архитектуру — отказать.
Если библиотека мелкая и используется в паре мест — отказать.
Если библиотека реализует DI или прочий IoC — 99% отказать.
Если не противоречит вышесказанному, то 100% не отказывать, если:
— библиотека реализует специфичный функционал, с которым самому придётся долго разбираться, например, рендереры pdf/excel.
— своя реализация займёт человеко месяцо/годы.
— является общепринятым стандартом, знакомым подавляющему большинству разработчиков.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Если библиотека реализует DI или прочий IoC — 99% отказать.
Это как — свои реализации DI используешь? Или это просто выделенный пункт из общего про навязывание архитектуры (в смысле что навязывает в проект жестко заданную библиотеку IoC)? Или что-то еще?
IT>>Если библиотека реализует DI или прочий IoC — 99% отказать.
Doc>Это как — свои реализации DI используешь? Или это просто выделенный пункт из общего про навязывание архитектуры (в смысле что навязывает в проект жестко заданную библиотеку IoC)? Или что-то еще?
присоединяюсь к вопросу,
некоторое время назад начало во мне расти недовольство спрингом на фоне любви всех вокруг к @Autowire, и я на небольшом (1 год на 2 разработчика) проекте решил попробовать всё инжектить прямо в джаве, написал свой ApplicationContextBuilder который возвращает ApplicationContext со всеми торчащими наружу сервисами,
и вполне доволен результатом,
интересно что другие в этом случае делают
Здравствуйте, Doc, Вы писали:
IT>>Если библиотека реализует DI или прочий IoC — 99% отказать.
Doc>Это как
DI от лукавого. Мне тут в соседней ветке пытались объяснить что такого даёт DI, очень долго пытались, но так и не смогли.
Замечу, что я в курсе определний из педевикии, но мой вопрой именно про "зачем". Ну и аргументы типа "да ты не понимаешь" меня тоже как бы не особо устраивают.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>DI от лукавого. Мне тут в соседней ветке пытались объяснить что такого даёт DI, очень долго пытались, но так и не смогли.
И какая альтернатива используется? new?
IT>Замечу, что я в курсе определний из педевикии, но мой вопрой именно про "зачем".
Для избавления от жестких зависимостей и в случаях когда конкретные реализации не известны на момент написания кода как ответы не подходят?
Здравствуйте, CEMb, Вы писали:
CEM>Вот интересно, кто как и на основе чего в своей работе руководствуется при таком выборе?
В современном мире программного обеспечения (где все тысячи раз переписано сначала для мейнфреймов, потом для PC, потом для облаков etc.) написать свой толковый и быстро работающий велосипед _с нуля_ невозможно. Сначала всегда требуется детально изучить существующие аналоги, понять их преимущества и недостатки. И только окончательно убедившись в том, что недостатков больше и что они критичны для бизнеса, кидаться радостно кодить свое.
Торвальдс сначала помучился с Minix, и только потом стал писать свою ОС. Амазон сначала уперлась во все мыслимые и немыслимые ограничения промышленных СУБД и файловых систем, только потом написала свои сервисы хранения данных и только еще более потом вывела их в онлайн.
Поэтому адекватным подходом к разработке некоего ПО в наше время видится следующее. Сначала следует собрать проект как конструктор, из максимально возможного числа готовых компонентов (библиотек, фреймворков, как угодно назовите), с минимумом собственного кода. Подбор этих компонентов, в том числе выбор наилучшего из списка аналогов — задача архитектора проекта (или человека, его заменяющего). Причем, архитектор обязан не просто тыкнуть пальцем в ту или иную либу, а запрототипировать и самолично протестить эти либы в условиях, максимально приближенных к боевым. Если, к примеру, прототип представлял собой консольное приложение, а на продакшене выбранная либа дергается веб-сервером из множества потоков и падает при этом — это не факап либы, это факап архитектора.
Далее наступает этап тестирования, на котором часть выбранных компонентов может быть отсеяна и заменена/переписана. Наконец, проект выходит в продакшн, в процессе жизни которого еще какая-то часть компонентов признается не выдерживающей критики и заменяется/переписывается (заметьте: проект уже в продакшене и приносит деньги!).
Риски ошибочного выбора компонентов называются проектными рисками, и на борьбу с ними закладывается отдельный бюджет. При этом, согласно теории вероятности, сразу все компоненты ошибочно выбранными оказаться не могут. Поэтому такой подход однозначно выгоднее для бизнеса, нежели все всегда писать самим. А если мы все-таки решаемся переписать какой-то из лагающих компонентов — мы уже точно знаем, что нас не устраивает в чужом решении и как лучше обойти этот боттнек. Иными словами, подход позволяет учиться на чужих ошибках, а не на своих.
Здравствуйте, Doc, Вы писали:
IT>>DI от лукавого. Мне тут в соседней ветке пытались объяснить что такого даёт DI, очень долго пытались, но так и не смогли. Doc>И какая альтернатива используется? new?
Я предложил орлам рассказать мне как прикрутить DI с пользой к одному моему проекту. Они поизучали код, придрались к неотносящимся к делу мелочам, но признали, что DI там ничем не поможет, потому что такой дизайн. Вот это видимо и есть альтернатива.
IT>>Замечу, что я в курсе определний из педевикии, но мой вопрой именно про "зачем". Doc>Для избавления от жестких зависимостей и в случаях когда конкретные реализации не известны на момент написания кода как ответы не подходят?
Пример из того же типика:
void MyVeryPrimitiveMethod()
{
var value1 = _service1.GetValue1();
var value2 = _service2.GetValue2();
var result = value1 * value2;
_service3.SetResult(result);
}
И это всё вместо:
int MyVeryPrimitiveMethod(int value1, int value2)
{
return value1 * value2;
}
Как по-твоему где больше зависимостей?
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT> IT>>DI от лукавого. Мне тут в соседней ветке пытались объяснить что такого даёт DI, очень долго пытались, но так и не смогли.
IT> Doc>И какая альтернатива используется? new?
IT> Я предложил орлам рассказать мне как прикрутить DI с пользой к одному моему проекту. Они поизучали код, придрались к неотносящимся к делу мелочам, но признали, что DI там ничем не поможет, потому что такой дизайн. Вот это видимо и есть альтернатива.
А конкретней? Ну т.е. DI не панацея как и любое общее решение, но ты-то как бы обобщаешь, что DI всегда ерунда.
IT> IT>>Замечу, что я в курсе определний из педевикии, но мой вопрой именно про "зачем".
IT> Doc>Для избавления от жестких зависимостей и в случаях когда конкретные реализации не известны на момент написания кода как ответы не подходят?
IT> Пример из того же типика:
IT>
IT> void MyVeryPrimitiveMethod()
IT> {
IT> var value1 = _service1.GetValue1();
IT> var value2 = _service2.GetValue2();
IT> var result = value1 * value2;
IT> _service3.SetResult(result);
IT> }
IT>
IT> И это всё вместо:
IT>
IT> int MyVeryPrimitiveMethod(int value1, int value2)
IT> {
IT> return value1 * value2;
IT> }
IT>
IT> Как по-твоему где больше зависимостей?
Очень никакой пример: тут можно сделать что и так и этак 'правильно'
Здравствуйте, IT, Вы писали:
IT>Я предложил орлам рассказать мне как прикрутить DI с пользой к одному моему проекту. Они поизучали код, придрались к неотносящимся к делу мелочам, но признали, что DI там ничем не поможет, потому что такой дизайн. Вот это видимо и есть альтернатива.
По сути согласен с уже высказанным рядом мнением — DI не панацея, более того не в каждый тем более готовый проект его легко прикрутить.
IT>Пример из того же типика:
[skip] IT>Как по-твоему где больше зависимостей?
То что зависимость вынесена в вызывающий класс, не значит что ее нет. Да, у класса, кусок кода которого показан, стало меньше зависимостей. Зато другой класс (и возможно не один) теперь должны знать где брать value1 и value2.
Здравствуйте, Dziman, Вы писали:
IT>> Я предложил орлам рассказать мне как прикрутить DI с пользой к одному моему проекту. Они поизучали код, придрались к неотносящимся к делу мелочам, но признали, что DI там ничем не поможет, потому что такой дизайн. Вот это видимо и есть альтернатива.
D>А конкретней? Ну т.е. DI не панацея как и любое общее решение, но ты-то как бы обобщаешь, что DI всегда ерунда.
DI всегда привносит дополнительную сложность в проект, впрочем как и любой другой инструмент. Но компенсировать эту сложность удаётся далеко не всегда и не всем. В этом смысле да, я обобщаю. И главным в том топике, да и в этом тоже, для меня была попытка понять как можно компенсировать ту сложность, которую даёт DI. Ответа я не услышал. Зато много раз услышал "ты не понимаешь"
IT>> Doc>Для избавления от жестких зависимостей и в случаях когда конкретные реализации не известны на момент написания кода как ответы не подходят?
D>Очень никакой пример: тут можно сделать что и так и этак 'правильно'
Этот пример показывает способ избавления от жестких зависимостей. DI такое и не снилось в самых радужных снах.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Doc, Вы писали:
Doc>По сути согласен с уже высказанным рядом мнением — DI не панацея, более того не в каждый тем более готовый проект его легко прикрутить.
Прикрутить его легко, для этого много ума не надо. Достаточно почитать блоги и восторженные посты от людей, которые ещё не наигрались в паттерны и вот это овно уже в проекте и жидким слоем размазано по всему коду.
Doc>То что зависимость вынесена в вызывающий класс, не значит что ее нет. Да, у класса, кусок кода которого показан, стало меньше зависимостей. Зато другой класс (и возможно не один) теперь должны знать где брать value1 и value2.
И в чём проблема?
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, CEMb, Вы писали:
CEM>Вот интересно, кто как и на основе чего в своей работе руководствуется при таком выборе?
Стараюсь писать своё. Оно обычно получается практически довольно быстро, пригодного качества, и можно исправлять, если сломается. Сторонние компоненты прекрасны, пока не сломаются, после чего отладке не поддаются.
Здравствуйте, IT, Вы писали:
IT> Doc>То что зависимость вынесена в вызывающий класс, не значит что ее нет. Да, у класса, кусок кода которого показан, стало меньше зависимостей. Зато другой класс (и возможно не один) теперь должны знать где брать value1 и value2.
IT> И в чём проблема?
Мне кажется вы рассматриваете не ту проблему: DI — это построение графа объектов, а в приведенном примере проблема не в том как построен граф, а как взаимодействуют объекты графа.
Здравствуйте, Dziman, Вы писали:
D>Мне кажется вы рассматриваете не ту проблему: DI — это построение графа объектов, а в приведенном примере проблема не в том как построен граф, а как взаимодействуют объекты графа.
DI — это 25-ти доллоровый термин для 5-ти центовой концепции. Я вообще не понимаю чего с ним так все носятся. Складывается такое впечатление, что DI — это некий верхний предел познания для большинства. Тот кто познал DI прётся от этого необычайно. Хотя даже концепцией это назвать можно с натяжкой. Так себе, не самый лучший паттерн, от которого проблемы возникают сразу и по всему коду, а что он даёт ценного внятно не может объяснить ни один из его апологетов.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Прикрутить его легко, для этого много ума не надо. Достаточно почитать блоги и восторженные посты от людей, которые ещё не наигрались в паттерны и вот это овно уже в проекте и жидким слоем размазано по всему коду.
Ну ясно дело, что если просто так в существующий проект "легко" прикрутить DI, не подумав как это будет работать, то результат будет феерический.
IT>И в чём проблема?
В том, что зависимость не ушла. Её переложили с одного класса на другой. А, как говориться, от перемены мест слагаемых сумма не изменяется.
Здравствуйте, scale_tone, Вы писали:
_>Подбор этих компонентов, в том числе выбор наилучшего из списка аналогов — задача архитектора проекта (или человека, его заменяющего). Причем, архитектор обязан не просто тыкнуть пальцем в ту или иную либу, а запрототипировать и самолично протестить эти либы в условиях, максимально приближенных к боевым.
Для каких-то глобальных вещей — да. Но вы забываете что еще есть всякая мелочь типа jQuery библиотек для UI и прочее. Протестить все за разумное время не реально. И вот тут иногда проще написать велосипед (свой и подконтрольный), чем выбирать 1 из 1000 на первый взгляд близнецов и возиться потом с чужим кодом.
Если нам не помогут, то мы тоже никого не пощадим.
