Главная » Хабрахабр » [recovery mode] Велосипедофобия

[recovery mode] Велосипедофобия

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

У меня просто велосипеда не было."/> <img src="http://orion-int.ru/wp-content/uploads/2019/01/recovery-mode-velosipedofobiya.jpg" alt="Я почему раньше злой был?

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

Новичок

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

Специалист

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Киберпреступники пять месяцев контролировали ASUS Live Update

Злоумышленники разместили на сервере вредоносный файл с бэкдором, подписанный валидным сертификатом ASUS. Как сообщает «Лаборатория Касперского», хакеры из APT-группировки ShadowHammer 5 месяцев контролировали сервис обновлений ASUS Live Update и заразили более полумиллиона компьютеров по всему миру.Исследователи из «Лаборатории Касперского» обнаружили, ...

Kubernetes 1.14: обзор основных новшеств

14. Этой ночью состоится очередной релиз Kubernetes — 1. По сложившейся для нашего блога традиции, рассказываем о ключевых изменениях в новой версии этого замечательного Open Source-продукта. 14 и сооветствующих issues, pull requests, Kubernetes Enhancement Proposals (KEP). Информация, использованная для подготовки ...