А компетентен ли советчик? Проблемы рекомендации «не изобретай велосипед»

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

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

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

Упустить из виду этот принцип, все равно, что признаться в собственной неспособности решать прикладные задачи.

Рассмотрим несколько случаев.

Источник

API над API

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

Случай из моей практики.

Язык мейнстримовый и библиотека от самого Facebook нагуглилась за 2 минуты. Необходимо было реализовать загрузку данных из Facebook в наш сервис.

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

5 часа работы с ней, не удалось даже авторизоваться. Результат: через 1.

Суммарно, на создание обертки и связанной функциональности на стороне сервиса у него ушло около часа. Коллега реализовал собственную обертку web-api фейсбука. На вопрос "а зачем ты тут навелосипедил", он отвечал следующие несколько дней.

Такие обертки устаревают, как только оборачиваемый интерфейс обновляется, а авторы забрасывают такие "проекты", делая код, их использующий, нерабочим. Подобное особенно ярко проявляется в мейнстримовых язык с большим коммьюнити: появляется нездоровая тенденция публиковать обертки API над другим API, под лозунгами "For humans" и "In simple way".

Здравый вопрос: и что, каждый раз писать такие обертки вручную?

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

Контроль над кодовой базой и отказ отвечать за чужие ошибки

"Зачем изобретать велосипед? В кругах wannabe разработки компьютерных игр такая фраза адресуется любому, кто посмеет реализовать свой движок. Или Game Maker, или, не, дай бог, Defold. Возьми юнити!".

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

То есть необходимо снизить вероятность встретить "чужой баг", исправить который cамостоятельно либо невозможно, либо крайне затруднительно. Как должен поменяться контекст здесь, чтобы появилась необходимость делать свой движок?
Как минимум, это контроль над кодовой базой и функциями движка (например, на ряде моделей контроллеров гейммейкер стабильно глючит, и поправить это бывает крайне проблематично).

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

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

Например, исходя из подобных посылок Томми Рефенес написал свой движок для Super Meat Boy.

Кто-то возразит: "Но ведь в сторе\еще каком-то хранилище, есть же гора пресетов\инструментов\расширений!".

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

Мнимая идентичность. Притягивание задачи за уши.

Из-за своей "жирности" или неудовлетворения одного из ключевых условий задачи (да, их бывает несколько). Иногда, сформулировав задачу выясняется, что приходящие на ум существующие решения… не подходят.

Хороший пример: CluNet.

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

Вывод

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

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

Если советчик упомянул велосипеды раньше, чем через несколько минут раздумий, скорее всего, делать этого он не умеет. Свидетельствует ли обратное о неумении решать задачи?

Или, по-капитански обобщая:

Прежде, чем решать — думай.
Прежде, чем говорить — думай.
И вообще — думай.