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

Пункт другое желательно комментировать.

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

Если библиотека удовлетворяет моим требованиям - воспользуюсь ей. 

Ажно растерялась. но выбрала "Одинаково часто использую и то и то" Все зависит от того что хотелось бы иметь конкретно ;)

В основном предпочитаю стандартные библиотеки. Но велосипеды тоже иногда пишу. Хотя бы для практики и опыта.

Понимайте как хотите ))))

Почему именно "стандартные"? А как же чужие, платные библиотеки?

Ну короче как нам скажут, так и делаем. 

Наверно лучше было написать сторонние или готовые библиотеки.

Сторонними библиотеками под дотнет постоянно приходится пользоваться, т.к. проще взять готовое и с саппортом, чем тратить человекочасы на своё сырое и глючное   

Надо бы всех программёров обязать использовать стандартные либы!! ))

Дел в том, что через полгода после написания самому -то сложно вспомнить, что это было и нафига. Не говоря уже о том, что другой человек возможно будет должен использовать твой код. Готовые библиотеки как правило хорошо задокументены + постоянно апдейтятся и оптимируются. так же вероятность того, что другой человек знаком с такой либой намного болъше того, что он знаком с твоим велосипедом ))) Так что всегда может подменить. и код легче ему дибагить при случае..

Я придерживаюсь такого правила. Если есть подходящая либа - беру её, если нет - пишу такую а докой итд. А уж "application specific" вещи ессно писать надо самому. К тому же стараюсь просить разработчиков либ вставить то что не хватает. зачастую тыкают носом в то, что уже существует такое, просто не нашёл 

Велосипедисты — это дураки и гении. Либо обычные люди, но текущие решения убогие, а велосипед круче.

Раньше любил велосипеды писать  
Потом дошло что пустая трата времени, теперь сначала стараюсь найти подходящую либу  

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

Использую стандартные, свои еще писать неумею... 

Добавлено через 1 минуту и 18 секунд

        

Хороший аргумент.


Это как?

А вот не знаю.  Третий месяц длится эпопея.

Использую готовые либы, если их версия »0.1. 
Потому как они уже отлажены. 

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

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

Ну а в таких случаях, кто как предопочитает поступать?
С одной стороны свой лисапед занимает 15 строк кода, а либа пару килобайт.

LSD, сильно зависит от того, сколько времени уйдёт на поиск и установку либы. Вполне возможно, что такой велик я бы оставил, но взял на заметку и при следующей необходимости функции из Jcarta переписал бы под неё.

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

А ещё, скажите мне, плс, кто-нибудь станет реализовывать работу, к примеру, с картинками в формате PNG через свой велосипед? Это конечно можно, но, ИМХО, проще набрать в гугле png library. Видимо топикстартер имеет ввиду маленькие велосипедики?

ответил

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

Не только. На вопрос можно посмотреть шире: готовое решение, против самопального.
Я вот например знаю пару весьма крупных контор, которые предпочли писать свою ERP систему и держать штат программистов по поддержке, вместо чтобы пользоваться готовыми решениями.

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

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

Если для корзины предусмотрены крепления  

ИМХО свое лучше т.к.:
1) Будет глючить взял переделал, а вот глюки с совместимостью и т.д. устранить посложнее...
2) Доработка - взял впихнул ченить новенькое, коменты стоят тебе все понятно - стиль знакомый исходники всегда под рукой..
3) и т.д....)) много можно найти причин... 

Не аргумент. Готовые решения редко глючат. А если и глючат, то эти глюки исправляют быстрее и с большей надёжностью(меньше вероятность того, что исправление не принесло новых глюков).



Что за "глюки с совместимостью и т.д."?



Что мешает расширить ф-циональность готового решения?



Пока я их не вижу...
Я не спорю - причины найти можно всегда. Главный фактор - целесообразность. Но я сомневаюсь, что ты найдёшь целесообразные причины написания своего драйвера ФС(только потому, что "свое лучше").

  Стандартные по максимуму. Нужно жалеть тех, кто будут потом читать твой код. Чем меньше своих велосипедов, тем прозрачнее читается реализация алгоритма и тем легче искать в нем баги. Ведь при использовании велосипедов приходиться проверять еще и их на ошибки, чтобы гарантированно сузить область поиска.

archimed7592, 

Сам отвечаешь на свой вопрос: "драйвера", скажешь все работают устойчиво? И вдогонку, как ты расширишь функциональность готового драйвера? Ведь не всегда исходники достать можно, зачастую только дллки... 

Драйвер - это я утрировал(типа драйвер же ты не пишешь - ты используешь стандартную библиотеку).
Про устойчивость не понял - у тебя какие-то проблемы с доступом к ФС? Пишешь свои драйвера, чтобы решить эти проблемы? OMG 0_о



Так, чисто из интересу... Ты про паттерны проектирования в курсе?

Я тоже утрировал) Почему обязательно ФС?)



В курсе) Но не все же задачи можно решить "шаблонно") Или ты хочешь сказать что было бы гораздо проще взять один самый современный движок и начать писать все игры только на нем? 
Не зря же умные люди из больших компаний иногда пишут что-то свое... 

И про адаптер? И про декоратор? Тогда какие проблемы в добавлении новой ф-циональности?

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

Если она сделана не грамотно, то лучше сделать свой "велосипед", ибо готовое решение от Васи Пупкина, позавчера узнавшего что такое программирование - это не решение вовсе...

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

