Здравствуйте, меня зовут Дмитрий Карловский, и я — профессиональный велосипедист. За всю свою карьеру я сделал кучу велосипедов: больших и маленьких, быстрых и удобных, кривых и прямых. Поэтому для меня довольно дико видеть толковых программистов, делающих большие и сложные приложения, но при этом подключающих к проекту очередной leftpad, вместо того, чтобы написать пару простых строк своими руками. Всему виной сформировавшаяся в среде программистов и поддерживающая сама себя боязнь велосипедов в продакшене.
Эволюция программиста
Для простоты изложения, выделим 3 условные группы программистов. Условные, потому, что между ними нет чёткой границы, а один и тот же человек в разных областях может принадлежать к разным группам.
Новичок
- У него ещё мало опыта и знаний, но он быстро усваивает новые, так как у него ещё нет устоявшихся привычек.
- Из-за эффекта новизны хорошо видит недостатки существующих решений и имеет сильное желание сделать своё, без этих недостатков.
- Он не знает как и почему сформировались те или иные практики и принципы, а если и знает, то не прочувствовал причины их появления на своей шкуре.
- Большая часть написанного им кода либо выбрасывается, либо рефакторится до неузнаваемости. В лучшем случае его же руками под директивными указаниями более опытных коллег.
- За написание велосипедов его нещадно бьют по руками, так как сторонняя библиотека с большей вероятностью окажется качественней по множеству критериев.
Специалист
- Подавляющее большинство популярных библиотек написана именно им в свободное от основной работы время, так как всё ещё бьют по рукам как за велосипеды, так и за открытие исходников.
- Как правило качество его кода соответствует среднему качеству кода в экосистеме. Если все пишут лапшу из колбэков, то и ему ничего не остаётся.
- Как правило использует сторонний код, так как его собственный не сильно лучше, а то и хуже из-за ограничений времени.
- Соответственно за велосипеды продолжает явно (на код-ревью) или неявно (баг-репортами) получать по рукам.
- Когда какая-то проблема его совсем достаёт, он пилит велосипед. А так как таких программистов большинство, получается 100500 не совместимых друг с другом велосипедов, поддерживаемых полутора разработчиками.
Профессионал
- Способен решить любую из проблем более качественно, чем в среднем по больнице, но из-за ограниченности ресурсов вынужден выбирать чему посвятить время.
- Ему по привычке бьют по рукам. Особенно, если в компании практикуют скрам, где все решения принимают большинством, подверженному эффекту Даннинга-Крюгера.
- Часто из-за сформированных на первых двух стадиях комплексов, он сам себя ограничивает и верит, что не способен сделать ничего лучше, чем сторонняя библиотека, которая "протестирована", "продумана", "поддерживается большим числом разработчиков".
Причины страха
Проследив эволюцию программиста, легко заметить, что сначала у него мало навыков, но нет страха, а по мере обретения навыков появляется и усиливается боязнь велосипедов. Чтобы справиться с этим страхом, нужно разобрать его причины.
Я не смогу сделать лучше
Новичок и правда не сможет. Ему стоит направить свои усилия на то, чтобы объяснить суть и важность проблем, которые он видит своим свежим взглядом, более опытным коллегам и разработчикам библиотек.
У специалиста скорее всего получится не хуже, если он хорошо разберётся в проблематике и посоветуется с другими специалистами и профессионалами.
Профессионал же способен сделать лучше в большинстве случаев, так как уже отлично разбирается в теме и даже имеет навык всестороннего анализа. К сожалению, проконсультироваться ему как правило не с кем, ибо других профессионалов мало, и они занимаются другими темами. А специалистам не хватает кругозора.
Некому будет чинить дефекты
Обычно автор велосипеда неплохо мотивирован чинить дефекты в своём детище. Но рано или поздно эта мотивация проходит, если делает он это в нерабочее время. И тут сторонняя библиотека, казалось бы, позволяет сэкономить ресурсы, ведь её поддержкой занимаются другие люди, которым не надо платить. Но повлиять на них не представляется возможным, а потому, чтобы успеть к дедлайну, придётся засучить рукава, и починить дефект своими силами, после чего долго и упорно пробивать свой патч в основной репозиторий, без какой-либо гарантии на успех.
Некому будет улучшать и развивать
Тут та же ситуация, что и с дефектами. Но если с дефектами всем обычно ясно, что их надо чинить, то вот взгляд на направление развития у всех разное. Сторонний разработчик будет развивать свою библиотеку туда, куда нужно ему, а не вам. С той скоростью, которая удобна ему, а не вам. Так что если требуется конкретный вектор развития, то свой велосипед даёт контроль и предсказуемость — два качества, которые для менеджмента куда важнее, чем временные и денежные затраты.
Я не смогу использовать это где-либо ещё
Если хочется использовать велосипед за пределами компании, то разрабатывать его придётся либо в свободное от работы время, либо договориться об открытии исходников, что обычно сложнее, но вполне возможно. Ведь компания практически бесплатно получает пиар в среде потенциальных работников, а так же бесплатных бета-тестеров (а то и контрибьюторов, но на это не стоит рассчитывать) в лице других пользователей велосипеда.
Время и деньги будут потрачены впустую
Тут прежде всего стоит сравнить с альтернативами. Если их нет, то и выбора нет — придётся пилить. Если же альтернативы есть, то тут стоит сравнить в денежном и временном эквиваленте:
- Стоимость написания своего велосипеда надлежащего качества. Сюда входит как собственно время написания кода, так и написание тестов, и перевод проекта на велосипед, и оценка стоимости привнесённых дефектов.
- Преимущества, которые даёт велосипед. Это может быть экономия за счёт определённых фичей, меньшего числа и стоимости дефектов, и другие факторы.
- Стоимость интеграции стороннего решения. Опять же включая оценку стоимости тестирования и привнесённых дефектов.
- Ограничения накладываемые сторонним решением. Тут может выясниться, что стороннее решение совсем не подходит. Или что оно замедлит разработку в 2 раза.
Также отдельно стоит оценить стоимость перехода со стороннего решения на велосипед, если вдруг выяснится, что какое-то из ограничений более неприемлемо. Часто бывает так, что выгоднее сейчас внедрить стороннее решение, а потом быстро перевести его на свой велосипед, когда (и если) потребуется, чем сейчас тратить время на велосипедостроение.
Данная оценка помогает как самому понять стоит ли игра свеч, так и объяснить менеджменту почему стоит написать своё, а не взять чужое (или наоборот).
Меня будут проклинать, как я проклинал предшественника
Сомнительно, чтобы велосипед занимал существенную долю проекта. Так что проклинать будут в большей степени за весь остальной код. Так что велосипед надо делать как минимум не хуже. А то и лучше, чтобы ни у кого не было желания заменить его на стороннюю библиотеку или на ещё один велосипед. Для этого нужно:
- Наличие явного, важного для проекта преимущества.
- Простой интерфейс использования, чтобы не приходилось делать свои обёртки вокруг.
- Гибкий API, чтобы не приходилось пилить новый велосипед при небольшом изменении требований.
- Хорошее покрытие тестами, что позволит меньше отсвечивать в баг-репортах и хорошо переживать рефакторинги.
- Исчерпывающая документация, чтобы не требовалось искать автора велосипеда, чтобы понять как на нём кататься.
Не хочу брать на себя ответственность
Это нормально, если вам наплевать на проект, над которым работаете. Если же вам не совсем всё-равно, чему посвящаете треть вашего времени за сутки, то придётся отстаивать свою точку зрения. И чем выше ваш статус, тем с большей ответственностью стоит подходить к тому, что говорить. Ведь от вашего голоса зависит не только как будете работать вы, но и как будут работать другие, и куда будет катиться проект в целом.
Рекомендации
Надеюсь мне удалось показать беспочвенность страхов перед велосипедами. Чем ближе вы к профессионализму, тем более амбициозные велосипеды можете на себя взять. Начинать лучше с велосипедов поменьше, имеющих меньшие риски, но дающие не мало опыта на этом поприще. И с этим портфолио браться за всё более крутые и интересные штуки. Важно только не забывать, что настоящий профессионал не только делает крутые штуки, но и знает когда стоит отказаться от их создания. Поэтому всегда проводите анализ, который и вам даст уверенности, что всё делаете правильно, и менеджмент будет на вашей стороне, и те, кто придут после вас, будут понимать что это за велосипед, зачем он тут, и почему иначе было нельзя.
Ну а чтобы помочь вам с анализом сторонних библиотек, я за вечер запилил приложение, позволяющее оценить время нерешения проблем проектов на ГитХабе. Чем больше число, тем хуже у проекта с поддержой, и тем дольше вам придётся ждать решения вашей проблемы. Например: сравнение Angular, VueJS, React и конечно же $mol, на котором этот велосипед и написан. Имейте ввиду, что последняя ссылка одноразовая, так как выкачивание всех открытых проблем Ангуляра выедает все лимиты ГитХаба, что красноречиво показывает, что его мейнтейнеры не справляются с поддержкой монстра, которого породили.
Комментарии (69)
SDKiller
07.01.2019 01:39Похоже, что-то не так у вас с методикой подсчета
timdorohin
07.01.2019 02:03Правильно всё, там в полно открытых вопросов с 13-14 годов, а общее число открытых переваливает за семьсот. Самому старому — 2026 дней.
SDKiller
07.01.2019 02:13Я думал, что речь идет о среднем времени, а не о сумме времени по всем issues.
timdorohin
07.01.2019 02:28С точки зрения статистики вообще лучше медианное брать, но это уже на совести автора)
vintage Автор
07.01.2019 08:48Среднее и медиана хороши, когда создаваемые проблемы уравновешиваются решаемыми. Тогда можно взять статистику по решённым проблемам и прикинуть время решения очередной. Однако, как правило наблюдается динамика — проблемный долг либо растёт, либо падает. А чем больше долг, тем дольше будет решаться проблема. Представьте, что в проекте есть 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 дней.
Да, может повезти и ваша проблема будет решена раньше, за счёт другой задачи, что уже есть в бэклоге. Но точно так же и за счёт вашей задачи может быть решена другая, более приоритетная. А поскольку приоритеты стороннего разработчика вы не контролируете, то стоит предполагать худшее.
ApeCoder
07.01.2019 13:09Интересно было бы видеть еще какое-то отражение величины проекта (типа колво нерешенных багов на 100 строчек кода) и серьезность (но тут вроде из гитхаба унифицированно ее не извлечь?)
А поскольку приоритеты стороннего разработчика вы не контролируете, то стоит предполагать худшее.
На них можно влиять предоставлением своих ресурсом (деньги, патчи, форк)
lair
07.01.2019 03:24+1Мой опыт с велосипедами весьма прост: почти всегда те велосипеды, с которыми я встречался в реальных проектах, обходились дороже в разработке и поддержке, чем использование готового стороннего решения. Особенно сильно это касается всяких велосипедов, связанных с безопасностью (свой OAuth2-клиент, например), или с типовыми сто раз реализованными задачами навроде логирования.
Это, несомненно, далеко не всегда так. Но в лично моем опыте это чаще так, чем иначе.
aosja
07.01.2019 10:03Согласен. Поэтому, вкатываться в продакшен на своем велосипеде надо аккуратно и всегда продумывать варианты отступления.
edogs
07.01.2019 04:14Всегда есть критическая точка когда нужно писать велосипед, а когда нужно не писать.
Если готовое решение надо допиливать и величина этих допилок превосходит хотя бы 25%, то уже надо подумать о велосипеде.
Если готовое решение не поддерживается, не особо развивается и не особо известно, то его скорее всего вообще лучше обойти стороной.lega
07.01.2019 10:56Если готовое решение надо допиливать и величина этих допилок превосходит хотя бы 25%, то уже надо подумать о велосипеде.
25% видимо только от той части которая необходима, а не всего готового решения которое может содержать кучу не нужного, + нужно учесть затраты на изучение и интеграцию готового решения.
kuza2000
07.01.2019 04:43Замечательная статья!
Начинающим велосипеды писать нужно, это бесценный опыт. Но только для себя)))
Сколько я их в свое время написал… просто было интересно)
Зато теперь знаю как базы данных устроены изнутри… или как работают архиваторы и чем отличается динамическое кодирование Хаффмана от статического)))
А когда начал читать про битовые индексы в Оракл, то все было понятно с полуслова, так как такой велосипед я реализовывал, причем на не реляционных базах данных и даже в продакшене)))Flammar
07.01.2019 16:12Мне в своё время пришлось написать три фреймворка на аннотациях и один фреймворк для математических расчётов с использованием JPA и динамическим формированием JPA-запросов. Конечно, всё это были «велосипеды», но опыт действительно бесценный.
Scf
07.01.2019 08:51Велосипедофобия — это частный случай обожествления best practices. Как и остальные best practices, "использовать готовое" — это всего лишь рекомендация, которую обязательно нужно рассмотреть в первую очередь, но совершенно не обязательно всегда ей следовать.
Flammar
07.01.2019 16:19+1Мне кажется, велосипедофобия — это ещё и способ избегания потенциальной лишней ответственности.
DmitryOgn
07.01.2019 22:03+2Ни разу не видел, чтобы кто-то отвечал за управленческие ошибки. Особенно если они сопровождаются вербально-двигательной гиперактивностью инициативного сотрудника.
Все это отмечается как «разработал», «внедрил». Разгребает всегда кто-то другой.
rinaty
07.01.2019 09:13В статье был упомянут эффект Даннинга-Крюгера, в английской вики пишут что нет такого эффекта, а авторы исходной работы ошибочно интерпретировали данные (математически ошибочно):
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".
Наверное, надо бы поправить русскую вики, но с телефона сложно это, хотя в ней есть упоминание про шнобелевскую премию.
lair
07.01.2019 11:56в английской вики пишут что нет такого эффекта
Неа, не пишут: "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". Иными словами, эти две работы говорят не о том, что эффекта Даннинга-Крюгера не существует, а о том, что его проявления менее распространены и слабее выражены.
rinaty
07.01.2019 14:22Забавно, как можно по разному одну статью прочитать. Сами эти две работы не читал, но мне хватило факта наличия их и наличия шнобелевской премии (ее так просто не дают).
Кстати приведенная цитата "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) более опытные точнее оценивают свое умение чем новички — т. е. у более опытных дисперсия оценки ниже чем у новичков, имхо, если бы у новичков был бы байес к завышению то так бы и написалиlair
07.01.2019 14:28+1Сами эти две работы не читал, но мне хватило факта наличия их и наличия шнобелевской премии (ее так просто не дают).
Вот только полезно почитать, за что же ее дают: 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"
rinaty
07.01.2019 15:02Но по факту где-то 80% работ получивших премию это реальный треш. Начиная гомеопатами и заканчивая Лукашенко.
ApeCoder
07.01.2019 10:22У специалиста скорее всего получится не хуже, если он хорошо разберётся в проблематике и посоветуется с другими специалистами и профессионалами.
… напишет, отправит в эксплуатацию, исправит ошибки и учтет замечания пользователей, сделает редизайн на основе полученного опыта :)
Идея о том, что новый код лучше старого, явно абсурдна. Старый код использовался. Он протестирован. Множество багов было найдено и они были исправлены. И с этим все в порядке. Код не плодит баги просто валяясь на жестком диске. Как раз наоборот! Программное обеспечение — это что, старый Dodge Dart, который ржавеет просто простаивая в гараже? Это что, плюшевый мишка, который плохо выглядит, если не сделан исключительно из нового материала?
Вернемся обратно к двухстраничной функции. Да, я знаю, это простая функция для отображения окна, но она обросла мусором и прочим барахлом, и никто не знает почему. Ну так я скажу почему: это фиксы багов. Этот кусок исправляет баг, который случился у Нэнси, когда она пыталась установить всё на машину без IE. Этот — тот баг, который происходит при нехватке памяти. А этот — когда файл находится на дискете, а юзер ее выдернул посреди всего. Вот этот вот вызов LoadLibrary ужасен, но благодаря нему код работает на старых версиях Windows 95.mapron
07.01.2019 11:30Цитата хорошая, но что если библиотека хорошая, проверенная, но:
а) мне уже не нужна совместимость с Win 95, OS/2, и что там еще в библиотеке осталось;
б) код который хорошо работал с устройствами на Win2000 как-то криво работает на Windows 10
в) автор свою разработку забросил лет 10 назад
Вроде как там есть и куча накопленного багажа, но надо четко оценивать насколько он применим и нужен нам.
А так да, даже std::variant в C++ человек опытный скорее всего не повторит корректно
acmnu
07.01.2019 12:29+4Идея о том, что новый код лучше старого, явно абсурдна. Старый код использовался. Он протестирован.
Ох, если бы он был протестирован. К сожалению качество большинства библиотек, которые можно найти в интернетах крайне низкое. И пока не попробуешь не узнаешь на сколько оно плохо работает.
Ну и груз обратной совместимости в подобных библиотеках высок.
ApeCoder
07.01.2019 12:56Мне интересно качество самой лучшей из библиотек, для какой-то задачи а не большинства. Всегда надо оценивать, что платишь, и что за это получаешь. Но сначала надо хотя бы понять что люди делали до этого когда столкнулись с такой же проблемой. Например, если пишешь статью про велосипеды, надо прочитать существующие статьи, и дописать свое, проставив ссылочки. Про Build vs Buy написана куча материалов — вполне можно их дополнить какими-то своими мыслями или обобщить.
Это если цель сделать что-то полезное, а не просто поучиться это делать. Т.е. как раз для новичков очень полезно писать свои маленькие учебные велосипедики. Или для старичков, которые новички в чем-то еще. В иных случаях как правило создание нового при существующем старом требует обоснования (есть x, y, z, но оно нам не подходит потому, что w).acmnu
07.01.2019 14:02Мне интересно качество самой лучшей из библиотек, для какой-то задачи а не большинства
Критерии выбора туманны: самая популярная не эквивалентна самой качественной.
ApeCoder
07.01.2019 14:11Критерии выбора ваши. Что для вас важнее.
acmnu
07.01.2019 14:19Я просто к тому, что "самая лучшая" это обычно невыполнимо. Да, бывают алмазы, но чаще всего выбираешь между плохим и очень плохим.
Здесь же ещё всплывает проблема, что как-то эту вещицу нужно поддерживать, т.е. тратить свое время не только на непосредственно патчи, но и на согласование их с сообществом. Это бывает вообще невозможно и приходится форкать.
В общем если тупо, не думая, подключать абы что из обществнного репозитория, то все хорошо, если включать мозг, то затраты все равно большие, на исследование, развитие, общение с сообществом.
Приемущество общественного транспорта, а не собственного велосипеда, мне видится в первую очередь в снижении затрат непосредственно на кодинг, а над остальным приходится работать.
ApeCoder
07.01.2019 14:47Наверное, это зависит от сообщества и задачи. Тупо, абы что не надо никогда. У нас есть выбор из n вариантов, один из них еще не готов и будет сделан вами. Тут вопрос насколько вы точно оцениваете трудоемкость доведения этого варианта до сравнимого с остальными качества. Как правило, в этом люди оптимистичны.
Еще, я думаю, большую часть, кода, которым вы пользуетесь, вы исключаете из рассмотрения (операционная система, sql server, язык, стандартный фреймворк).
Преимущество общественного транспорта, а не собственного велосипеда, мне видится в первую очередь в снижении затрат непосредственно на кодинг, а над остальным приходится работать.
Кодинг, тестинг (включая in production), документирование, обучение.
YemSalat
08.01.2019 19:12К сожалению качество большинства библиотек, которые можно найти в интернетах крайне низкое.
Спорное утверждение. Если звезд на гитхабе много — скорее всего качество норм.gnaeus
08.01.2019 19:33Если звезд на гитхабе много — скорее всего качество норм.
Или библиотека поднялась на волне хайпа.
YemSalat
08.01.2019 19:50Это да, но хайп на корявом коде возникает не так уж часто.
gnaeus
08.01.2019 19:58А хайп возникает не на коде этой конкретной библиотеки, а на основном фреймворке.
Например, в 2016 достаточно было написать слова react redux в Readme — и толпы фанатов с синдромом утенка были обеспечены. А на деле внутри может быть один файл на 20 строк с багами и часто без тестов.justboris
08.01.2019 20:30Поэтому можно еще смотреть на число скачиваний с NPM. Если уж библиотека попала в зависимости, значит она решает какую-то задачу для пользователей. Установить модуль все-таки побольше усилий требует, чем поставить звездочку на гитхабе.
vintage Автор
08.01.2019 20:40+1Нашёл сходу в node_modules: https://www.npmjs.com/package/boolbase
2 миллиона скачиваний в неделю.
Исходник:
module.exports = { trueFunc: function trueFunc(){ return true; }, falseFunc: function falseFunc(){ return false; } };
Странно, что без тестов. Дело лефтпада живёт.
justboris
08.01.2019 20:45Скачивается два миллиона раз и не ломает никому сборку? Так это же замечательно!
То, что внутри тривиальная функциональность – это уже другой разговор. Главное, работает стабильно и не отсвечивает.vintage Автор
08.01.2019 21:22Это говорит о качестве того, что её использует. Например, используется она в css-select, где можно найти свою кривую процедуру сортировки пузырьком: github.com/fb55/css-select/blob/master/lib/sort.js#L23
Надо ли говорить, что тестов на неё нет? Странно, что она не вынесена в отдельный модуль.justboris
08.01.2019 23:41Вот видите, популярность библиотеки привлекла ваше внимание и вы указали на проблемные места. Если бы не популярность, то все было бы точно так же, только еще и без внимания.
vintage Автор
09.01.2019 07:01Это я случайно тыкнул в один модуль из 900, чтобы показать как там всё плохо. Обычно я в эту помойку не лажу. Без толку это.
gnaeus
08.01.2019 20:44В идеальном мире — да. А в современном вебе разработчики чаще эти проблемы сами себе и создают. Постоянно вижу чуть ли не лендинги с redux, saga и еще десятком библиотек типа redux-bla-bla-bla. Хотя там и cам Redux-то не нужен. И даже Дэн об этом писал.
А почему? А потому что так привыкли. Синдром утенка в действии. Отсюда и регулярные скачивания в NPM набегают…justboris
08.01.2019 20:54Изначально был вопрос о критериях качества. И библиотеки с большим числом скачиваний как правило качественнее менее популярных аналогов.
Вопрос, подходит ли популярный модуль под ваши задачи – это уже другая тема. Для этого есть другие методы.gnaeus
08.01.2019 21:05Ну а я утверждаю, что популярность не является критерием качества. Это всего лишь эвристика. Популярность библиотеки / языка / фреймворка говорит об одном из двух:
— это действительно качественная вещь (реже)
— эта вещь была создана в нужном месте в нужное время (не обязательно первая в своем роде, а именно попавшая на гребень волны)
За примерами ходить далеко не надо – сам язык JavaScript.
Поэтому сервисы вроде npms.io оценивают пакеты не только по количеству скачиваний (popularity), но и по качеству (наличие тестов / CI / покрытия / документации) и по поддерживаемости (частота коммитов, кол-во открытых / закрытых issue и т.п.)
i360u
07.01.2019 11:03+1Горячо поддерживаю. Только опыт велосипедостроения сделает из среднего разработчика настоящего профессионала. Даже если ваш велосипед "не взлетит", это поможет на многие проблемы взглянуть на новом уровне понимания. Я частенько сталкиваюсь с ситуациями, когда написать велосипед написать тупо проще и быстрее, чем интегрировать и отлаживать стороннее решение. А еще в популярных либах бывает много протухшего легаси, избавиться от которого в перманентно раздуваемой сообществом кодовой базе становится очень затруднительно.
ApeCoder
07.01.2019 11:08Я частенько сталкиваюсь с ситуациями, когда написать велосипед написать тупо проще и быстрее, чем интегрировать и отлаживать стороннее решение.
Имхо, это значит что у вас не велосипед а нечто другое со своими требованиями.
justboris
07.01.2019 12:11В демо-приложении стоило бы добавить буферизацию ввода, и не ходить на сервер после каждого нажатия. Github API быстро исчерпал лимит и забанил мой IP на час
vintage Автор
07.01.2019 12:33Она там есть по умолчанию в 200мс. Увеличил до секунды.
А с лимитами, да, приходится переключать VPN.
vdem
07.01.2019 12:34+5Часто вижу, что например jQuery подключается на странице практически только из-за необходимости отправлять AJAX запросы, хотя самописная функция умещается в 10 строк. Раздражает повсеместно распространенная практика на любой чих подключать сразу какой-то готовый плагин с целой кучей совершенно ненужных фич. Страничка с парой десятков подключаемых скриптов — это полный мрак, особенно если они начинают конфликтовать. Лучше написать свой велосипед в 10-20-100 строк, чем подключать БелАЗ 200Kb размером (сжатым!).
humbug
07.01.2019 22:47А напишите эту самописную функцию, пожалуйста. Потому что лет 7 назад кроссбраузерное решение занимало явно больше 10 строк.
justboris
07.01.2019 23:07+1await (await fetch('/api/path')).json()
Для простого запроса такого хватит, а для сложных – вот тут был обзор библиотек.
vdem
07.01.2019 23:20А я уже думал двумя вариантами ответить, с поддержкой старых IE (через ActiveX, там действительно намного больше строк, и всё равно не повод только из-за этого подключать jQuery — хотя в том случае поводов было бы намного больше, из-за чего jQuery и появился) и новых, вот там порядка 10 строк достаточно. Но ваш вариант круче, надо подучить новые возможности JS.
dplsoft
07.01.2019 16:29+1Я наблюдал высшую степень «велосеподофобии», когда фобия начинает поглощаться «стокгольмским синдромом» вместе с «синдромом мокрой обезьяны и непритрагиваемого банана».
Т.е.: те, кого били по рукам, начинают не просто бить по рукам, но ведут бездумную, яростную, фанатичную «охоту на ведьм». Они, не понимая почему их били по рукам, начинают бить по рукам всех без разбору, даже в том случае, когда «по их мнению, велосипед» является обоснованным и едва ли не единственным для данной ситуации решением.
Они не могут объяснить почему это плохо или хорошо; они знают что «есть типовое», а раз есть — его надо использовать любой ценой,т.е. использование типового решения становится самоцелью, а не средством решения проблемbabylon
09.01.2019 03:50Поддерживаю автора — чем больше у вас опыта и понимания, тем больше шансов что ваш «велосипед», станет именно тем, что нужно тут и сейчас.
Фразу можно построить с конца. Если ваш велосипед стал тем, что уже есть здесь и сейчас тем больше у вас опыта и понимания. Такие велосипеды я собирал. Вопрос- зачем? Когда собираешь свой не всегда знаешь как использовать существующий. Хотя и знаешь про его наличие. Зависит от сложности механизма.
Flammar
07.01.2019 16:40Теоретически, яростная велосипедофобия может привести к снижению качества кода и его разбуханию. Потому что копипаст и прочее дублирование кода — это типа не велосипедостроение, а рефакторинг с вынесением кода в общие куски ведёт к появлению каких-то самопальных библиотек, которые всегда можно назвать «велосипедом» и заявить, что вместо их написания надо использовать какие-нибудь сторонние протестированные библиотеки.
vsb
07.01.2019 18:53+1Популярные сторонние библиотеки хороши тем, что они, как правило, хорошо протестированы, чего не скажешь о своём коде. А качество кода в случае библиотек значения не имеет. Почитайте ужасы об коде СУБД Оракл. Однако же это не мешает ей прекрасно работать, а всё благодаря огромному множеству тестов. Впрочем соглашусь, что впадать в крайности не стоит.
tmaxx
07.01.2019 20:28Я не против велосипедов, у самого их немало. Но сторонние библиотеки все-таки содержат меньше багов (в среднем), причем это не имеет никакого отношения к профессионализму авторов.
Они могут быть трижды новичками и говнокодерами, но если конечный результат использует в проде куча народу, то скорее всего большинство явных косяков было найдено и исправлено (пусть даже медленно и мучительно). Сторонняя библиотека экономит не столько время разработки, сколько время тестирования. К «очередному leftpad»у этот аргумент, естественно, не относится.
У меня к велосипедам отношение простое. Если есть существующее решение, удовлетворяющее всем требованиям, то лучше взять его. Если нет — пишем велосипед. Опять же, помогает при спорах «велосипедофобами»: не нравится велосипед? — предложи альтернативу!
DmitryOgn
07.01.2019 21:56+1Сравните две фразы:
* Боязнь велосипедов, потому что много били по рукам. Не понимаю за что, ведь творчество это прекрасно.
* Неприятие велосипедов, потому что приходилось разгребать «творческий» код предшественников или тянуть основной функционал, пока коллеги занимались «творчеством».
Неоднократно приходилось наблюдать, как сотрудники удовлетворяют любопытство за счет проекта. Сюда можно отнести не только строительство велосипедов (в тяжелом случае это был свой UI фреймворк с нуля, в логистическом софте), но и желание попробовать новый фреймворк, с трехкратным переездом с одного на другой за год.iago
08.01.2019 00:33+1Подпишусь под каждым словом, видел не раз как при отсутствии должного контроля (который вроде бы и не подразумевается для сеньоров) люди пишут велосипеды просто потому, что интересно. Давайте свою базу данных на файлах с самописной хэш-функцией запилим. А теперь давайте свой рендерер вьюшек напишем. Ну допустим в нем не поддерживается анимация, зато он может показать в 5 раз больше данных на одном экране! А, столько не надо? Ну а вдруг понадобится?
Ну и так далее, это конечно скорее о недобросовестных разработчиках, которым наплевать на работодателя и проект
x67
07.01.2019 23:10Мне кажется, что у каждого, кто в одной области пишет достаточно много кода (скажем, открывает ide раз в неделю или чаще), должна быть библиотека или пакет под названием randomtooltips, abysshit или deephole, в которой находятся только ему ведомые функции и классы
numitus2
08.01.2019 03:42Половину статей с хабра которые описывают «перегибы на местах» можно описать цитатой из Звездных Войн: «Только ситхи возводят все в абсолют»
phantom-code
Как бы появлялись существующие решения, если бы не было велосипедистов? Велосипеды нужны, как минимум для самообразования. Я считаю, что каждый нормальный программист должен попробовать реализовать что-нибудь вроде красно-черного дерева или даже компилятора для своего языка программирования. В процессе появляется более глубокое понимание предметной области, а так же приобретается уникальный опыт. Конечно, в большинстве случаев, подобные велосипеды не следует использовать в production. Для достижения высокого качества, велосипед нужно шлифовать годами, уделяя ему неприлично много времени. По сути, он должен стать основной, решаемой разработчиком задачей.
mapron
Ну из определения «велосипеда» (изобретения того, что уже есть), самая первая версия велосипедом не являлась.
Обычно так говорят все же о проектах, которых, ну прям ОЧЕНЬ много видов уже написано. Например, не знаю, какой-нибудь сишной либы конвертации utf* туда-обратно.
Вот как раз о таких вещах говорят «нет смысла изобретать велосипед».
А когда на рынке 1-2 библиотеки, и одна не подходит по лицензии, вторая по функциональности… что плохого написать третью?
(вещи связанные с безопасностью, конечно отдельная тема. я в основном про библиотеки общего назначения)
gnaeus
Даже когда уже есть 100500 реализаций одного и того же, велосипеды служат инкубатором идей для новых версий мейнстримных проектов.
Некоторые идеи требуют глубокого изменения архитектуры популярных реализаций. А на это никто не пойдет, пока идея не докажет свою жизнеспособность или не будет иметь хотя бы рабочий прототип.
Поэтому тащить велосипед в production — нужно семь раз подумать. А вот выложить в opensource и обсудить с коллегами — нужно обязательно.
Flammar
phantom-code
Однако открытый/бесплатный велосипед тоже является велосипедом. Где та граница, после которой велосипед переходит в категорию «существующее решение»? Если разработчик посвящает всё свое время (или большую его часть) велосипеду, то рано или поздно он доведет его до состояния «существующего решения». Если же велосипед написан второпях, плохо оттестирован, в нем отсутствует функциональность, имеющаяся в других готовых решениях, и он фактически просто затыкает какую-то дыру в проекте — это безусловно самый обычный велосипед.
Flammar
Однако открытый/бесплатный велосипед является в первую очередь открытым, а только во вторую, и то необязательно — велосипедом. Велосипед — это переизобретение чужого решения, опенсорсное же решение по определению чужое, и поэтому не может быть названо велосипедом.
phantom-code
Вы это говорите исключительно с точки зрения коммерческого проекта, которым занимаетесь на работе? А если я пишу OpenSource, я «по определению» не могу писать велосипед, даже если переизобретаю другое опенсорсное решение? Это все конечно придирки, просто я не совсем понял вашу мысль.
Flammar
Разумеется, чтоб научиться писать хорошо, надо писать много, и набрать требуемое для этого количество кода только на коммерческих проектах нереально. Разумеется, все проекты хотят разработчиков с навыками, но при этом никто не хочет, чтоб навык приобретался за счёт его проекта. Поэтому надо много писать «для себя», в «пет-проектах» и в опенсорсе. При этом надо понимать, что велосипеды неизбежны и что 90% написанного кода пойдут «в корзину».