Комментарии 85
Как бы появлялись существующие решения, если бы не было велосипедистов?
Ну из определения «велосипеда» (изобретения того, что уже есть), самая первая версия велосипедом не являлась.
Обычно так говорят все же о проектах, которых, ну прям ОЧЕНЬ много видов уже написано. Например, не знаю, какой-нибудь сишной либы конвертации utf* туда-обратно.
Вот как раз о таких вещах говорят «нет смысла изобретать велосипед».
А когда на рынке 1-2 библиотеки, и одна не подходит по лицензии, вторая по функциональности… что плохого написать третью?
(вещи связанные с безопасностью, конечно отдельная тема. я в основном про библиотеки общего назначения)
Некоторые идеи требуют глубокого изменения архитектуры популярных реализаций. А на это никто не пойдет, пока идея не докажет свою жизнеспособность или не будет иметь хотя бы рабочий прототип.
Поэтому тащить велосипед в production — нужно семь раз подумать. А вот выложить в opensource и обсудить с коллегами — нужно обязательно.
Как бы появлялись существующие решения, если бы не было велосипедистов?Ответ в тексте:
СпециалистПохоже, всё самое базовое и рисковое делается на бесприбыльной основе в open source.
Подавляющее большинство популярных библиотек написана именно им в свободное от основной работы время, так как всё ещё бьют по рукам как за велосипеды, так и за открытие исходников.
Вы это говорите исключительно с точки зрения коммерческого проекта, которым занимаетесь на работе?Да, я только это и имел в виду. Именно для такового опенсорсное решение по определению чужое. Именно для такового особенно критично количество затраченных человеко-часов.
А если я пишу OpenSource, я «по определению» не могу писать велосипед, даже если переизобретаю другое опенсорсное решение?Тут я, да, несколько «промахнулся». Можете, конечно. Но это будет за ваш счёт, а не за счёт коммерческого проекта.
Разумеется, чтоб научиться писать хорошо, надо писать много, и набрать требуемое для этого количество кода только на коммерческих проектах нереально. Разумеется, все проекты хотят разработчиков с навыками, но при этом никто не хочет, чтоб навык приобретался за счёт его проекта. Поэтому надо много писать «для себя», в «пет-проектах» и в опенсорсе. При этом надо понимать, что велосипеды неизбежны и что 90% написанного кода пойдут «в корзину».
Я думал, что речь идет о среднем времени, а не о сумме времени по всем issues.
Среднее и медиана хороши, когда создаваемые проблемы уравновешиваются решаемыми. Тогда можно взять статистику по решённым проблемам и прикинуть время решения очередной. Однако, как правило наблюдается динамика — проблемный долг либо растёт, либо падает. А чем больше долг, тем дольше будет решаться проблема. Представьте, что в проекте есть 100500 решённых на заре разработки задач однодневок, и есть 100500 годами открытых задач, так как проект давно забросили. Медиана будет 1 день, а на деле решения проблемы вы не дождётесь.
Чтобы лучше понять "время нерешения проблем", предлагаю взглянуть на следующую диаграмму:
210 |
2210 |
22210 | closed
---------------------------
2222 | 10 open
222 | 2210
22 | 222210
2 | 22222210
| 2222222210
|
past | futureПо вертикали — задачи, по горизонтали — дни. Числа показывают оставшийся объём работы по задаче в человеко-днях. 0 — задача завершена. Допустим над проектом работает 1 человек и решает проблемы в порядке их поступления. А каждый день кто-то создаёт ещё одну на 2 человеко-дня.
Статистика по завершённым задачам (левый верхний квадрант): в среднем 3 дня на задачу.
Проблемный долг (левый-нижний квадрант): 10 проблемо-дней
Фактически завершена задача будет (правый нижний квадрант): через 10 дней.
Да, может повезти и ваша проблема будет решена раньше, за счёт другой задачи, что уже есть в бэклоге. Но точно так же и за счёт вашей задачи может быть решена другая, более приоритетная. А поскольку приоритеты стороннего разработчика вы не контролируете, то стоит предполагать худшее.
Интересно было бы видеть еще какое-то отражение величины проекта (типа колво нерешенных багов на 100 строчек кода) и серьезность (но тут вроде из гитхаба унифицированно ее не извлечь?)
А поскольку приоритеты стороннего разработчика вы не контролируете, то стоит предполагать худшее.
На них можно влиять предоставлением своих ресурсом (деньги, патчи, форк)
Мой опыт с велосипедами весьма прост: почти всегда те велосипеды, с которыми я встречался в реальных проектах, обходились дороже в разработке и поддержке, чем использование готового стороннего решения. Особенно сильно это касается всяких велосипедов, связанных с безопасностью (свой OAuth2-клиент, например), или с типовыми сто раз реализованными задачами навроде логирования.
Это, несомненно, далеко не всегда так. Но в лично моем опыте это чаще так, чем иначе.
Если готовое решение надо допиливать и величина этих допилок превосходит хотя бы 25%, то уже надо подумать о велосипеде.
Если готовое решение не поддерживается, не особо развивается и не особо известно, то его скорее всего вообще лучше обойти стороной.
Если готовое решение надо допиливать и величина этих допилок превосходит хотя бы 25%, то уже надо подумать о велосипеде.25% видимо только от той части которая необходима, а не всего готового решения которое может содержать кучу не нужного, + нужно учесть затраты на изучение и интеграцию готового решения.
Если готовое решение не поддерживается, не особо развивается и не особо известно, то его скорее всего вообще лучше обойти стороной.
Не раз сталкивался с тем, что если все найденные готовые решения вот такие, то это значит, что я, как и авторы этих решений, где-то просчитался в архитектуре.
В итоге хранилище весьма шустро «завелосипедили». Всё отлично, всё работает. Но со временем в системе появлялось все больше модулей, которые используют хранилище для своих нужд, соответственно, требования к его функциональности возросли. Самые неприятные, с точки зрения усилий по реализации, касались конкурентного доступа к файлам и задач текущего обслуживания хранилища.
Очень похоже, что интеграция со специализированным хранилищем обошлась бы дешевле велосипеда. Собственно, в чем тут архитектурный просчет: на тот момент в используемом стеке технологий на стороне сервера приложений была только nodejs, и хотелось обойтись без добавления всяких tomcat'ов только ради «второстепенной» задачи. Стремились как раз таки сэкономить. Просчет не смертельный, но все же просчет.
Начинающим велосипеды писать нужно, это бесценный опыт. Но только для себя)))
Сколько я их в свое время написал… просто было интересно)
Зато теперь знаю как базы данных устроены изнутри… или как работают архиваторы и чем отличается динамическое кодирование Хаффмана от статического)))
А когда начал читать про битовые индексы в Оракл, то все было понятно с полуслова, так как такой велосипед я реализовывал, причем на не реляционных базах данных и даже в продакшене)))
Велосипедофобия — это частный случай обожествления best practices. Как и остальные best practices, "использовать готовое" — это всего лишь рекомендация, которую обязательно нужно рассмотреть в первую очередь, но совершенно не обязательно всегда ей следовать.
В статье был упомянут эффект Даннинга-Крюгера, в английской вики пишут что нет такого эффекта, а авторы исходной работы ошибочно интерпретировали данные (математически ошибочно):
When artifacts are eliminated, the evidence is strong that humans are generally correct in their self-assessments, with only a small percentage of the participants who were studied exhibiting performance that might merit the label "unskilled and unaware of it".
Наверное, надо бы поправить русскую вики, но с телефона сложно это, хотя в ней есть упоминание про шнобелевскую премию.
в английской вики пишут что нет такого эффекта
Неа, не пишут: "In the field of psychology, the Dunning–Kruger effect is a cognitive bias in which people..."
авторы исходной работы ошибочно интерпретировали данные (математически ошибочно)
Это заявление авторов двух конкретных работ. Его точно так же надо идти и проверять. Но, что важнее: "they support two other tenets of the original Kruger and Dunning research: [...] (2) experts usually self-assess themselves with better accuracy than do novices". Иными словами, эти две работы говорят не о том, что эффекта Даннинга-Крюгера не существует, а о том, что его проявления менее распространены и слабее выражены.
Забавно, как можно по разному одну статью прочитать. Сами эти две работы не читал, но мне хватило факта наличия их и наличия шнобелевской премии (ее так просто не дают).
Кстати приведенная цитата "they support two other tenets of the original Kruger and Dunning research: [...] (2) experts usually self-assess themselves with better accuracy than do novices" как я ее понимаю уже не про эффекь Даннинга-Крюгера а про какие-то два побочных вывода из их работы. Как я их понимаю:
(1) если обучиться методике себя оценивать, то ты будешь себя точнее оценивать (вроде и так очевидно:)))
(2) более опытные точнее оценивают свое умение чем новички — т. е. у более опытных дисперсия оценки ниже чем у новичков, имхо, если бы у новичков был бы байес к завышению то так бы и написали
Сами эти две работы не читал, но мне хватило факта наличия их и наличия шнобелевской премии (ее так просто не дают).
Вот только полезно почитать, за что же ее дают: to "honor achievements that first make people laugh, and then make them think".
какие-то два побочных вывода из их работы
"tenet: one of the principles on which a belief or theory is based"
У специалиста скорее всего получится не хуже, если он хорошо разберётся в проблематике и посоветуется с другими специалистами и профессионалами.
… напишет, отправит в эксплуатацию, исправит ошибки и учтет замечания пользователей, сделает редизайн на основе полученного опыта :)
Идея о том, что новый код лучше старого, явно абсурдна. Старый код использовался. Он протестирован. Множество багов было найдено и они были исправлены. И с этим все в порядке. Код не плодит баги просто валяясь на жестком диске. Как раз наоборот! Программное обеспечение — это что, старый Dodge Dart, который ржавеет просто простаивая в гараже? Это что, плюшевый мишка, который плохо выглядит, если не сделан исключительно из нового материала?
Вернемся обратно к двухстраничной функции. Да, я знаю, это простая функция для отображения окна, но она обросла мусором и прочим барахлом, и никто не знает почему. Ну так я скажу почему: это фиксы багов. Этот кусок исправляет баг, который случился у Нэнси, когда она пыталась установить всё на машину без IE. Этот — тот баг, который происходит при нехватке памяти. А этот — когда файл находится на дискете, а юзер ее выдернул посреди всего. Вот этот вот вызов LoadLibrary ужасен, но благодаря нему код работает на старых версиях Windows 95.
а) мне уже не нужна совместимость с Win 95, OS/2, и что там еще в библиотеке осталось;
б) код который хорошо работал с устройствами на Win2000 как-то криво работает на Windows 10
в) автор свою разработку забросил лет 10 назад
Вроде как там есть и куча накопленного багажа, но надо четко оценивать насколько он применим и нужен нам.
А так да, даже std::variant в C++ человек опытный скорее всего не повторит корректно
Идея о том, что новый код лучше старого, явно абсурдна. Старый код использовался. Он протестирован.
Ох, если бы он был протестирован. К сожалению качество большинства библиотек, которые можно найти в интернетах крайне низкое. И пока не попробуешь не узнаешь на сколько оно плохо работает.
Ну и груз обратной совместимости в подобных библиотеках высок.
Это если цель сделать что-то полезное, а не просто поучиться это делать. Т.е. как раз для новичков очень полезно писать свои маленькие учебные велосипедики. Или для старичков, которые новички в чем-то еще. В иных случаях как правило создание нового при существующем старом требует обоснования (есть x, y, z, но оно нам не подходит потому, что w).
Мне интересно качество самой лучшей из библиотек, для какой-то задачи а не большинства
Критерии выбора туманны: самая популярная не эквивалентна самой качественной.
Я просто к тому, что "самая лучшая" это обычно невыполнимо. Да, бывают алмазы, но чаще всего выбираешь между плохим и очень плохим.
Здесь же ещё всплывает проблема, что как-то эту вещицу нужно поддерживать, т.е. тратить свое время не только на непосредственно патчи, но и на согласование их с сообществом. Это бывает вообще невозможно и приходится форкать.
В общем если тупо, не думая, подключать абы что из обществнного репозитория, то все хорошо, если включать мозг, то затраты все равно большие, на исследование, развитие, общение с сообществом.
Приемущество общественного транспорта, а не собственного велосипеда, мне видится в первую очередь в снижении затрат непосредственно на кодинг, а над остальным приходится работать.
Наверное, это зависит от сообщества и задачи. Тупо, абы что не надо никогда. У нас есть выбор из n вариантов, один из них еще не готов и будет сделан вами. Тут вопрос насколько вы точно оцениваете трудоемкость доведения этого варианта до сравнимого с остальными качества. Как правило, в этом люди оптимистичны.
Еще, я думаю, большую часть, кода, которым вы пользуетесь, вы исключаете из рассмотрения (операционная система, sql server, язык, стандартный фреймворк).
Преимущество общественного транспорта, а не собственного велосипеда, мне видится в первую очередь в снижении затрат непосредственно на кодинг, а над остальным приходится работать.
Кодинг, тестинг (включая in production), документирование, обучение.
К сожалению качество большинства библиотек, которые можно найти в интернетах крайне низкое.
Спорное утверждение. Если звезд на гитхабе много — скорее всего качество норм.
Если звезд на гитхабе много — скорее всего качество норм.
Или библиотека поднялась на волне хайпа.
Например, в 2016 достаточно было написать слова react redux в Readme — и толпы фанатов с синдромом утенка были обеспечены. А на деле внутри может быть один файл на 20 строк с багами и часто без тестов.
Нашёл сходу в node_modules: https://www.npmjs.com/package/boolbase
2 миллиона скачиваний в неделю.
Исходник:
module.exports = {
trueFunc: function trueFunc(){
return true;
},
falseFunc: function falseFunc(){
return false;
}
};Странно, что без тестов. Дело лефтпада живёт.
То, что внутри тривиальная функциональность – это уже другой разговор. Главное, работает стабильно и не отсвечивает.
Надо ли говорить, что тестов на неё нет? Странно, что она не вынесена в отдельный модуль.
А почему? А потому что так привыкли. Синдром утенка в действии. Отсюда и регулярные скачивания в NPM набегают…
Вопрос, подходит ли популярный модуль под ваши задачи – это уже другая тема. Для этого есть другие методы.
— это действительно качественная вещь (реже)
— эта вещь была создана в нужном месте в нужное время (не обязательно первая в своем роде, а именно попавшая на гребень волны)
За примерами ходить далеко не надо – сам язык JavaScript.
Поэтому сервисы вроде npms.io оценивают пакеты не только по количеству скачиваний (popularity), но и по качеству (наличие тестов / CI / покрытия / документации) и по поддерживаемости (частота коммитов, кол-во открытых / закрытых issue и т.п.)
Горячо поддерживаю. Только опыт велосипедостроения сделает из среднего разработчика настоящего профессионала. Даже если ваш велосипед "не взлетит", это поможет на многие проблемы взглянуть на новом уровне понимания. Я частенько сталкиваюсь с ситуациями, когда написать велосипед написать тупо проще и быстрее, чем интегрировать и отлаживать стороннее решение. А еще в популярных либах бывает много протухшего легаси, избавиться от которого в перманентно раздуваемой сообществом кодовой базе становится очень затруднительно.
Она там есть по умолчанию в 200мс. Увеличил до секунды.
А с лимитами, да, приходится переключать VPN.
А напишите эту самописную функцию, пожалуйста. Потому что лет 7 назад кроссбраузерное решение занимало явно больше 10 строк.
await (await fetch('/api/path')).json()Для простого запроса такого хватит, а для сложных – вот тут был обзор библиотек.
А каким-нибудь bower можно это тринспилировать в ECMAScript 3? Я с современным миром JS не особо знаком, со многими вещами познакомился в статье https://habr.com/en/company/mailru/blog/340922/
Ради одной строчки кода транспиляцию запускать накладно, проще код переписать, чтобы он работал в InternetExplorer (остальным браузерам и так норм)
<script src="https://unpkg.com/promise-polyfill"></script>
<script src="https://unpkg.com/unfetch/polyfill"></script>
<script>
fetch('/api/path')
.then(function(res) {return res.json()})
.then(function(data) {
console.log(data);
})
</script>Почему накладно? Если писать на es2017 и транспилировать в ECMAScript 3 для большей совместимости?
Т.е.: те, кого били по рукам, начинают не просто бить по рукам, но ведут бездумную, яростную, фанатичную «охоту на ведьм». Они, не понимая почему их били по рукам, начинают бить по рукам всех без разбору, даже в том случае, когда «по их мнению, велосипед» является обоснованным и едва ли не единственным для данной ситуации решением.
Они не могут объяснить почему это плохо или хорошо; они знают что «есть типовое», а раз есть — его надо использовать любой ценой,
Они не понимают, что стандартные типовые решения, как и любые решения, имеют пусть и большую, но ограниченную область применения, и попытка воткнуть их «вот в этом конкретном случае» — будет не просто попыткой забивать экскаватором гвозди, она приведет к серьезным переработкам.
Как бы вы знали, как меня достала эта охота на ведьм! оох.
Товарищи! ) Давайте уже объяснять новичкам почему их бьют по рукам, и что иногда надо, надо, надо писать «велосипеды».
Поддерживаю автора — чем больше у вас опыта и понимания, тем больше шансов что ваш «велосипед», станет именно тем, что нужно тут и сейчас.
Велосипеды писать надо.
Даже не потому что это поможет им понять почему типовые решения сделаны так, как они сделаны.
Просто потому, что как минимум иногда проекту крайне необходимо решение, у которого
ps: тут, главное, не забыть сказать, что нельзя впадать в другую крайность: далеко не всегда такое 'частное велосипедное решение' стоит потом повторно использовать, или пускать в массы. Согласитесь — тонны новоявленных языков да фреймворков, которые рождаются буквально каждый день и дохнут так же быстро как стада леммингов при миграции — это как бы намекает, что нельзя все подряд велосипеды пытаться пускать в массовость )
Они могут быть трижды новичками и говнокодерами, но если конечный результат использует в проде куча народу, то скорее всего большинство явных косяков было найдено и исправлено (пусть даже медленно и мучительно). Сторонняя библиотека экономит не столько время разработки, сколько время тестирования. К «очередному leftpad»у этот аргумент, естественно, не относится.
У меня к велосипедам отношение простое. Если есть существующее решение, удовлетворяющее всем требованиям, то лучше взять его. Если нет — пишем велосипед. Опять же, помогает при спорах «велосипедофобами»: не нравится велосипед? — предложи альтернативу!
* Боязнь велосипедов, потому что много били по рукам. Не понимаю за что, ведь творчество это прекрасно.
* Неприятие велосипедов, потому что приходилось разгребать «творческий» код предшественников или тянуть основной функционал, пока коллеги занимались «творчеством».
Неоднократно приходилось наблюдать, как сотрудники удовлетворяют любопытство за счет проекта. Сюда можно отнести не только строительство велосипедов (в тяжелом случае это был свой UI фреймворк с нуля, в логистическом софте), но и желание попробовать новый фреймворк, с трехкратным переездом с одного на другой за год.
Ну и так далее, это конечно скорее о недобросовестных разработчиках, которым наплевать на работодателя и проект
Мне кажется, что у каждого, кто в одной области пишет достаточно много кода (скажем, открывает ide раз в неделю или чаще), должна быть библиотека или пакет под названием randomtooltips, abysshit или deephole, в которой находятся только ему ведомые функции и классы
Нелюблю собственные велосипеды. Или не туда едут, или туда но не доезжают.
Но не могу остановится их создавать и докручивать. Даже в ущерб деньгам, карьере, репутации, семье. Что делать?
Бояться нужно костылей, т.к. они нужны только калекам. А велосипеды для здоровых, ведущих активный образ жизни, людей.
И боятся люди не велосипедов, а того, что велосипед может обернуться костылем… Надо не бояться, а тренировать свои умения, садится на велосипед и ехать на нем. Без рук, без ног, любой стороной и только вперед.
Ну и, конечно, за своим велосипедом(впрочем как и костылем) нужно следить, обслуживать и обновлять периодически, что не нужно делать с чужими велосипедами))
Пример 1: раньше фичи не было, ты написал, сейчас появилась «из упаковки», но нет времени разбираться, тем более что сейчас любое «из упаковки» это какая-то магия; да ну ее; вот фича и стала велосипедом.
Пример 2: Или вот притащил кто-то условный автомапер, напирая «убирайте свои велосипеды», а тут вдруг сдвиг в головах происходит все начинают json из db таскать и весь код вокруг DTO, автомапера, биндинга сам становится велосипедом который конечно борец с велосипедами никогда не бросит.
Велосипедофобия