Велосипедофобия

Здравствуйте, меня зовут Дмитрий Карловский, и я — профессиональный велосипедист. За всю свою карьеру я сделал кучу велосипедов: больших и маленьких, быстрых и удобных, кривых и прямых. Поэтому для меня довольно дико видеть толковых программистов, делающих большие и сложные приложения, но при этом подключающих к проекту очередной leftpad, вместо того, чтобы написать пару простых строк своими руками. Всему виной сформировавшаяся в среде программистов и поддерживающая сама себя боязнь велосипедов в продакшене.


Я почему раньше злой был? У меня просто велосипеда не было.


Эволюция программиста


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


Новичок


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

Специалист


  • Подавляющее большинство популярных библиотек написана именно им в свободное от основной работы время, так как всё ещё бьют по рукам как за велосипеды, так и за открытие исходников.
  • Как правило качество его кода соответствует среднему качеству кода в экосистеме. Если все пишут лапшу из колбэков, то и ему ничего не остаётся.
  • Как правило использует сторонний код, так как его собственный не сильно лучше, а то и хуже из-за ограничений времени.
  • Соответственно за велосипеды продолжает явно (на код-ревью) или неявно (баг-репортами) получать по рукам.
  • Когда какая-то проблема его совсем достаёт, он пилит велосипед. А так как таких программистов большинство, получается 100500 не совместимых друг с другом велосипедов, поддерживаемых полутора разработчиками.

Профессионал


  • Способен решить любую из проблем более качественно, чем в среднем по больнице, но из-за ограниченности ресурсов вынужден выбирать чему посвятить время.
  • Ему по привычке бьют по рукам. Особенно, если в компании практикуют скрам, где все решения принимают большинством, подверженному эффекту Даннинга-Крюгера.
  • Часто из-за сформированных на первых двух стадиях комплексов, он сам себя ограничивает и верит, что не способен сделать ничего лучше, чем сторонняя библиотека, которая "протестирована", "продумана", "поддерживается большим числом разработчиков".

Причины страха


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


Я не смогу сделать лучше


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


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


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


Некому будет чинить дефекты


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


Некому будет улучшать и развивать


Тут та же ситуация, что и с дефектами. Но если с дефектами всем обычно ясно, что их надо чинить, то вот взгляд на направление развития у всех разное. Сторонний разработчик будет развивать свою библиотеку туда, куда нужно ему, а не вам. С той скоростью, которая удобна ему, а не вам. Так что если требуется конкретный вектор развития, то свой велосипед даёт контроль и предсказуемость — два качества, которые для менеджмента куда важнее, чем временные и денежные затраты.


Я не смогу использовать это где-либо ещё


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


Время и деньги будут потрачены впустую


Тут прежде всего стоит сравнить с альтернативами. Если их нет, то и выбора нет — придётся пилить. Если же альтернативы есть, то тут стоит сравнить в денежном и временном эквиваленте:


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

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


Данная оценка помогает как самому понять стоит ли игра свеч, так и объяснить менеджменту почему стоит написать своё, а не взять чужое (или наоборот).


Меня будут проклинать, как я проклинал предшественника


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


  1. Наличие явного, важного для проекта преимущества.
  2. Простой интерфейс использования, чтобы не приходилось делать свои обёртки вокруг.
  3. Гибкий API, чтобы не приходилось пилить новый велосипед при небольшом изменении требований.
  4. Хорошее покрытие тестами, что позволит меньше отсвечивать в баг-репортах и хорошо переживать рефакторинги.
  5. Исчерпывающая документация, чтобы не требовалось искать автора велосипеда, чтобы понять как на нём кататься.

Не хочу брать на себя ответственность


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


Рекомендации


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


