Comments 36
P.S. Сам плевался от фейсбучных SDK, в итоге написал за полчаса коннектор на curl.
Пилим большой (относительно — бандл около пяти мегабайт в сумме) проект на React и TypeScript. Периодически сталкиваюсь с тем, что существует почти подходящее решение где-то в недрах npm, но в нём есть досадное несоответствие нашим ожиданиям, из-за которого брать эту библиотеку к себе "как есть" — значит, наворачивать вокруг неё лютые костыли. Уже несколько раз форкал такие пакеты и тащил в проект собственную версию. Тоже своего рода велосипед (пусть и по большей части из фабричных деталей)? Зато руль ровно нужной высоты и тормоза откалиброваны.
Обратное тоже верно. Решил писать велосипед — обоснуй почему не существующие решения, почему не адаптер над ними. И аргументы должны быть чёткими, чтобы два дня не объяснять.
С другой стороны, налицо фактор протекания, просачивания не используемых сначала функций больших библиотек, затянутых в проект ради одной, в результате чего заменить её на практике почти невозможно. Хрестоматийный пример в веб-разработке — jQuery. Затащили ради AJAX или промисов, а потом во всем приложении используется всё, да ещё jQuery UI. Основной аргумент — уже есть же, не надо новую зависимость, не надо велосипед писать…
И аргументы должны быть чёткими, чтобы два дня не объяснять
Так об этом и речь. В статье у коллеги автора были вполне уважительные причины сделать свою реализацию, но очень сложно сломить предупреждение, что свой велосипед никогда не может быть лучше, чем что-то готовое.
Причины может и были, но судя по "отвечал несколько дней" аргументов готово не было. Ну или не донёс их массово, убеждая каждого по одиночке.
Но ведь в самом вопросе ничего странного нет :) Видишь контринтуитивное решение — спроси коллегу, почему он его принял. И отсутствие готовой обёртки к популярному сервису действительно вызывает недоумение и недоверие. Мой опыт показывает, что такое бывает — но редко.
И отсутствие готовой обёртки к популярному сервису действительно вызывает недоумение и недоверие
Вполне могу себе это представить. Обертка для Java, скорее всего, будет и будет актуальной, но ведь еще есть: .Net, Go, PHP, Ruby, Python и т.д. – поддерживать API обертки в актуальном состоянии для всех возможных языков и технологий может быть проблемой даже для очень крупной компании.
Эта проблема, на мой взгляд, проистекает из-за того, что у REST сервисов нет общепризнанного механизма их описания
Хм… Swagger a.k.a. OpenAPI?
И кодогенерация под мейнстримовые языки в нём имеется.
Основная проблема, по-моему, в другом: большинство сервисов не REST, даже если сами себя так называют.
Я к тому, что стандарты описания заточены прежде всего под идиоматический REST. Из-за этого, когда ради практического удобства мы отходим от REST, то, с одной стороны, сами описания дают мало важной информации, что-то остаётся в лучшем случае в комментариях, а то и в голове, а, с другой, описания становятся трудоёмкие без всякого полезного выхлопа. Ну, скажем, мы только POST метод используем, но его всё время нужно указывать.
Просто надо было написать это где-то, где все сами могли прочитать. например в комментарии к MR/PR. Или рассказать на дейли-митинге, груминге, планерке и т. п.
"Зачем изобретать велосипед? Возьми юнити!"
У этого решения есть ещё один недостаток, который распространяется на многие не-писания-велосипедов. Юнити часто оверкилл и он может тащить непропорциональные системные требования. Они не запредельные, да, но всё равно как-то странно, когда рогалик с минимальной анимацией, не поддерживающий даже мышь (не говоря уже о геймпадах, 3D, VR и чёрте в ступе), весит 100+ Мб и лагает на интегрированной видеокарте. Серьёзно, отрисовка страниц в браузере — несопоставимо сложнее, чем весь UI игры, но как-то же фаерфокс умудряется работать на относительно старом железе.
Но есть другая проблема: если конкретный разрабочтик игры не смог на юнити оптимизировать рогалик с минимальной анимацией — разве можно надеяться, что он сможет написать с нуля игровой движок с лучшей производительностью? Автор игры скорее всего не осилил документацию по движку — но вот с нуля написать на SDL или вручную на OpenGL+DirectX он сможет написать нечто лучшее? Сомнительно :)
Безусловно, какие-то минимальные требования к компьютеру у Unity есть, и без него реально написать игру, весящую намного меньше и работающую в разы быстрее. Но гораздо чаще тормоза вызывает не сам движок, а неумение им пользоваться.
Но есть другая проблема: если конкретный разрабочтик игры не смог на юнити оптимизировать рогалик с минимальной анимацией — разве можно надеяться, что он сможет написать с нуля игровой движок с лучшей производительностью?
Я вот вообще не смогу ничего собрать на юнити, не говоря уже об оптимизации, потому что я юнити умею только устанавливать и впринципе занимаюсь бэкендом. Но что касается движка для платформера, то думаю за неделю где-нибудь напишу. Рабочий прототип, в котором можно будет прыгать по платформе, вообще, наверное за день соберу. По фичам будет хуже, чем в юнити, но для платформера может быть больше и не нужно?
Приветствую! Хотелось бы дать небольшой комментарий. Любая проблема, как медаль, имеет две стороны. Так и аргументы высказанные в статье описывают лишь одну сторону медали. Спасибо за примеры из практики. Так, действительно, лучше разъяснять свою точку зрения.
Существует и обратная сторона медали. Разработка своего в рамках решения задачи далеко не всегда есть велосипед. Вопрос заключается в том, учтен ли уже существующий опыт при решении подобных задач. Потому что изобретение велосипеда часто превращается в изобретение квадратного деревянного колеса.
Часто разработчики мнят себя гениями и первооткрывателями. Но, согласитесь, что мы в средней массе не Моцарты, а, дай Бог, Сальери. Из этого следует, что выбор пути решения должен быть результатом изучения технологий и подбора правильного стратегического решения. Которое не приведет в дальнейшем к серьезным проблемам.
Опыт и знания позволяют иногда выносить суждения о том, что не нужно изобретать велосипед. И все, далеко не ограничено выбором API, фреймворка или библиотеки. Естественно, что все выводы должны быть обоснованы. Но я, даже, предлагая уже известные и успешно реализуемые много лет концепции, сталкивался с непросветной глупостью "гениев изобретения велосипедов". Как результат в промышленной реализации возникали и продолжают возникать проблемы, которых легко можно было избежать.
Да беда и в релевантности тоже. Если человек несколько лет изобретал в какой-то области квадратные колеса. То вот вам и специалист со стажем! Только качество стажа и кругозор у него слишком узки.
Посылку поддерживаю. Поэтому я и говорю о «нескольких минутах раздумья». В сущности, бездумно бросаться реализовывать так же безалаберно, как и бездумно втаскивать другие решения.
Если подняться на уровень мышления повыше, то основной формулой успеха является взять чужое решение и его облагородить!!! Не изобретать заново, а улучшить, или адаптировать под себя. И там надо учитывать так много нюансов, зачастую тратя много времени и ресурсов, что у кого-то его эмпирический опыт подсказывает сразу — «не надо изобретать велосипед». Это называется интуиция. Она, конечно, может поводить иногда.
Но чаще подводят велосипеды с квадратными колесами.
На мой взгляд, при более-менее сложной задаче, первый посыл — смотреть прототипы, аналоги и т.п. Это и для изобретения тоже нужно. И только все взвесив и обосновав, оценив свои силы, браться что-то кардинально менять и изобретать свое.
Амфибия летает плохо, но зато не тонет. Свой дирижабль построить легко, и он даже будет летать. Но до первой грозы.
P.S. Ну вот упомянули Unity всуе. Плохой пример, имхо. Это, конечно, монстр. Зато будет актуален для проектов любого масштаба, вплоть до прикладного моделирования и т.п. Но полно более простых вариантов, даже на уровне библиотек. Вот тут точно, свой велосипед выйдет золотым. Если мы говорим не про разовый проект, а про вхождение в геймдев на профессиональном уровне (хотя бы в мечтах).
Пишем большой проект. Все сторонние библиотеки четко делятся на три категории:
1) кандидаты на добавление в стандартную библиотеку,
2) те, в которые нам приходится контрибьютить,
3) непригодные к использованию вообще.
Мы выработали правило: не бери стороннюю библиотеку, если не готов посылать в нее пулл-реквесты.
Хороший пример: CluNet.
Так если автор так засматривался на CAN, то почему не CAN то? Ни одного ограничения, которое помешало бы использовать сам CAN, в статье не упоминается.
Мне кажется пример про игровые движки мимо. Он подразумевает, что у разработчика
- хватает умений, чтобы не только написать всю игровую логику, но и игровой движок, причём делающий необходимый минимум функций не хуже или лучше готовых движков. Сюда может входить удобный редактор уровней, поддержка сразу нескольких игровых платформ (Windows/PS/Xbox), хорошая работа с разным оборудованием (вспоминаем те же геймпады) и многое другое
- есть время, чтобы написать не только игру, но и движок, а так же в дальнейшем его поддерживать
И на любой пример "автор написал свой движок и выпустил популярную игру" можно привести сотню "автор взял готовый движок и написал популярную игру". Блин, да даже Blizzard использовала Unity для Hearthstone, хотя вот у кого-кого, а у них недостатка в ресурсах уж точно нет.
И нет, я выводы статьи не оспариваю — просто пример с игровыми движками расходится с оптимальной практикой. В 9 случаях из 10 стоит таки выбрать готовое решение. А вот в единственном десятом у автора собственного движка достаточно компетенций, чтобы ему этот совет был бесполезен — он и сам может принять такое решение :)
P.S. И да, я сам писал с нуля и свой игровой движок, и редакторы уровней, и CMS для сайтов — всякое бывало. Но часто это был не оптимальный выбор, а скорее повод прокачать скилл.
Одна достаточно несложная, но увлекательная игра, в которую я постоянно донатил, была на Unity. После очередного обновления движка Unity он, а с ним и игра, перестал запускаться на относительно старых системах и относительно старых браузерах типа ФФ двухгодичной давности. Я решил, что эта игра не стоит обновления железа и системы. При этом сама игра от обновления не получила ничего, всё и так прекрасно работало (и, кстати, практически не развивалось — так что новые возможности движка не требовались, даже если они и были)
В целом, статью поддерживаю, очень часто приходится писать свои решения, а чужие, в случае когда принимается решение «не писать свой велосипед», иногда приносят много боли на этапе поддержки, или когда выясняется что для фичи, которая развивается, понадобился не только функционал «А», представленный в библиотеке, но и функционал «Б», который придумали уже после внедрения сторонней либы, и который в ней отсутствует.
Впрочем, для наиболее распространённых задач, на популярных языках, как правило есть несколько десятков\сотен готовых решений, и достаточно найти в топе по скачиваниям на гитхабе такой вариант, который поддерживается мейнтейнерами. К сожалению, не все задачи, которые приходится решать, являются «распространёнными»)
В кругах wannabe разработки компьютерных игр такая фраза адресуется любому, кто посмеет реализовать свой движок. «Зачем изобретать велосипед? Возьми юнити!»
Если ты сумеешь полноценно реализовать движок хотя бы приближающийся к Unity — ты более высокой квалификации, чем заметная доля программистов под Unity (извините, ребята).
Для тех не стоит вообще вопрос написать движок, ибо не смогут.
Велосипед так долго не могли изобрести, потому что на утренних планёрках кто-то постоянно говорил «Давайте не будем изобретать велосипед».©
А компетентен ли советчик? Проблемы рекомендации «не изобретай велосипед»