Самодостаточноть vs. Велосипедостроение

С этим сталкиваются студенты. Остальные при формировании ТЗ присутствуют. Если нет - ставить перед фактом.

С этим сталкиваются студенты.

То есть на момент офрмления ТЗ всё практически готово и остаётся только код «по чертежу» написать?

ТЗ оформляется не молниеносно. Время погуглить есть. Можно пробежать глазами варианты (я не только о библиотеках) и внести коррективы.

Да что за фобия такая - Велосипедостроение? :) Никто лучше тебя не сделает, НО если возникают такие вопросы

А если не выйдет?

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

обожаю писать велосипеды. Правда, часто недооцениваю сложность.

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

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

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

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

Сейчас велосипедю гораздо реже, но удобных случаев не упускаю. :)

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

А вдруг это будет Велосипедостроение?

Вы так говорите, как будто это что то плохое...

У меня свои потоки ввода/вывода, свои вектора (в декартовом пространстве), про массивы и средства визуализации и речи нету... коллеги этим с удовольствием пользуются;-)

Современное программирование на 100% состоит из применения готовых решений. Если ты навелосипедил хоть строчку кода, ты пионер, и тебе не место в профессии.

У меня свои потоки ввода/вывода, свои вектора (в декартовом пространстве), про массивы и средства визуализации и речи нету... коллеги этим с удовольствием пользуются

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

с удовольствием

Насчет удовольствия не факт. Вполне вероятно, что многие из коллег тебя тихонечко ненавидят.

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

Насчет удовольствия не факт. Вполне вероятно, что многие из коллег тебя тихонечко ненавидят.

Я спрошу;-)

Можно форкнуть библиотеку, выбросив из неё ненужный функционал.

Кто, на чьи деньги и в каком объеме будет искать в твоем форке уязвимости, чинить баги, развивать? Наличие «лишней» функциональности в либе тебя вообще волновать не должно, вместо этого нужно смотреть на наличие крупных пользователей, на качество кода, на допустимость лицензии...

а откуда боязнь фреймворков, если только ты не для микроконтроллера код пишешь? Тут уже вопрос: «вам шашечки или ехать»?

Даёшь каждой программе по своему XML/JSON/YAML/INI/другое парсеру!

«Библиотека» на самом деле является фреймворком и содержит кучу другого «не нужного» функционала.

Ути-пути.

Требуемый функционал реализован не полностью.

Ну тогда библиотека и не подходит. Требуемый функционал либо реализован, либо не реализован.

Код/API библиотеки ужасны.

Напиши няшную обёртку, это довольно легко и быстро.

Проблемы с лицензией.

Опенсорсные библиотеки сейчас 99% нужного функционала реализуют. Закрытые лицензии только у очень уж специфических библиотек, там действительно нужно либо писать сугубо под свои нужды, либо покупать, что уж.

Сталкиваетесь ли вы с подобными проблемами? Как обычно их решаете?

Сравниваем затраты на велосипединг и на внедрение и осваивание сторонней библиотеки.

XML/JSON/YAML/INI

Вот кстати во всех проектах, где я работал, INI-парсер - всегда свой :) В отличие от остальных форматов.

Если ты делаешь что-то похожее, но умеющее делать нечто, что готовое решение не умеет, то почему ты называешь это велосипедом, а не ноу-хау? Собственно вопрос и нужно так ставить: нужно ли проекту ноу-хау? Если проект не технологический, то скорее всего нет. Как тебе уже правильно предсказывают, обычно задачи в таких проектах подгоняются под инструменты. Если проект технологический, то не сделав value added, не сделаешь бизнеса. Такие дела.

голос из идеального мира

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

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

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