Главное Свежее Вакансии Образование
1 672 25 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Почему иногда стоит изобретать велосипед

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

Многие IT-специалисты будут убеждать всех в том, что «не нужно изобретать велосипед»: пользуйтесь готовыми модулями, в них есть почти всё, что вам нужно. Однако здесь речь пойдёт об обратном подходе: «пишите всё сами, если можете».

Взглянем на часть подключаемых библиотек/модулей среднего сайта:

b_567c06ab2d7f7.jpg

Многовато, не правда ли? Мелкому или среднему проекту, скорее всего, столько не нужно. А появилось всё это добро из-за нежелания потрудится над собственной реализацией простых вещей или неоправданной спешки.

Так что же, все готовые решения плохие? Нет, но их редко используют по назначению. Канонический пример: нужно добавить на сайт простую галерею для просмотра фотографий. Средний программист при желании напишет её за день с учётом специфики проекта. Только делать он этого в большинстве случаев не будет, а подключит чей-нибудь громоздкий модуль с кучей настроек и улучшенной поддержкой IE 5.5.

Зато вполне разумно использовать, например, сторонние карты, т. к. на написание собственных у вас уйдут годы.

Единственным неоспоримым преимуществом готовых решений можно назвать повышение скорости разработки (кстати, большим преимуществом). Поэтому рассмотрим подробнее их недостатки для большинства проектов:

  • Полуготовность. Сторонние модули можно сравнить с лапшой быстрого приготовления. Нужно изучить инструкцию, достать тарелку, распаковать содержимое, раздобыть воду, нагреть её, залить, подождать и ещё где-то найти ложку. Т. е. готовые решения нужно адаптировать под проект (а это не всегда хорошо и быстро получается).
  • Низкий КПД. В JS-библиотеке порой содержатся тысячи функций. Сколько из них используется в проекте? 10? 50? Все остальные просто висят мёртвым грузом, увеличивая нагрузку на оборудование.
  • Неоптимальная реализация. Сторонние модули претендуют на некую универсальность, поэтому в них содержится куча проверок и настроек, которые не нужны для вашего проекта. Собственное решение может работать в десятки раз быстрее.
  • Отсутствие функционала. Очень часто в готовом решении есть 70% функционала, который вам нужен, но не 100%. Т. е. придётся использовать ещё один модуль или реализовывать остальное самостоятельно.
  • Конфликтность. Несколько чужих модулей могут влиять на работу друг друга не лучшим образом. Найти и разрешить такие противоречия бывает нелегко.
  • Непредсказуемость. Любая функция может работать не так, как ожидалось. Например, недавно попался текстовый редактор, который наотрез отказывался печатать букву «ё».
  • Неисправимые ошибки. Почти любая программа содержит ошибки. Готовые подключаемые модули — не исключение. Проблема в том, что ошибку в собственном коде программист найдёт гораздо быстрее, чем в чужом. Некоторые компании вообще запрещают модифицировать свою интеллектуальную собственность.
  • Платность. Мощные решения часто являются платными. Не все компании имеют средства для их покупки.
  • Отсутствие гарантий безопасности. Вы уверены, что какая-нибудь чужая функция не передаёт внутренние данные компании третьим лицам?

Напоследок рассмотрим пример почти полного отказа от готовых решений на televizor-x.ru:

b_567c1af8256ac.jpgЧто это за сиреневый туман? Это весь JS-код клиентской части сайта (кроме счётчика Метрики). Он занимает около 10 килобайт и вмещается в один FullHD экран. В коде реализованы:

  • Работа с AJAХ-запросами.
  • Галерея (переключение миниатюр, лупа, полноэкранный просмотр, предзагрузка, листание пальцами).
  • Фильтр по характеристикам.
  • Коррекция ввода в некоторых полях.
  • Изменение URL без перезагрузки.
  • Всплывающие подсказки для характеристик товаров.
  • Поиск.
  • Кнопки «поделиться в соцсетях».
  • Скрытие/показ блоков на маленьких экранах.
  • Вызов Яндекс.Метрики.

При необходимости код можно ещё оптимизировать.

+10
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
PushAll
Платформа мгновенных уведомлений.
Олег Карнаухов
Кстати, было бы круто, если бы например можно было на продакшене "собрать" сайт так, чтобы все неиспользуемые функции из кода удалялись. Тогда получаем и библиотеки и эффективный по размеру код.
Ответить
Показать предыдущие комментарии
Цена на
Просто поиск цен на товары
Евгений 10302
Какие-то библиотеки в браузере — плохая идея, т. к. чуть устаревшие версии браузеров сразу не будут поддерживать актуальные версии библиотек. Потом все ещё начнут жаловаться, что их любимая библиотека не вошла в стандарт...