DragonFire, конкретнее, pls.
Вот у меня задача стоит: сертификация аеропортов. Там, помимо всего прочего нужны сложные геометрические расчёты. Я порыл в сети и набрёл на CGAL. Почти всё что мне нужно есть. Всё чего нет - добавляется несколькими движениями руки.
Иначе мне пришлось бы писать всю эту геометрическую мутату самому.
Ессно, не для любой задачи есть готовое решение - тогда нужно писать "велосипед". В этом нет ничего страшного.

Это сообщение отредактировал(а) archimed7592 - 26.10.2007, 22:27

Согласен существует много готовых библиотек с решениями математики или графики... несколько меньше - физики... Но например когда я занимался нейронными сетями тут все алгоритмы пришлось самому писать) 
А так, естественно, зачем писать свой VCL если есть готовый)) 

И здесь смотрел?



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

Так бы и сказал, что искать готовые решения лень .

Т.е. я хочу сказать, что если решение идёт с компилятором/IDE, то как правило о нём многие знают и используют эти решения. Если же для того, чтобы использовать решение придётся немного потрудиться(найти его, установать, научиться пользоваться, протестировать), то многие почему-то предпочитают свои велосипеды. Чисто из праздного интересу: а зачем? Уже всё есть. Уже всё отлажено. Возьми "с полки" и используй на здоровье, а если баг найдёшь, так за тебя его исправят, да ещё и спасибо скажут - тебе останется только установить патч.
Вот и спрашивается - зачем?
Взять, к примеру PDF. Я не знаю насколько у него сложен формат, да и знать не хочу - зачем мне забивать голову бинарным форматом, когда есть куча свободных библиотек, предоставляющих более высокоуровневый интерфейс к PDF.
XML... можно парсить руками - это не сложно... А зачем? Есть промышленный стандарт - DOM, с которым и работать приятней и не нужно ничего изобретать.
Для выделения подстрок можно использовать pos, indexOf, find или как эта ф-ция называется в вашем языке, а можно использовать библиотеку для регулярных выражений.
Во всех готовых решениях есть один минус: в них нужно разобраться, но... Неужели это сложнее, чем написать свой велосипед?
Зато плюсов у готовых решений немерено и я их уже приводил... основные из них:
1) научиться нужно лишь единожды - потом можно использовать это решение в любом проекте, сколько угодно раз.
2) готовые решения как правило написаны более качественно и продуманно, чем решение написаное с перепугу "а завтра же deadline".
3) готовые решения как правило содержат меньше багов, ибо ими пользуешься не только ты, но и "миллион лемингов"(которые не могут ошибаться )

В чем-то ты конечно прав но для меня существует два минуса готовых решений:
1) Недоступность кода (тот же VCL я могу в любое время просмотреть полностью, а практически все библиотеки поставляются именно как библиотеки, а не набор юнитов)
2) Цена (далеко не все решения бесплатны, а если писать корпоративный проект то в любом случае покупать весь софт придется...)
Но никто не говорил что PDF RAR и другие форматы надо читать ручками)) 

Осмелюсь предположить, что тебе эти коды и не нужны вовсе. Действительно... Зачем они тебе? 



Мммм... Мне кажется, что та же VCL тебе не бесплатно досталась? 



А какие надо? Именно надо. Т.е. в каких случаях не приемлется готовое решение и почему его нужно писать самому? Попробуй сформулировать критерии...

Хорошо написал, присоединяюсь. Добавлю еще один пункт.
4) Готовые решения продолжают развиваться, исправляться и улучшатся параллельно с твоим проектом. И в следующие релизы твоего продукта таким образом войдут не только человеко-часы твоей команды, но вся работа проделанная над сторонним продуктом его командой. Если не поленишься, конечно, следить за его развитием и обновлять версии.

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


Это зависит от технологий. В Java, к примеру, такой проблемы нет.


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

К сожалению пишу на C++ и ObjectPascal )) Хотя подмечено верно...  

Вопрос спорный) Но если его развивать еще пара страниц флуда появится... 

А я псих, пишу всё своё  

Предпочитаю объединять готовые либы в то, с чем мне удобно работать.

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

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

В итоге я бросаю это гиблое дело и начинаю писать всё сам. Мне реально проще придумать алгоритмы и написать свой OpenGL "c блек-джеком и шлюхами" чем разобраться в документации. 

В какой-то момент правда выясняется что задача это суровая, хоть и требует меньше мозга, но зато требует кучу времени. Я опять пытаюсь вникнуть в документацию и тут выясняется что "а у них же всё также как у меня"   . И собсно вникать уже нивочто не надо - и так уже почти всё ясно.

И тут я аккуратно прикручиваю чужую либу.   



Это сообщение отредактировал(а) Fieral - 10.2.2009, 18:56

Тут ситуация следующая: просто выкладывание библиотеки конечно ничего в ней не изменит, но вот когда ей начнут пользоваться другие тут уже появятся позитивные изменения недоступные велосипеду:
- массовое тестирование библиотеки, в условиях сильно отличающихся от условий разработчика
- обратная связь от пользователей, что в библиотеке хорошо, что плохо, что стоит добавить
- пользователи могут помочь с написанием документации, всякие  How to и Quick start
- если исходники открыты, к разработке могут подключится и сторонние разработчики, или проект может взять к себе кто нибудь типа Apache Software Foundation