Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Выбор телевизоров по отфильтрованным описаниям
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
26
Отследить-посылку

Отследить-посылку

отследить-посылку.рф

25
Битрикс24

Битрикс24

www.bitrix24.ru

13
WebResidentTeam

WebResidentTeam

webresident.agency

12
Логомашина

Логомашина

logomachine.ru

12
Devicerra

Devicerra

devicerra.com

11
Reader

Reader

Интернет-журнал о современных технологиях.

9
ADN Digital Studio

ADN Digital Studio

adn.agency

9
Aword

Aword

Приложение для изучения английских слов

9
GIFTD

GIFTD

giftd.tech

8
Eczo.bike

Eczo.bike

www.eczo.bike

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк во ВКонтакте

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

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

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

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

b_567c06ab2d7f7.jpg

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

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

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

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

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

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

b_567c1af8256ac.jpg

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

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

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

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

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

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

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

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

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

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

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