Вообще не очень понятно, почему написание собственных решений для проекта всегда вызывает бурные дебаты. Ни у кого своих программистов нет?
Ответить
StartupFellows
Сайт вакансий от стартапов. Поиск специалистов и стартапы для специалистов.
andfadeev 9471
есть же https://developers.google.com/closure/compiler/ и dead code elimination, собирает весь js и выкидывает все что не используется
Ответить
PushAll
Платформа мгновенных уведомлений.
Олег Карнаухов
Воот. Я так и думал, что такое чувствует.
Ответить
Антон Тихомиров
Хотели сказать "существует"?)))
Ответить
PushAll
Платформа мгновенных уведомлений.
Олег Карнаухов
Ага, писал одной рукой на планшете 9ти дюймовом, тот еще изврат.
Ответить
4devs
Разработка и поддержка проектов на Symfony 2
Андрей 22153
когда вы говорите "пишите свои библиотеки", где-то грустит сообщество. Конечно день написать, хорошему программисту, какие браузеры не будем поддерживать? Сколько времени надо на тестирование? Сколько времени будет в дальнейшем уходить на поддержку уже написаного кода? Самый лучший код это отсутсвие кода, если уже кто-то за вас все сделал тогда не надо изобретать велосипед, и вопрос не только в написании но и в исправлении багов, в отлавливали ошибок, в поддержке. В то время когда вашу супер библиотеку пишет один программист, стороннюю пишут десятки, и она постоянно развивается...
И что вы в итоге выигрываете? работает она также, только с поддержкой браузеров с исправлением ошибок. Размер больше? при данном уровне интернета 200кб - не смешите меня, и еще для распространены библиотек есть cdn, поэтому можно даже не грузить. А если вы не можете решить конфликты и все функции в вашей библиотеки глобальные, то это говорит о низком уровне разработчиков...
Время потраченное можно использовать не написание того то уже есть, а на то что необходимо - что решает бизнес задачи.
И про поддержку ИЕ 5.5 это где вы нашли такую галерею?
Ответить
AgriChain
AgriChain - комплексная онлайн система IT-решений для управления агробизнесом
Панченко Андрей
плюсанул! молодцом ребята!
Ответить
Цена на
Просто поиск цен на товары
Евгений 10302
Очень часто сталкиваюсь с таким мнением и не могу сказать, что полностью с ним не согласен. Однако такой подход характерен для тех, кто рассматривает проект только как средство зарабатывания денег. Опять обращаю внимание на то, что речь не идёт о всех проектах. В части случаев готовые библиотеки абсолютно оправданы.

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

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

Глобальные функции — это зло для большой модульной библиотеки, которую должны поддерживать 20 человек. Если функций всего 20, то глобальность не имеет особого значения. Опять же были случаи, когда приходилось переписывать хорошую модульную объектную структуру на нечитаемый низкоуровневых код, который работал примерно в 100 раз быстрее.

«Работает она также». Опять же не соглашусь. Решает ту же задачу, да, но работает она по-другому, избыточно. Зачем писали LiteOS? Почему бы не взять какой-нибудь готовый Linux?

Про IE 5.5 — это утрирование. Но суть в том, что не поддерживая 5% браузеров, можно улучшить работу в остальных 95% (что в своё время и сделал YouTube).
Ответить
Антон Тихомиров
Оставлю свое оптимистичное мнение тут. Потрясная статья, которая призывает выкинуть все барахло из jQuery, особенно когда нужно процентов 30 из всего ее функционала. Лично я в серьез об этом задумался и на досуге этим обязательно займусь. Вопрос только в свободном времени. Честно признаться, если бы я ее не прочитал - я бы до сих пор думал, что тащить саму jQuery, а к ней и jQuery UI, в которых нужны только окошки и слайдер - это нормально. Ради таких статей хочется заходить на Спарк. И не слушайте диванных теоретиков, большинству и аббревиатура JS не знакома бывает)
Ответить
Показать предыдущие комментарии
EasyGuide
Платформа для путешественников и гидов
U.238 80570
Я вот тоже недавно задумался о том чтобы написать свою версию jQuery без лишнего и с добавлением некоторых нужных удобств. Но, как оказалось, далеко ходить не нужно: для работы с DOM есть прекрасная библиотека Zepto. Она весит меньше jQuery и имеет такое же API как у jQuery. Новый проект однозначно на ней буду делать.
Ответить
Антон Тихомиров
О, да, слышал о ней. То есть если API как у jQuery - значит полностью совместима с плагинами для нее? Это тогда очень интересно!
Ответить
EasyGuide
Платформа для путешественников и гидов
U.238 80570
Насчет плагинов не факт, потому как только манипуляции с DOM и функции ajax в ней реализованы. Но с простыми плагинами может и совместима будет, надо проверить (и наверно нужно будет поменять ссылку с jQuery на Zepto в коде плагинов)
Ответить
Антон Тихомиров
Ну да, это принципиально, так что тут нужно взвесить все за и против. Лично у меня несколько десятков их, больше половины самописных. Из коробки jQuery довольно мало умеет на самом деле.
Ответить
EasyGuide
Платформа для путешественников и гидов
U.238 80570
да, согласен
Ответить
Андрей Сиденко
Всегда говорю, что «на * свой Google не построишь».

Для посредственных сайтов пойдет. Все равно их, скорее всего, забросят через N месяцев. Но если что-то серьезное - только свои разработки, ребята.

* любая CMS, любой сторонний модуль и т.д.
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.