Ну а чтобы помочь вам с анализом сторонних библиотек, я за вечер запилил приложение, позволяющее оценить время нерешения проблем проектов на ГитХабе. Чем больше число, тем хуже у проекта с поддержой, и тем дольше вам придётся ждать решения вашей проблемы. Например: сравнение Angular, VueJS, React и конечно же $mol, на котором этот велосипед и написан. Имейте ввиду, что последняя ссылка одноразовая, так как выкачивание всех открытых проблем Ангуляра выедает все лимиты ГитХаба, что красноречиво показывает, что его мейнтейнеры не справляются с поддержкой монстра, которого породили.

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 85

    +8
    Как бы появлялись существующие решения, если бы не было велосипедистов? Велосипеды нужны, как минимум для самообразования. Я считаю, что каждый нормальный программист должен попробовать реализовать что-нибудь вроде красно-черного дерева или даже компилятора для своего языка программирования. В процессе появляется более глубокое понимание предметной области, а так же приобретается уникальный опыт. Конечно, в большинстве случаев, подобные велосипеды не следует использовать в production. Для достижения высокого качества, велосипед нужно шлифовать годами, уделяя ему неприлично много времени. По сути, он должен стать основной, решаемой разработчиком задачей.
      +3
      Как бы появлялись существующие решения, если бы не было велосипедистов?

      Ну из определения «велосипеда» (изобретения того, что уже есть), самая первая версия велосипедом не являлась.
      Обычно так говорят все же о проектах, которых, ну прям ОЧЕНЬ много видов уже написано. Например, не знаю, какой-нибудь сишной либы конвертации utf* туда-обратно.
      Вот как раз о таких вещах говорят «нет смысла изобретать велосипед».
      А когда на рынке 1-2 библиотеки, и одна не подходит по лицензии, вторая по функциональности… что плохого написать третью?
      (вещи связанные с безопасностью, конечно отдельная тема. я в основном про библиотеки общего назначения)
        +3
        Даже когда уже есть 100500 реализаций одного и того же, велосипеды служат инкубатором идей для новых версий мейнстримных проектов.

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

        Поэтому тащить велосипед в production — нужно семь раз подумать. А вот выложить в opensource и обсудить с коллегами — нужно обязательно.
        +2
        Как бы появлялись существующие решения, если бы не было велосипедистов?
        Ответ в тексте:
        Специалист

        Подавляющее большинство популярных библиотек написана именно им в свободное от основной работы время, так как всё ещё бьют по рукам как за велосипеды, так и за открытие исходников.
        Похоже, всё самое базовое и рисковое делается на бесприбыльной основе в open source.
          +2
          Однако открытый/бесплатный велосипед тоже является велосипедом. Где та граница, после которой велосипед переходит в категорию «существующее решение»? Если разработчик посвящает всё свое время (или большую его часть) велосипеду, то рано или поздно он доведет его до состояния «существующего решения». Если же велосипед написан второпях, плохо оттестирован, в нем отсутствует функциональность, имеющаяся в других готовых решениях, и он фактически просто затыкает какую-то дыру в проекте — это безусловно самый обычный велосипед.
            0
            Однако открытый/бесплатный велосипед является в первую очередь открытым, а только во вторую, и то необязательно — велосипедом. Велосипед — это переизобретение чужого решения, опенсорсное же решение по определению чужое, и поэтому не может быть названо велосипедом.
              0
              Вы это говорите исключительно с точки зрения коммерческого проекта, которым занимаетесь на работе? А если я пишу OpenSource, я «по определению» не могу писать велосипед, даже если переизобретаю другое опенсорсное решение? Это все конечно придирки, просто я не совсем понял вашу мысль.
                +1
                Вы это говорите исключительно с точки зрения коммерческого проекта, которым занимаетесь на работе?
                Да, я только это и имел в виду. Именно для такового опенсорсное решение по определению чужое. Именно для такового особенно критично количество затраченных человеко-часов.
                А если я пишу OpenSource, я «по определению» не могу писать велосипед, даже если переизобретаю другое опенсорсное решение?
                Тут я, да, несколько «промахнулся». Можете, конечно. Но это будет за ваш счёт, а не за счёт коммерческого проекта.

                Разумеется, чтоб научиться писать хорошо, надо писать много, и набрать требуемое для этого количество кода только на коммерческих проектах нереально. Разумеется, все проекты хотят разработчиков с навыками, но при этом никто не хочет, чтоб навык приобретался за счёт его проекта. Поэтому надо много писать «для себя», в «пет-проектах» и в опенсорсе. При этом надо понимать, что велосипеды неизбежны и что 90% написанного кода пойдут «в корзину».
        0
        Похоже, что-то не так у вас с методикой подсчета

        image
          0
          Правильно всё, там в полно открытых вопросов с 13-14 годов, а общее число открытых переваливает за семьсот. Самому старому — 2026 дней.
            +1

            Я думал, что речь идет о среднем времени, а не о сумме времени по всем issues.

              0
              С точки зрения статистики вообще лучше медианное брать, но это уже на совести автора)
                0

                Среднее и медиана хороши, когда создаваемые проблемы уравновешиваются решаемыми. Тогда можно взять статистику по решённым проблемам и прикинуть время решения очередной. Однако, как правило наблюдается динамика — проблемный долг либо растёт, либо падает. А чем больше долг, тем дольше будет решаться проблема. Представьте, что в проекте есть 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 дней.


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

                  0

                  Интересно было бы видеть еще какое-то отражение величины проекта (типа колво нерешенных багов на 100 строчек кода) и серьезность (но тут вроде из гитхаба унифицированно ее не извлечь?)


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

                  На них можно влиять предоставлением своих ресурсом (деньги, патчи, форк)

          +9

          Мой опыт с велосипедами весьма прост: почти всегда те велосипеды, с которыми я встречался в реальных проектах, обходились дороже в разработке и поддержке, чем использование готового стороннего решения. Особенно сильно это касается всяких велосипедов, связанных с безопасностью (свой OAuth2-клиент, например), или с типовыми сто раз реализованными задачами навроде логирования.


          Это, несомненно, далеко не всегда так. Но в лично моем опыте это чаще так, чем иначе.

            +1
            Согласен. Поэтому, вкатываться в продакшен на своем велосипеде надо аккуратно и всегда продумывать варианты отступления.
            +6
            Всегда есть критическая точка когда нужно писать велосипед, а когда нужно не писать.
            Если готовое решение надо допиливать и величина этих допилок превосходит хотя бы 25%, то уже надо подумать о велосипеде.
            Если готовое решение не поддерживается, не особо развивается и не особо известно, то его скорее всего вообще лучше обойти стороной.
              +1
              Если готовое решение надо допиливать и величина этих допилок превосходит хотя бы 25%, то уже надо подумать о велосипеде.
              25% видимо только от той части которая необходима, а не всего готового решения которое может содержать кучу не нужного, + нужно учесть затраты на изучение и интеграцию готового решения.
                0
                Если готовое решение не поддерживается, не особо развивается и не особо известно, то его скорее всего вообще лучше обойти стороной.

                Не раз сталкивался с тем, что если все найденные готовые решения вот такие, то это значит, что я, как и авторы этих решений, где-то просчитался в архитектуре.
                  0
                  Можете привести пример?
                    0
                    Например, как-то искал модуль для nodejs, реализующий файловое хранилище в локальной файловой системе. Функция была на тот момент второстепенной для проекта, надо было уметь «всего лишь» сохранять и извлекать файлы по id, поэтому не хотелось тащить монстров типа Jackrabbit. Все, что нашел, было или заброшено, или сыро, или годно только на совсем игрушечные объемы данных.
                    В итоге хранилище весьма шустро «завелосипедили». Всё отлично, всё работает. Но со временем в системе появлялось все больше модулей, которые используют хранилище для своих нужд, соответственно, требования к его функциональности возросли. Самые неприятные, с точки зрения усилий по реализации, касались конкурентного доступа к файлам и задач текущего обслуживания хранилища.

                    Очень похоже, что интеграция со специализированным хранилищем обошлась бы дешевле велосипеда. Собственно, в чем тут архитектурный просчет: на тот момент в используемом стеке технологий на стороне сервера приложений была только nodejs, и хотелось обойтись без добавления всяких tomcat'ов только ради «второстепенной» задачи. Стремились как раз таки сэкономить. Просчет не смертельный, но все же просчет.
                +3
                Замечательная статья!
                Начинающим велосипеды писать нужно, это бесценный опыт. Но только для себя)))
                Сколько я их в свое время написал… просто было интересно)
                Зато теперь знаю как базы данных устроены изнутри… или как работают архиваторы и чем отличается динамическое кодирование Хаффмана от статического)))
                А когда начал читать про битовые индексы в Оракл, то все было понятно с полуслова, так как такой велосипед я реализовывал, причем на не реляционных базах данных и даже в продакшене)))
                  0
                  Мне в своё время пришлось написать три фреймворка на аннотациях и один фреймворк для математических расчётов с использованием JPA и динамическим формированием JPA-запросов. Конечно, всё это были «велосипеды», но опыт действительно бесценный.
                  +9

                  Велосипедофобия — это частный случай обожествления best practices. Как и остальные best practices, "использовать готовое" — это всего лишь рекомендация, которую обязательно нужно рассмотреть в первую очередь, но совершенно не обязательно всегда ей следовать.

                    +2
                    Мне кажется, велосипедофобия — это ещё и способ избегания потенциальной лишней ответственности.
                      +4
                      Ни разу не видел, чтобы кто-то отвечал за управленческие ошибки. Особенно если они сопровождаются вербально-двигательной гиперактивностью инициативного сотрудника.

                      Все это отмечается как «разработал», «внедрил». Разгребает всегда кто-то другой.
                    0

                    В статье был упомянут эффект Даннинга-Крюгера, в английской вики пишут что нет такого эффекта, а авторы исходной работы ошибочно интерпретировали данные (математически ошибочно):
                    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".


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

                      0
                      в английской вики пишут что нет такого эффекта

                      Неа, не пишут: "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". Иными словами, эти две работы говорят не о том, что эффекта Даннинга-Крюгера не существует, а о том, что его проявления менее распространены и слабее выражены.

                        0

                        Забавно, как можно по разному одну статью прочитать. Сами эти две работы не читал, но мне хватило факта наличия их и наличия шнобелевской премии (ее так просто не дают).


                        Кстати приведенная цитата "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) более опытные точнее оценивают свое умение чем новички — т. е. у более опытных дисперсия оценки ниже чем у новичков, имхо, если бы у новичков был бы байес к завышению то так бы и написали

                          +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"

                            –1

                            Но по факту где-то 80% работ получивших премию это реальный треш. Начиная гомеопатами и заканчивая Лукашенко.

                      +2
                      У специалиста скорее всего получится не хуже, если он хорошо разберётся в проблематике и посоветуется с другими специалистами и профессионалами.

                      … напишет, отправит в эксплуатацию, исправит ошибки и учтет замечания пользователей, сделает редизайн на основе полученного опыта :)


                      https://habr.com/post/219651/


                      Идея о том, что новый код лучше старого, явно абсурдна. Старый код использовался. Он протестирован. Множество багов было найдено и они были исправлены. И с этим все в порядке. Код не плодит баги просто валяясь на жестком диске. Как раз наоборот! Программное обеспечение — это что, старый Dodge Dart, который ржавеет просто простаивая в гараже? Это что, плюшевый мишка, который плохо выглядит, если не сделан исключительно из нового материала?

                      Вернемся обратно к двухстраничной функции. Да, я знаю, это простая функция для отображения окна, но она обросла мусором и прочим барахлом, и никто не знает почему. Ну так я скажу почему: это фиксы багов. Этот кусок исправляет баг, который случился у Нэнси, когда она пыталась установить всё на машину без IE. Этот — тот баг, который происходит при нехватке памяти. А этот — когда файл находится на дискете, а юзер ее выдернул посреди всего. Вот этот вот вызов LoadLibrary ужасен, но благодаря нему код работает на старых версиях Windows 95.
                        +1
                        Цитата хорошая, но что если библиотека хорошая, проверенная, но:
                        а) мне уже не нужна совместимость с Win 95, OS/2, и что там еще в библиотеке осталось;
                        б) код который хорошо работал с устройствами на Win2000 как-то криво работает на Windows 10
                        в) автор свою разработку забросил лет 10 назад
                        Вроде как там есть и куча накопленного багажа, но надо четко оценивать насколько он применим и нужен нам.
                        А так да, даже std::variant в C++ человек опытный скорее всего не повторит корректно
                          0
                          Разумеется, всегда есть условия при которых лучше написать свое.
                          +4
                          Идея о том, что новый код лучше старого, явно абсурдна. Старый код использовался. Он протестирован.

                          Ох, если бы он был протестирован. К сожалению качество большинства библиотек, которые можно найти в интернетах крайне низкое. И пока не попробуешь не узнаешь на сколько оно плохо работает.


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

                            0
                            Мне интересно качество самой лучшей из библиотек, для какой-то задачи а не большинства. Всегда надо оценивать, что платишь, и что за это получаешь. Но сначала надо хотя бы понять что люди делали до этого когда столкнулись с такой же проблемой. Например, если пишешь статью про велосипеды, надо прочитать существующие статьи, и дописать свое, проставив ссылочки. Про Build vs Buy написана куча материалов — вполне можно их дополнить какими-то своими мыслями или обобщить.

                            Это если цель сделать что-то полезное, а не просто поучиться это делать. Т.е. как раз для новичков очень полезно писать свои маленькие учебные велосипедики. Или для старичков, которые новички в чем-то еще. В иных случаях как правило создание нового при существующем старом требует обоснования (есть x, y, z, но оно нам не подходит потому, что w).
                              0
                              Мне интересно качество самой лучшей из библиотек, для какой-то задачи а не большинства

                              Критерии выбора туманны: самая популярная не эквивалентна самой качественной.

                                0
                                Критерии выбора ваши. Что для вас важнее.
                                  0

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


                                  Здесь же ещё всплывает проблема, что как-то эту вещицу нужно поддерживать, т.е. тратить свое время не только на непосредственно патчи, но и на согласование их с сообществом. Это бывает вообще невозможно и приходится форкать.


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


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

                                    0

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


                                    Еще, я думаю, большую часть, кода, которым вы пользуетесь, вы исключаете из рассмотрения (операционная система, sql server, язык, стандартный фреймворк).


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

                                    Кодинг, тестинг (включая in production), документирование, обучение.

                              0
                              К сожалению качество большинства библиотек, которые можно найти в интернетах крайне низкое.

                              Спорное утверждение. Если звезд на гитхабе много — скорее всего качество норм.
                                +1
                                Если звезд на гитхабе много — скорее всего качество норм.

                                Или библиотека поднялась на волне хайпа.

                                  0
                                  Это да, но хайп на корявом коде возникает не так уж часто.
                                    +1
                                    А хайп возникает не на коде этой конкретной библиотеки, а на основном фреймворке.
                                    Например, в 2016 достаточно было написать слова react redux в Readme — и толпы фанатов с синдромом утенка были обеспечены. А на деле внутри может быть один файл на 20 строк с багами и часто без тестов.
                                      0
                                      Поэтому можно еще смотреть на число скачиваний с NPM. Если уж библиотека попала в зависимости, значит она решает какую-то задачу для пользователей. Установить модуль все-таки побольше усилий требует, чем поставить звездочку на гитхабе.
                                        +2

                                        Нашёл сходу в node_modules: https://www.npmjs.com/package/boolbase
                                        2 миллиона скачиваний в неделю.


                                        Исходник:


                                        module.exports = {
                                            trueFunc: function trueFunc(){
                                                return true;
                                            },
                                            falseFunc: function falseFunc(){
                                                return false;
                                            }
                                        };

                                        Странно, что без тестов. Дело лефтпада живёт.

                                          0
                                          Скачивается два миллиона раз и не ломает никому сборку? Так это же замечательно!

                                          То, что внутри тривиальная функциональность – это уже другой разговор. Главное, работает стабильно и не отсвечивает.
                                            +1
                                            Это говорит о качестве того, что её использует. Например, используется она в css-select, где можно найти свою кривую процедуру сортировки пузырьком: github.com/fb55/css-select/blob/master/lib/sort.js#L23
                                            Надо ли говорить, что тестов на неё нет? Странно, что она не вынесена в отдельный модуль.
                                              –1
                                              Вот видите, популярность библиотеки привлекла ваше внимание и вы указали на проблемные места. Если бы не популярность, то все было бы точно так же, только еще и без внимания.
                                                0
                                                Это я случайно тыкнул в один модуль из 900, чтобы показать как там всё плохо. Обычно я в эту помойку не лажу. Без толку это.
                                          0
                                          В идеальном мире — да. А в современном вебе разработчики чаще эти проблемы сами себе и создают. Постоянно вижу чуть ли не лендинги с redux, saga и еще десятком библиотек типа redux-bla-bla-bla. Хотя там и cам Redux-то не нужен. И даже Дэн об этом писал.

                                          А почему? А потому что так привыкли. Синдром утенка в действии. Отсюда и регулярные скачивания в NPM набегают…
                                            0
                                            Изначально был вопрос о критериях качества. И библиотеки с большим числом скачиваний как правило качественнее менее популярных аналогов.

                                            Вопрос, подходит ли популярный модуль под ваши задачи – это уже другая тема. Для этого есть другие методы.
                                              0
                                              Ну а я утверждаю, что популярность не является критерием качества. Это всего лишь эвристика. Популярность библиотеки / языка / фреймворка говорит об одном из двух:
                                              — это действительно качественная вещь (реже)
                                              — эта вещь была создана в нужном месте в нужное время (не обязательно первая в своем роде, а именно попавшая на гребень волны)

                                              За примерами ходить далеко не надо – сам язык JavaScript.

                                              Поэтому сервисы вроде npms.io оценивают пакеты не только по количеству скачиваний (popularity), но и по качеству (наличие тестов / CI / покрытия / документации) и по поддерживаемости (частота коммитов, кол-во открытых / закрытых issue и т.п.)
                              +5

                              Горячо поддерживаю. Только опыт велосипедостроения сделает из среднего разработчика настоящего профессионала. Даже если ваш велосипед "не взлетит", это поможет на многие проблемы взглянуть на новом уровне понимания. Я частенько сталкиваюсь с ситуациями, когда написать велосипед написать тупо проще и быстрее, чем интегрировать и отлаживать стороннее решение. А еще в популярных либах бывает много протухшего легаси, избавиться от которого в перманентно раздуваемой сообществом кодовой базе становится очень затруднительно.

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

                                Имхо, это значит что у вас не велосипед а нечто другое со своими требованиями.

                                0
                                В демо-приложении стоило бы добавить буферизацию ввода, и не ходить на сервер после каждого нажатия. Github API быстро исчерпал лимит и забанил мой IP на час
                                +5
                                Часто вижу, что например jQuery подключается на странице практически только из-за необходимости отправлять AJAX запросы, хотя самописная функция умещается в 10 строк. Раздражает повсеместно распространенная практика на любой чих подключать сразу какой-то готовый плагин с целой кучей совершенно ненужных фич. Страничка с парой десятков подключаемых скриптов — это полный мрак, особенно если они начинают конфликтовать. Лучше написать свой велосипед в 10-20-100 строк, чем подключать БелАЗ 200Kb размером (сжатым!).
                                  0

                                  А напишите эту самописную функцию, пожалуйста. Потому что лет 7 назад кроссбраузерное решение занимало явно больше 10 строк.

                                    +2
                                    await (await fetch('/api/path')).json()

                                    Для простого запроса такого хватит, а для сложных – вот тут был обзор библиотек.

                                      0
                                      А я уже думал двумя вариантами ответить, с поддержкой старых IE (через ActiveX, там действительно намного больше строк, и всё равно не повод только из-за этого подключать jQuery — хотя в том случае поводов было бы намного больше, из-за чего jQuery и появился) и новых, вот там порядка 10 строк достаточно. Но ваш вариант круче, надо подучить новые возможности JS.
                                      0

                                      А каким-нибудь bower можно это тринспилировать в ECMAScript 3? Я с современным миром JS не особо знаком, со многими вещами познакомился в статье https://habr.com/en/company/mailru/blog/340922/

                                        0

                                        Ради одной строчки кода транспиляцию запускать накладно, проще код переписать, чтобы он работал в 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>
                                          0

                                          Почему накладно? Если писать на es2017 и транспилировать в ECMAScript 3 для большей совместимости?

                                            0

                                            Потому что разворачивание async/await в es3 выглядит вот так. Не очень компактно.


                                            Плюс этому коду понадобится пара килобайт рантайма.

                                              0

                                              О, спасибо большое. А чем этот рантайм отличается от того, что внутри JS VM?

                                                0
                                                Тем, что его надо загружать отдельно, а встроенные возможности движка JS уже и так доступны.
                                              0
                                              Ладно async/await, посмотрите на «простой» for
                                    +2
                                    Я наблюдал высшую степень «велосеподофобии», когда фобия начинает поглощаться «стокгольмским синдромом» вместе с «синдромом мокрой обезьяны и непритрагиваемого банана».

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

                                    Они не могут объяснить почему это плохо или хорошо; они знают что «есть типовое», а раз есть — его надо использовать любой ценой,
                                    т.е. использование типового решения становится самоцелью, а не средством решения проблем

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

                                    Как бы вы знали, как меня достала эта охота на ведьм! оох.
                                    (и даже без смайлика, да, действительно достало.)

                                    Товарищи! ) Давайте уже объяснять новичкам почему их бьют по рукам, и что иногда надо, надо, надо писать «велосипеды».

                                    Поддерживаю автора — чем больше у вас опыта и понимания, тем больше шансов что ваш «велосипед», станет именно тем, что нужно тут и сейчас.

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


                                    ps: тут, главное, не забыть сказать, что нельзя впадать в другую крайность: далеко не всегда такое 'частное велосипедное решение' стоит потом повторно использовать, или пускать в массы. Согласитесь — тонны новоявленных языков да фреймворков, которые рождаются буквально каждый день и дохнут так же быстро как стада леммингов при миграции — это как бы намекает, что нельзя все подряд велосипеды пытаться пускать в массовость )

                                      0
                                      Поддерживаю автора — чем больше у вас опыта и понимания, тем больше шансов что ваш «велосипед», станет именно тем, что нужно тут и сейчас.

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

                                      0
                                      Теоретически, яростная велосипедофобия может привести к снижению качества кода и его разбуханию. Потому что копипаст и прочее дублирование кода — это типа не велосипедостроение, а рефакторинг с вынесением кода в общие куски ведёт к появлению каких-то самопальных библиотек, которые всегда можно назвать «велосипедом» и заявить, что вместо их написания надо использовать какие-нибудь сторонние протестированные библиотеки.
                                        +2
                                        Популярные сторонние библиотеки хороши тем, что они, как правило, хорошо протестированы, чего не скажешь о своём коде. А качество кода в случае библиотек значения не имеет. Почитайте ужасы об коде СУБД Оракл. Однако же это не мешает ей прекрасно работать, а всё благодаря огромному множеству тестов. Впрочем соглашусь, что впадать в крайности не стоит.
                                          0
                                          Я не против велосипедов, у самого их немало. Но сторонние библиотеки все-таки содержат меньше багов (в среднем), причем это не имеет никакого отношения к профессионализму авторов.

                                          Они могут быть трижды новичками и говнокодерами, но если конечный результат использует в проде куча народу, то скорее всего большинство явных косяков было найдено и исправлено (пусть даже медленно и мучительно). Сторонняя библиотека экономит не столько время разработки, сколько время тестирования. К «очередному leftpad»у этот аргумент, естественно, не относится.

                                          У меня к велосипедам отношение простое. Если есть существующее решение, удовлетворяющее всем требованиям, то лучше взять его. Если нет — пишем велосипед. Опять же, помогает при спорах «велосипедофобами»: не нравится велосипед? — предложи альтернативу!

                                            +3
                                            Сравните две фразы:

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

                                            * Неприятие велосипедов, потому что приходилось разгребать «творческий» код предшественников или тянуть основной функционал, пока коллеги занимались «творчеством».

                                            Неоднократно приходилось наблюдать, как сотрудники удовлетворяют любопытство за счет проекта. Сюда можно отнести не только строительство велосипедов (в тяжелом случае это был свой UI фреймворк с нуля, в логистическом софте), но и желание попробовать новый фреймворк, с трехкратным переездом с одного на другой за год.
                                              +1
                                              Подпишусь под каждым словом, видел не раз как при отсутствии должного контроля (который вроде бы и не подразумевается для сеньоров) люди пишут велосипеды просто потому, что интересно. Давайте свою базу данных на файлах с самописной хэш-функцией запилим. А теперь давайте свой рендерер вьюшек напишем. Ну допустим в нем не поддерживается анимация, зато он может показать в 5 раз больше данных на одном экране! А, столько не надо? Ну а вдруг понадобится?

                                              Ну и так далее, это конечно скорее о недобросовестных разработчиках, которым наплевать на работодателя и проект
                                              +1

                                              Мне кажется, что у каждого, кто в одной области пишет достаточно много кода (скажем, открывает ide раз в неделю или чаще), должна быть библиотека или пакет под названием randomtooltips, abysshit или deephole, в которой находятся только ему ведомые функции и классы

                                                +1
                                                Половину статей с хабра которые описывают «перегибы на местах» можно описать цитатой из Звездных Войн: «Только ситхи возводят все в абсолют»
                                                  0
                                                  Клуб анонимных программоголиков.
                                                  Нелюблю собственные велосипеды. Или не туда едут, или туда но не доезжают.
                                                  Но не могу остановится их создавать и докручивать. Даже в ущерб деньгам, карьере, репутации, семье. Что делать?
                                                    +1
                                                    Не знаю. У самого никакой личной жизни. Пытаюсь влиять на индустрию, но идти против хайпа, что против ветра. Велосипеды дохода не приносят. Хорошо хоть на работе и платят хорошо и проект амбициозный. Но в остальном кризис среднего возраста в полный рост. И что с этим делать — не представляю.
                                                      0
                                                      «Кризис среднего возраста» здорового человека преодолевается надеждами «оставлю детям». Велосипеды прошедших технологических поколений конечно детям не нужны. Но оставлять можно саму стратегию «создавать велосипеды». Нужна оценка перспектив велосипедостроения в программировании на среднесрочный период. Это для меня. А Ваша работа Дмитрий, конечно достойна конвертироваться в капитал.
                                                    0
                                                    (минутка философии)

                                                    Бояться нужно костылей, т.к. они нужны только калекам. А велосипеды для здоровых, ведущих активный образ жизни, людей.

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

                                                    Ну и, конечно, за своим велосипедом(впрочем как и костылем) нужно следить, обслуживать и обновлять периодически, что не нужно делать с чужими велосипедами))
                                                      0
                                                      Велосипед — порождение нестабильной архитектуры. Сдается мне никаких велосипедов на WebForms не бывает. Вот когда все вокруг скачет любой код становится велосипедом.

                                                      Пример 1: раньше фичи не было, ты написал, сейчас появилась «из упаковки», но нет времени разбираться, тем более что сейчас любое «из упаковки» это какая-то магия; да ну ее; вот фича и стала велосипедом.

                                                      Пример 2: Или вот притащил кто-то условный автомапер, напирая «убирайте свои велосипеды», а тут вдруг сдвиг в головах происходит все начинают json из db таскать и весь код вокруг DTO, автомапера, биндинга сам становится велосипедом который конечно борец с велосипедами никогда не бросит.
                                                        0
                                                        Сдается мне никаких велосипедов на WebForms не бывает.

                                                        Миллион их там.

                                                      Only users with full accounts can post comments. Log in, please.