[recovery mode] Велосипедофобия
Здравствуйте, меня зовут Дмитрий Карловский, и я — профессиональный велосипедист. За всю свою карьеру я сделал кучу велосипедов: больших и маленьких, быстрых и удобных, кривых и прямых. Поэтому для меня довольно дико видеть толковых программистов, делающих большие и сложные приложения, но при этом подключающих к проекту очередной leftpad, вместо того, чтобы написать пару простых строк своими руками. Всему виной сформировавшаяся в среде программистов и поддерживающая сама себя боязнь велосипедов.
Для простоты изложения, выделим 3 условные группы программистов. Условные, потому, что между ними нет чёткой границы, а один и тот же человек в разных областях может принадлежать к разным группам.
Новичок
- У него ещё мало опыта и знаний, но он быстро усваивает новые, так как у него ещё нет устоявшихся привычек.
- Из-за эффекта новизны хорошо видит недостатки существующих решений и имеет сильное желание сделать своё, без этих недостатков.
- Он не знает как и почему сформировались те или иные практики и принципы, а если и знает, то не прочувствовал причины их появления на своей шкуре.
- Большая часть написанного им кода либо выбрасывается, либо рефакторится до неузнаваемости. В лучшем случае его же руками под директивными указаниями более опытных коллег.
- За написание велосипедов его нещадно бьют по руками, так как сторонняя библиотека с большей вероятностью окажется качественней по множеству критериев.
Специалист
- Подавляющее большинство популярных библиотек написана именно им в свободное от основной работы время, так как всё ещё бьют по рукам как за велосипеды, так и за открытие исходников.
- Как правило качество его кода соответствует среднему качеству кода в экосистеме. Если все пишут лапшу из колбэков, то и ему ничего не остаётся.
- Как правило использует сторонний код, так как его собственный не сильно лучше, а то и хуже из-за ограничений времени.
- Соответственно за велосипеды продолжает явно (на код-ревью) или неявно (баг-репортами) получать по рукам.
- Когда какая-то проблема его совсем достаёт, он пилит велосипед. А так как таких программистов большинство, получается 100500 не совместимых друг с другом велосипедов, поддерживаемых полутора разработчиками.
Профессионал
- Способен решить любую из проблем более качественно, чем в среднем по больнице, но из-за ограниченности ресурсов вынужден выбирать чему посвятить время.
- Ему по привычке бьют по рукам. Особенно, если в компании практикуют скрам, где все решения принимают большинством, подверженному эффекту Даннинга-Крюгера.
- Часто из-за сформированных на первых двух стадиях комплексов, он сам себя ограничивает и верит, что не способен сделать ничего лучше, чем сторонняя библиотека, которая «протестирована», «продумана», «поддерживается большим числом разработчиков».
Проследив эволюцию программиста, легко заметить, что сначала у него мало навыков, но нет страха, а по мере обретения навыков появляется и усиливается боязнь велосипедов. Чтобы справиться с этим страхом, нужно разобрать его причины.
Я не смогу сделать лучше
Новичок и правда не сможет. Ему стоит направить свои усилия на то, чтобы объяснить суть и важность проблем, которые он видит своим свежим взглядом, более опытным коллегам и разработчикам библиотек.
У специалиста скорее всего получится не хуже, если он хорошо разберётся в проблематике и посоветуется с другими специалистами и профессионалами.
Профессионал же способен сделать лучше в большинстве случаев, так как уже отлично разбирается в теме и даже имеет навык всестороннего анализа. К сожалению, проконсультироваться ему как правило не с кем, ибо других профессионалов мало, и они занимаются другими темами. А специалистам не хватает кругозора.
Некому будет чинить дефекты
Обычно автор велосипеда неплохо мотивирован чинить дефекты в своём детище. Но рано или поздно эта мотивация проходит, если делает он это в нерабочее время. И тут сторонняя библиотека, казалось бы, позволяет сэкономить ресурсы, ведь её поддержкой занимаются другие люди, которым не надо платить. Но повлиять на них не представляется возможным, а потому, чтобы успеть к дедлайну, придётся засучить рукава, и починить дефект своими силами, после чего долго и упорно пробивать свой патч в основной репозиторий, без какой-либо гарантии на успех.
Некому будет улучшать и развивать
Тут та же ситуация, что и с дефектами. Но если с дефектами всем обычно ясно, что их надо чинить, то вот взгляд на направление развития у всех разное. Сторонний разработчик будет развивать свою библиотеку туда, куда нужно ему, а не вам. С той скоростью, которая удобна ему, а не вам. Так что если требуется конкретный вектор развития, то свой велосипед даёт контроль и предсказуемость — два качества, которые для менеджмента куда важнее, чем временные и денежные затраты.
Я не смогу использовать это где-либо ещё
Если хочется использовать велосипед за пределами компании, то разрабатывать его придётся либо в свободное от работы время, либо договориться об открытии исходников, что обычно сложнее, но вполне возможно. Ведь компания практически бесплатно получает пиар в среде потенциальных работников, а так же бесплатных бета-тестеров (а то и контрибьюторов, но на это не стоит рассчитывать) в лице других пользователей велосипеда.
Время и деньги будут потрачены впустую
Тут прежде всего стоит сравнить с альтернативами. Если их нет, то и выбора нет — придётся пилить. Если же альтернативы есть, то тут стоит сравнить в денежном и временном эквиваленте:
- Стоимость написания своего велосипеда надлежащего качества. Сюда входит как собственно время написания кода, так и написание тестов, и перевод проекта на велосипед, и оценка стоимости привнесённых дефектов.
- Преимущества, которые даёт велосипед. Это может быть экономия за счёт определённых фичей, меньшего числа и стоимости дефектов, и другие факторы.
- Стоимость интеграции стороннего решения. Опять же включая оценку стоимости тестирования и привнесённых дефектов.
- Ограничения накладываемые сторонним решением. Тут может выясниться, что стороннее решение совсем не подходит. Или что оно замедлит разработку в 2 раза.
Также отдельно стоит оценить стоимость перехода со стороннего решения на велосипед, если вдруг выяснится, что какое-то из ограничений более неприемлемо. Часто бывает так, что выгоднее сейчас внедрить стороннее решение, а потом быстро перевести его на свой велосипед, когда (и если) потребуется, чем сейчас тратить время на велосипедостроение.
Данная оценка помогает как самому понять стоит ли игра свеч, так и объяснить менеджменту почему стоит написать своё, а не взять чужое (или наоборот).
Меня будут проклинать, как я проклинал предшественника
Сомнительно, чтобы велосипед занимал существенную долю проекта. Так что проклинать будут в большей степени за весь остальной код. Так что велосипед надо делать как минимум не хуже. А то и лучше, чтобы ни у кого не было желания заменить его на стороннюю библиотеку или на ещё один велосипед. Для этого нужно:
- Наличие явного, важного для проекта преимущества.
- Простой интерфейс использования, чтобы не приходилось делать свои обёртки вокруг.
- Гибкий API, чтобы не приходилось пилить новый велосипед при небольшом изменении требований.
- Хорошее покрытие тестами, что позволит меньше отсвечивать в баг-репортах и хорошо переживать рефакторинги.
- Исчерпывающая документация, чтобы не требовалось искать автора велосипеда, чтобы понять как на нём кататься.
Надеюсь мне удалось показать беспочвенность страхов перед велосипедами. Чем ближе вы к профессионализму, тем более амбициозные велосипеды можете на себя взять. Начинать лучше с велосипедов поменьше, имеющих меньшие риски, но дающие не мало опыта на этом поприще. И с этим портфолио браться за всё более крутые и интересные штуки. Важно только не забывать, что настоящий профессионал не только делает крутые штуки, но и знает когда стоит отказаться от их создания. Поэтому всегда проводите анализ, который и вам даст уверенности, что всё делаете правильно, и менеджмент будет на вашей стороне, и те, кто придут после вас, будут понимать что это за велосипед, зачем он тут, и почему иначе было нельзя.
Ну, а чтобы помочь вам с анализом сторонних библиотек, я за вечер запилил приложение, позволяющее оценить время нерешения проблем проектов на ГитХабе. Чем больше число, тем хуже у проекта с поддержой, и тем дольше вам придётся ждать решения вашей проблемы. Например: сравнение Angular, VueJS, React и конечно же $mol, на котором этот велосипед и написан.
