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

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

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

Новичок

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

Специалист

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Дмитрий Карловский

Источник ^[4]